Method and apparatus for performing and reporting early measurements based on predicted UL and / or DL data

Abstract

Embodiments include a WTRU configured to receive configuration information indicating a trigger condition for a measurement to be performed when operating in a first activity level, receive an indication to transition from operating in a second activity level to operating in the first activity level, perform the measurement when operating in the first activity level in response to predicting that the trigger condition is satisfied, and perform the measurement when operating in the second activity level in response to predicting that the trigger condition is satisfied. And sending a report based on the measurement in response to transitioning to the second activity level. For example, a WTRU may be configured to perform UL / DL traffic prediction and early measurements while in an idle / inactive state, and send a measurement-based report in response to transitioning to a connected state. The report may include the measurements performed and / or indicate whether the CA / DC configuration will allow the WTRU to meet UL / DL traffic requirements. The WTRU may also avoid performing measurements and / or include measurement reports.

Description

[0001] Cross - reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 410,681, filed on September 28, 2022, the content of which is incorporated herein by reference. Summary of the Invention

[0003] Embodiments of an apparatus or device include a WTRU configured to perform UL / DL traffic prediction and early measurement when in an idle / inactive mode, wherein the WTRU configuration further includes a condition / correlation between uplink / downlink (UL / DL) traffic prediction and early measurement.

[0004] One or more embodiments relate to artificial intelligence / machine learning (AI / ML) and UL / DL traffic prediction, such as early measurement and UL / DL traffic prediction for cellular automation / dual - connectivity (CA / DC).

[0005] In an embodiment, a WTRU (e.g., a UE) is configured to perform UL / DL traffic prediction and early measurement when idle / inactive (e.g., during idle / inactive mobility), wherein the WTRU configuration further includes a condition / correlation between the two (e.g., the WTRU is configured to perform early measurement only when the predicted traffic volume is higher than a certain level, or the traffic has a certain quality of service (QoS)).

[0006] In an embodiment, the WTRU is configured to perform UL / DL traffic prediction when idle / inactive, and is configured to monitor conditions associated with starting early measurement, and start performing early measurement when the conditions are met.

[0007] In an embodiment, upon connection setup or restoration, the WTRU includes current and predicted buffer levels (e.g., predicted buffer status report (BSR) and current BSR).

[0008] In an embodiment, upon connection setup or restoration, the WTRU includes additional information, such as whether CA / DC is needed to adapt to current and predicted traffic levels / types, reasons why early measurement is not performed or reasons for not including an early measurement report, etc.

[0009] In an embodiment, a wireless transmit / receive unit (WTRU) is configured to receive configuration information indicating trigger conditions for performing measurements, perform measurements in response to predicting that the trigger conditions are met, and send measurement - based reports.

[0010] In an embodiment, the WTRU performs the following operations:

[0011] Receive one or more of the following configurations (e.g., from the network or from another WTRU):

[0012] Early measurements (e.g., during transition from a connected mode to an inactive or idle mode);

[0013] Predictions regarding UL or / and DL data arrival (e.g., time span, desired accuracy level);

[0014] Relationship between the performance of early measurements and predicted UL / or DL data (e.g., when at least X KB of UL data is expected to arrive within n milliseconds (ms) with an accuracy of p%, early measurements will be initiated);

[0015] Transition from a connected mode to idle / inactive (e.g., upon receipt of a Radio Resource Control (RRC) release message);

[0016] Do not immediately initiate the execution of early measurements when transitioning to the idle / inactive mode;

[0017] Perform UL / DL data prediction;

[0018] Initiate the execution of early measurements when it is detected that the condition for starting early measurements based on the predicted data is met;

[0019] Initiate an RRCSetup or RRCResume procedure upon arrival of UL data or upon receipt of a paging indicating DL data; and

[0020] Send the results of the executed early measurements (e.g., send to the network or another WTRU) during or upon completion of the RRCSetup or RRCResume procedure. Description of the Drawings

[0021] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals in the drawings indicate like elements and in which:

[0022] Figure 1A is a system diagram showing an example communication system in which one or more of the disclosed embodiments can be implemented;

[0023] Figure 1B is a system diagram showing an example wireless transmit / receive unit (WTRU) that can be used within the communication system shown in Figure 1A ;

[0024] Figure 1C is a system diagram showing an example radio access network (RAN) and an example core network (CN) that can be used within the communication system shown in Figure 1A ;

[0025] Figure 1D is a system diagram showing an example that can be used withinFigure 1A System diagram of another example RAN and another example CN used within the shown communication system;

[0026] Figures 2 to 3 Illustrates the RRC connection establishment / setup connection restoration procedure;

[0027] Figure 4 Summarizes different RRC modes and the transitions between different RRC modes;

[0028] Figure 5 Illustrates early measurements that can be used for fast setup of CA / DC when a WTRU moves from RRC_INACTIVE to RRC_CONNECTED;

[0029] Figures 6A to 6C Illustrates a sample BSR format.

[0030] Figure 7 Illustrates that when receiving a UECapabilityEnquiry message from the network, the WTRU compiles and transmits WTRU capability information by sending a UECapabilityInformation message;

[0031] Figure 8 Diagram of potential problems with the current mechanism for early measurement configuration;

[0032] Figure 9 Diagram showing another potential problem with the current mechanism for early measurement configuration;

[0033] Figure 10 Diagram showing that according to an embodiment, the WTRU is provided with a configuration related to early measurement configuration depending on traffic prediction (when in connected mode or when transitioning to inactive mode);

[0034] Figure 11 Diagram showing that according to an embodiment, the WTRU determines a scenario where CA / DC setup is not required;

[0035] Figure 12 Diagram showing that according to another embodiment, the WTRU is provided with one or more configurations related to early measurement configuration depending on traffic prediction (when in connected mode or when transitioning to inactive mode); and

[0036] Figure 13 Flowchart of a method implemented by a WTRU for performing measurements and reporting results in response to the satisfaction of a trigger condition according to an embodiment. Detailed embodiments

[0037] The following are the abbreviations and acronyms used herein.

[0038] AMF Access and Mobility Management Function

[0039] AP Aperiodic

[0040] BS Base Station

[0041] BWP Bandwidth Part

[0042] CCE Control Channel Element

[0043] CORESET Control Resource Set

[0044] CRC Cyclic Redundancy Check

[0045] CSI Channel State Information

[0046] CSI-RS Channel State Information RS

[0047] DCI Downlink Control Information

[0048] DL Downlink

[0049] DMRS Demodulation Reference Signal

[0050] FDD Frequency Division Duplexing

[0051] FDM Frequency Division Multiplexing

[0052] FDMA Frequency Division Multiple Access

[0053] FDRA Frequency Domain Resource Allocation

[0054] FR1 Frequency Range 1

[0055] FR2 Frequency Range 2

[0056] HARQ-ACK Hybrid Automatic Repeat Request Acknowledgment

[0057] ID Identification, also known as Index

[0058] IM Interference Measurement

[0059] MAC Medium Access Control

[0060] MAC CE MAC Control Element

[0061] MCS Modulation and Coding Scheme

[0062] MIMO Multiple-Input Multiple-Output

[0063] MU-MIMO Multi-User MIMO

[0064] NDI New Data Indicator

[0065] NR New Radio

[0066] NZP Non-Zero Power

[0067] OFDM Orthogonal Frequency Division Multiplexing

[0068] PBCH Physical Broadcast Channel

[0069] PDCCH Physical Downlink Control Channel

[0070] PDSCH Physical Downlink Shared Channel

[0071] PSCCH Physical Sidelink Control Channel

[0072] PSSCH Physical Sidelink Shared Channel

[0073] PUCCH Physical Uplink Control Channel

[0074] PUSCH Physical Uplink Shared Channel

[0075] QAM Quadrature Amplitude Modulation

[0076] QCL Quasi-Co-Location

[0077] QPSK Quadrature Phase Shift Keying

[0078] RAN Radio Access Technology

[0079] RE Resource Element

[0080] REG Resource Element Group

[0081] RRC Radio Resource Control

[0082] RS Reference Signal

[0083] RSRP RS Received Power

[0084] RV Redundancy Version

[0085] Rx Receive, Receiver or Reception

[0086] Scell Secondary Cell

[0087] SCI Sidelink Control Information

[0088] SDM Space Division Multiplexing

[0089] SINR Signal-to-Interference-plus-Noise Ratio

[0090] SLIV Start and Length Indicator Value

[0091] SNR Signal-to-Noise Ratio

[0092] SP Semi-Persistent

[0093] SRI SRS Resource Indicator

[0094] SRS Sounding RS

[0095] SSB Synchronization Signal / PBCH Block

[0096] SUL Supplementary Uplink

[0097] TB Transport Block

[0098] TCI Transmission Configuration Indicator

[0099] TDD Time Division Duplex

[0100] TDM Time Division Multiplexing

[0101] TDRA Time Domain Resource Allocation

[0102] TRP Transmission and Reception Point

[0103] TRS Tracking RS (also known as CSI-RS for tracking)

[0104] Tx Transmission, Transmitter or Transmission

[0105] UCI Uplink Control Information

[0106] UE User Equipment; UE and WTRU are used interchangeably in this document

[0107] UL Uplink

[0108] WTRU Wireless Transmit / Receive Unit; UE and WTRU are used interchangeably in this document

[0109] ZP Zero Power

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

[0111] As Figure 1A shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal digital assistants (PDA), smart phones, laptop computers, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMD), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automation processing chain), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0112] The communication system 100 may further include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (such as CN 106, the Internet 110, and / or other networks 112). By way of example, base stations 114a, 114b may be base transceiver stations (BTSs), NodeBs, eNodeBs (eNBs), home NodeBs, home eNode Bs, next-generation NodeBs (such as gNodeBs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, and the like. Although each of base stations 114a, 114b is described as a single element, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

[0118] 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 jointly implement LTE radio access and NR radio access, such as using the Dual Connectivity (DC) principle. Therefore, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNB and gNB).

[0119] 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 (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), GSM Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0120] For example, Figure 1A the base station 114b in [description] can be a wireless router, a home Node B, a home eNode B, or an access point, and may use any suitable RAT to facilitate wireless connectivity in a local area, such as business premises, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drones), and roads, etc. 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 pico cell or a femto cell. As Figure 1A shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.

[0121] The RAN 104 may communicate 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 different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, accounting services, location-based services for mobile devices, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although in Figure 1AAlthough not shown in the figure, it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT or different RATs as RAN 104. For example, in addition to being connected to RAN 104 which can use NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technology.

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

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

[0124] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136 and / or other peripheral devices 138, etc. It should be understood that while maintaining consistency with the embodiments, the WTRU 102 can include any sub-combination of the foregoing elements.

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

[0126] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (such as base station 114a) via an air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive signals such as IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

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

[0129] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (such as a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132), and store data in such memories. 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 so on. In other embodiments, the processor 118 may access information from memories that are not physically located on the WTRU 102 (such as located on a server or a home computer (not shown)), and store data therein.

[0130] The processor 118 may receive power from a power source 134, and may be configured to distribute and / or control power for 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 batteries (such as nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, a fuel cell, and so on.

[0131] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (such as longitude and latitude) about the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (such as base stations 114a, 114b) via an air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may obtain location information by means of any suitable location determination method while remaining compliant with the embodiments.

[0132] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral device 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, etc.

[0133] 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 a particular subframe for both 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 hardware (e.g., a choke) or via signal processing by 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 a particular subframe for UL (e.g., for transmission) or DL (e.g., for reception)).

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

[0135] The RAN 104 may include eNode-Bs 160a, 160b, 160c, but it should be understood that the RAN 104 may include any number of eNode-Bs while remaining compliant with the embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

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

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

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

[0140] SGW 164 may be connected to PGW 166, and PGW 166 may provide access to a packet-switched network such as the Internet 110 for WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices.

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

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

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

[0144] A WLAN employing an infrastructure Basic Service Set (BSS) mode can have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP can have access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic destined for an STA from outside the BSS can arrive via the AP and can be delivered to the STA. Traffic from an STA destined for a destination outside the BSS can be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS can be sent via the AP, e.g., where the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between the source STA and the destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode can not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode can sometimes be referred to herein as an "ad-hoc" communication mode.

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

[0146] High Throughput (HT) STAs can use 40 MHz wide channels for communication, e.g., by combining a 20 MHz primary channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

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

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

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

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

[0151] Figure 1DFIG. 0 is a system diagram showing RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0152] RAN 104 may include gNBs 180a, 180b, 180c, but it should be understood that RAN 104 may include any number of gNBs while remaining compliant with the embodiment. Each of gNBs 180a, 180b, 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, 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 gNBs 180a, 180b, 180c. Thus, for example, gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive a coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0153] 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 the OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or having a continuously varying absolute time length).

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

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

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

[0157] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing the registration area, terminating non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service that the WTRUs 102a, 102b, 102c are using. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 182a, 182b may provide control plane functions for handovers between the RAN 104 and other RANs (not shown) that employ other radio technologies (e.g., LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

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

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

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

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

[0162] The simulation device can be designed to implement one or more tests on other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device to perform tests and / or execute tests using over-the-air wireless communication.

[0163] One or more simulation devices can perform one or more functions including all functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can send and / or receive data using direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas).

[0164] In NR, the WTRU can be in one of the following three RRC modes:

[0165] - RRC_CONNECTED (also referred to as "connected" or "connected mode" in this document)

[0166] - RRC_INACTIVE (also referred to as "inactive" or "inactive mode" in this document)

[0167] - RRC_IDLE (also referred to as "idle" or "idle mode" in this document)

[0168] In the RRC_CONNECTED mode, the WTRU actively connects to the network, where signaling and data radio bearers are established (SRBs and DRBs), and it is capable of receiving downlink (DL) data from the network in unicast and also capable of sending uplink (UL) data to the network. The mobility of the WTRU from one cell / node to another is controlled by the network, which may configure the WTRU to send measurement reports periodically or when certain conditions are met (e.g., an adjacent cell becomes better than the serving cell by more than a certain threshold), and based on these reports, the network may send a handover command to the WTRU to move the WTRU to another cell / node. The network may also configure conditional handover CHO, where the WTRU executes a pre-configured handover command when certain conditions are met instead of sending measurement reports. The network may also send a HO command to the WTRU without receiving any measurement reports (e.g., based on implementation, e.g., determination of the current location).

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

[0170] If the network expects the WTRU to become inactive for a long duration, it may send the WTRU to the RRC_IDLE mode. When in the RRC_IDLE mode, the WTRU camps on the best cell (the cell with the best signal level at the highest priority RAT and the highest priority frequency within that RAT), which will facilitate the WTRU to establish a connection via that cell if the WTRU needs to transition back to the connected mode. The WTRU also monitors the downlink paging channel to detect the arrival of DL data. If the WTRU detects a paging indicating the arrival of DL data from the network, or if the WTRU wants to send UL data, the WTRU will initiate a connection setup / establishment process.

[0171] During connection setup or recovery, the WTRU first performs a random access (RA) process (also referred to herein as the random access channel RACH process) before sending an RRCSetupRequest or RRCResumeRequest message. The RA process serves at least two main purposes:

[0172] - Obtain UL synchronization between the UE and the network (e.g., gNB)

[0173] - Obtain the resources to be used for sending the request message.

[0174] During the RA process, the WTRU sends a message (referred to as msg1) containing a preamble and a RA-RNTI (Random Access - Radio Network Temporary Identifier) on the RACH to the gNB. In the case of contention-based random access (CBRA), the preamble is randomly selected from a set of possible preamble values (i.e., there may be contention if another WTRU initiates a random access procedure using the same preamble value). In the case of contention-free random access (CFRA), a specific preamble is provided to the WTRU in advance (e.g., when the WTRU is in the connected mode, during the transition to the idle / inactive mode, etc.). The RA-RNTI is calculated based on the PRACH (Physical RACH) occasion on which the random access message is to be sent to the network.

[0175] Upon receiving msg1, the gNB responds with msg2, which contains a random access response (RAR). To enable the WTRU to obtain the RAR, the network also sends a DCI (Downlink Control Indicator) scrambled with the RA-RNTI in the PDCCH, and the WTRU uses this DCI to determine on which resources (i.e., time and frequency) the RAR (and other relevant information) is provided to the WTRU. The WTRU attempts to detect this DCI within a period of time after sending the preamble (referred to as the RAR window). If such a DCI is not received, the WTRU may retransmit the preamble again. If the DCI is received, then the WTRU will obtain the RAR at the indicated time and frequency resources in the PDSCH. In the RAR and the associated information, the WTRU will be provided with a timing advance (TA) applied to send UL data, a TC-RNTI (Temporary Cell RNTI), and UL resources for sending setup / resume request messages.

[0176] The WTRU can obtain detailed information / configurations regarding the use of the random access channel, such as the RACH occasion, the random access response window, etc., via dedicated configuration or from the system information broadcast (SIB) when in the connected mode or during the transition in the idle / inactive mode.

[0177] Figures 2 to 3 Illustrates the RRC connection establishment / setup and connection resume processes according to one or more embodiments.

[0178] Refer to Figure 2 , at 200, the WTRU 202 is in the connection management (CM)-idle mode and the RRC-idle mode.

[0179] At 204 (Message 1), the WTRU 202 sends an RRCSetupRequest message to the gNB 206.

[0180] Next, at 208 (Message 2), the gNB 206 sends an RRCSetup message to the WTRU 202.

[0181] Then, at 210, the WTRU 202 is in CM - idle mode and RRC - connected mode.

[0182] Next, at 212 (Message 2a), the WTRU 202 sends an RRCSetupComplete message to the gNB 206.

[0183] Then, at 214 (Message 3), the gNB 206 sends an initial WTRU message to the AMF 216.

[0184] Next, at 218, the WTRU 202 is in CM - connected mode and RRC - connected mode.

[0185] Then, at 220 (Message 4), the AMF 216 sends a downlink NAS transport message to the gNB 206.

[0186] Next, at 222 (Message 4a), the gNB 206 sends a DLInformationTransfer message to the WTRU 202.

[0187] Then, at 224 (Message 5), the WTRU 202 sends a ULInformationTransfer message to the gNB 206.

[0188] Next, at 226 (Message 5a), the gNB 206 sends an uplink NAS transport message to the AMF 216.

[0189] Then, at 228 (Message 6), the AMF 216 sends an initial context setup request message to the gNB 206.

[0190] Next, at 230 (Message 7), the gNB 206 sends a SecurityModeCommand message to the WTRU 202.

[0191] Then, at 232 (Message 7a), the WTRU 202 sends a SecurityModeComplete message to the gNB 206.

[0192] Next, at 234 (Message 8), gNB 206 sends an RRCReconfiguration message to WTRU 202.

[0193] Then, at 236 (Message 8a), WTRU 202 sends an RRCReconfigurationComplete message to gNB 206.

[0194] Next, at 238, gNB 206 sends an initial context setup response message to AMF 216.

[0195] Reference Figure 3 , at 300, WTRU 302 is in connection management (CM)-connected mode and RRC-inactive mode.

[0196] Then, at 304 (Message 1), WTRU 302 sends an RRCResumeRequest message to gNB 306.

[0197] Next, at 308 (Message 2), gNB 306 sends a retrieve WTRU context request message to the previous serving gNB 310.

[0198] Then, at 312 (Message 3), the previous serving gNB 310 sends a retrieve WTRU context response message to gNB 306.

[0199] Next, at 314 (Message 4), gNB 306 sends an RRCResume message to WTRU 302.

[0200] Then, at 316, WTRU 302 is in CM-connected mode and RRC-connected mode.

[0201] Next, at 318 (Message 5), WTRU 302 sends an RRCResumeComplete message to gNB 306.

[0202] Then, at 320 (Message 6), gNB 306 sends an Xn-U address indication message to the previous serving gNB 310.

[0203] Next, at 322 (Message 7), gNB 306 sends a path switch request message to AMF 324.

[0204] Then, at 326 (Message 8), AMF 324 sends a path switch request response message to gNB 306.

[0205] Next, at 328 (Message 9), gNB 306 sends a WTRU context release message to a previous serving gNB 310.

[0206] Note: Refer to Figures 2 to 3 (The following msg numbers may not correspond to the message numbers in Figures 2 to 3 above).

[0207] - The term msg3 is used herein to refer to RRCResumeRequest or RRCSetupRequest.

[0208] - The term msg4 is used herein to refer to RRCresome or RRCSetup.

[0209] - The term msg5 is used herein to refer to RRCResumeComplete or RRCSetupComplete.

[0210] - If the WTRU 202 / 302 resumes connection in the same gNB 206 / 306, messages 2, 3, and 6 to 9 may not be required and thus the WTRU can be resumed without involving the Core Network (CN).

[0211] As can be seen above and Figures 2 to 3 in, the RRC connection setup process can be a lengthy process that may take several round-trip times to complete and it may involve the CN. This is because when the WTRU 202 / 302 enters the idle mode, the RRC context of the WTRU is released and thus the WTRU is unknown at the RAN level. Therefore, the RAN obtains the WTRU context from the CN. In addition, security is re-established thereafter and the WTRU 202 / 302 is reconfigured with DRBs and SRBs before UL / DL data transmission / reception occurs.

[0212] This lengthy setup process may be incompatible with low-latency services and thus NR has introduced an intermediate state between the connected mode and the idle mode, which is called the inactive mode. The INACTIVE mode has most of the power-saving advantages of the idle mode (e.g., the WTRU 202 / 302 can but does not need to continuously monitor the PDCCH, which is one of the most power-consuming processes in the connected mode), but at the same time, the RAN still maintains the RRC / security context of the WTRU. When the WTRU 202 / 302 transitions to the connected mode (e.g., due to the arrival of UL data or receipt of a paging indicating the arrival of DL data), the connection can be quickly resumed, e.g., without involving the CN, without re-establishing the security context of the WTRU, and without reconfiguring the bearers.

[0213] Figure 4 Summarizes different RRC modes and the transitions between them.

[0214] For example, at 400, a WTRU ( Figure 4 not shown in) is in the NR RRC - connected mode.

[0215] The WTRU can transition to an intermediate NR RRC - inactive mode at 402, or directly to the NR RRC - idle mode at 404.

[0216] When in the NR RRC - inactive mode at 402, the WTRU can transition back to the NR RRC - connected mode at 400 or to the NR RRC - idle mode at 404.

[0217] Also, when in the NR RRC - idle mode at 404, the WTRU can transition back to the NR RRC - connected mode at 400.

[0218] Refer to Figures 2 to 4 , when a WTRU (e.g., WTRU 202 / 302) performs a connection setup / establishment or resume procedure, it includes (in the RRCSetupRequest or RRCResumeRequest) the cause for the setup or resume. Currently, the following causes are defined.

[0219]

[0220] For example, if the connection is being set up / resumed due to a voice call or video call initiated by the WTRU, the WTRU sets the setup / resume cause to mo - VoiceCall (mobile - originated voice call) or mo - VideoCall (mobile - originated video call). As another example, if the connection is being set up / resumed due to a downlink paging indicating DL data, the WTRU sets the setup / resume cause to one of mt - Access (mobile - terminated access), highPriorityAccess, mps - PriorityAccess, or mcs - PriorityAccess (depending on the access category of the WTRU).

[0221] When the WTRU is sent to the inactive mode, the network includes suspendConfig in the RRCRelease message, and SuspendConfig contains information such as the following:

[0222] - The resumeIdentity (short identity short RNTI and long identity full RNTI) to be used by the WTRU. The WTRU determines which identity to use based on the system information broadcast in the target cell (e.g., if useFullResumeID is indicated in the SIB, the long identity is used, otherwise,

[0223] the short identity is used).

[0224] - RAN paging area (e.g., cell list): This is the RAN area where the WTRU can be paged at the RAN level. If the WTRU performs cell reselection to a cell outside the RAN area, the WTRU performs a RAN area update procedure.

[0225] - nextHopChaining count: This is used to derive the security context (e.g.,

[0226] encryption / integrity protection key) when resuming the connection.

[0227] The mechanism for RAN area update is sometimes referred to as the "two-step resume" process because the WTRU sends a ResumeRequest indicating cell reselection to a cell outside the RAN area, and the network responds with a release message (e.g., including the new RAN area configuration). That is, the WTRU will remain in the inactive mode, and if the WTRU needs to be paged (e.g., for DL data arrival at the RAN for the WTRU), the network now has information about which RAN area the WTRU is or can be accessible in.

[0228] Regarding measurements in RRC_IDLE and RRC_INACTIVE, the network can configure carrier aggregation (CA) or / and dual connectivity (DC) for the WTRU in order to increase the data rate per user (and in some cases, also increase reliability). In CA, the WTRU simultaneously sends / receives data to / from multiple cells of a given gNB operating at different carrier frequencies. On the other hand, in DC, the WTRU is connected to two serving gNBs, called the master node (MN) and the secondary node (SN). When operating in DC, the WTRU can be further configured in CA within the MN and / or SN. The set of cells configured for the WTRU under the MN is called the master cell group (MCG), and the cells under the SN are called the secondary cell group (SCG). The primary cell in the MCG is called the PCell, and the primary cell in the SCG is called the PSCell. The term SPCell (special cell) is used to refer to the PCell or PSCell. Cells other than the SpCell are called SCells (secondary cells).

[0229] The network typically decides to configure CA and / or DC for a WTRU based on measurement reports received from the WTRU regarding neighboring cells (although nothing prevents the network from blindly configuring CA or / and DC).

[0230] To enable quick configuration of CA and / or DC as soon as the WTRU transitions to RRC_CONNECTED, it is known to introduce early measurement reports (also known as idle / inactive measurements), where the WTRU can be configured to perform measurements on neighboring cells (intra-frequency, inter-frequency, or / and inter-RAT neighboring cells) while it is in RRC_INACTIVE or RRC_IDLE. When the WTRU transitions to the RRC_CONNECTED mode, the WTRU can send the measurements to let the network know if there are candidate neighboring cells that can be configured in the CA or DC mode for the WTRU.

[0231] Figure 5 Illustrates early measurements that can be used for quick configuration of CA / DC when the WTRU 500 transitions from the RRC_INACTIVE mode to the RRC_CONNECTED mode. At 501, the network 503 detects that the WTRU 500 is not exhibiting activity. At 502, the WTRU 500 is provided with at least one early measurement configuration by the network 503 when transitioning from RRC-CONNECTED 504 to RRC_INACTIVE 506, and the WTRU configures itself according to the early measurement configuration. At 508, when the WTRU is in RRC_INACTIVE, the WTRU 500 performs measurements. When the WTRU 500 transitions to the RRC_CONNECTED mode 510 (e.g., at 512, due to receiving a paging due to DL data arrival, or at 514, UL data arrives and is to be sent, etc.), the WTRU will trigger an RRC resume procedure by sending an RRC resume request message at 516. At 518, the network 503 can request the WTRU 500 to send the measurements performed during the RRC_INACTIVE mode in the RRC resume message, and the WTRU will provide the measurements in the RRCResumeComplete message at 520. Based on this, if such candidate cells are available at 522, the network 503 can immediately configure CA / DC.

[0232] If such candidate cells are available at 522, the network 503 sends an RRCReconfiguration message to the WTRU 500 at 524, which can include CA / DC configuration information.

[0233] Next, at 526, the WTRU 500 sends an RRCReconfigurationComplete message to the network 403 and thereafter operates in CA / DC mode according to the CA / DC configuration information sent to the WTRU by the network 503 at 528.

[0234] Still referring to Figure 5 , in the absence of early measurements (e.g., NR rel-15), the setup of CA / DC may have been significantly delayed because the WTRU 500 will be configured with measurements to be performed after transitioning to RRC_CONNECTED and the network 503 typically waits until the WTRU has performed these measurements and has sent a measurement report before configuring CA / DC.

[0235] Idle / inactive measurement configurations can be provided to the WTRU 500 via a dedicated message (e.g., in the measIdleConfig information element (IE) in the RRCRelease message when the WTRU transitions to idle / inactive), or the WTRU can obtain the idle / inactive measurement configuration from System Information Block (SIB) 11 (in the measIdleConfig-SIB IE).

[0236] The measIdleConfig IE can basically contain one or more of the following general items:

[0237] - A list of NR carrier frequencies to be measured (for CA or DC candidate NR cells). This can contain additional information such as a list of cells to be measured, the quality to be measured (e.g., RSRP or RSRQ), RSRP / RSRQ thresholds indicating which cells are to be included in the measurement report, details of SSB and beam configurations, etc.

[0238] - A list of EUTRA (i.e., LTE) frequencies (for inter-RAT candidate cells with NR for DC, e.g., EN-DC, NE-DC). This can contain additional information such as a list of cells to be measured, the quality to be measured (e.g., RSRP and / or RSRQ), RSRP / RSRQ thresholds indicating which cells are to be included in the measurement report, etc.

[0239] - Idle measurement duration (a value ranging from approximately 10 seconds to 300 seconds): This specifies how long the WTRU

[0240] 500 remains performing measurements while idle / inactive;

[0241] - Active area: Specifies a list of frequencies (and optionally cells within that frequency). If the WTRU

[0242] If the WTRU 500 reselects a cell that is not included in the active area, the WTRU 500 stops measuring.

[0243] The active area is optional, and the WTRU 500 is configured with at least an NR list or an E-UTRA frequency list (which may also be configured with both).

[0244] Regarding scheduling in NR, the base station (gNB, e.g., part of network 503), specifically the MAC entity at the gNB in the example, is responsible for scheduling both the uplink and downlink physical resources in NR.

[0245] To achieve an efficient use of network radio resources in a fair manner among different WTRUs served by the network, the gNB uses information such as:

[0246] - Buffer status related to the WTRU (e.g., pending data to be sent in DL for the WTRU at the gNB, UL buffer status reported by the WTRU)

[0247] - QoS requirements for each WTRU and related radio bearers

[0248] - Radio conditions at the WTRU (e.g., identified by measurements performed at the gNB and / or reported by the WTRU)

[0249] - Power headroom at the WTRU, which is the difference between the maximum transmit power of the WTRU and the estimated power of the UL transmission (e.g., as indicated by a power headroom report from the WTRU).

[0250] When the gNB makes scheduling decisions in both UL and DL (i.e., which (which) WTRU gets which UL / DL resources to transmit / receive), the gNB will use all the above information about the numerous WTRUs it is currently serving. The gNB can schedule in a dynamic manner (i.e., the WTRUs being scheduled and which resources are allocated to these WTRUs change from one radio time slot / frame to another) or in a persistent manner (i.e., a certain set of radio resources allocated to a WTRU or a group of WTRUs in UL or DL at a given time). Persistent scheduling in UL in NR is called configured grant, while in DL, it is called semi-persistent scheduling (SPS).

[0251] Regarding uplink scheduling, in the uplink, the gNB can dynamically allocate resources to the WTRU via C-RNTI on (one or more) PDCCHs. The WTRU monitors (one or more) PDCCHs to find possible grants for UL transmission. When CA is configured, the same C-RNTI applies to all serving cells.

[0252] The gNB may cancel a PUSCH transmission, or a repetition of a PUSCH transmission, or an SRS transmission of a WTRU, for another WTRU with a latency-critical transmission. The gNB may configure the WTRU to monitor the cancellation transmission indication using the CI-RNTI on the PDCCH.

[0253] In addition, using the configured grant, the gNB may allocate uplink resources for the initial HARQ transmission and HARQ retransmission to the WTRU. There are generally two types of configured uplink grants:

[0254] - Type 1: The RRC directly provides the configured uplink grant (including periodicity).

[0255] - Type 2: The RRC defines the periodicity of the configured uplink grant, and the PDCCH addressed to the CS-RNTI may signal and activate the configured uplink grant, or deactivate the configured uplink grant; that is, the PDCCH indication addressed to the CS-RNTI may implicitly reuse the uplink grant according to the periodicity defined by the RRC until deactivation.

[0256] The WTRU may be configured with up to, for example, 12 active configured uplink grants for a given BWP of the serving cell. When more than one active uplink grant is configured, the network determines which of these configured uplink grants are active at a certain time (including all uplink grants). Each configured uplink grant may be of Type 1 or Type 2. For Type 2, the activation and deactivation of the configured uplink grant are independent between serving cells. When more than one Type 2 configured grant is configured, each configured grant is individually activated using a DCI command, and the deactivation of the Type 2 configured grant is completed using a DCI command, which may deactivate a single configured grant configuration or jointly deactivate multiple configured grant configurations.

[0257] For both dynamic grants and configured grants, for a transport block, two or more repetitions may be in one time slot, or across time slot boundaries in consecutive available time slots, where each repetition is in one time slot. For dynamic grants and Type 2 configured grants, the number of repetitions may also be dynamically indicated in the L1 signaling. The dynamically indicated number of repetitions overrides the RRC-configured number of repetitions, if both exist.

[0258] Regarding buffer status reports, the uplink buffer status report (BSR) provides support for QoS-aware packet scheduling. In NR, the BSR is reported at the logical channel group (LCG) granularity. A WTRU can be configured with up to 32 logical channel IDs (LCIDs), and these can be grouped into up to 8 LCGs. Note that some special WTRUs can be configured with more than 32 LCIDs and more than 8 LCGs (e.g., a mobile terminal (MT) of an integrated backhaul access (IAB) node can be configured with up to 65855 LCIDs and 256 LCGs).

[0259] The BSR can be sent in at least two formats:

[0260] - A short BSR format for reporting data of only one LCG;

[0261] - A long BSR format for reporting data from several LCGs

[0262] The MAC control element (MAC CE) is used to send the BSR. When the BSR is triggered (e.g., when new data arrives at the WTRU's transmission buffer), if the WTRU does not have any available UL grant to send the BSR, the WTRU sends a scheduling request (SR) to request the required UL resources to send the BSR.

[0263] There are several variants of the short BSR and the long BSR (e.g., for the case of an IAB MT), but for the sake of brevity, only a subset of them is described below and shown in the corresponding figures. The details of the variants of the short BSR and the long BSR are known.

[0264] Some BSR formats are shown in Figures 6A to 6C where "Oct" represents 8 bits (one byte). Figure 6A is a diagram of a short BSR MAC CE format with one Oct Oct1 according to an embodiment, where Oct1 is segmented into 3 bits for the LCG ID and 5 bits indicating the size of the buffer. Figure 6B is a diagram of an extended short BSR format with two Octs according to an embodiment, where Oct1 is an 8-bit LCG ID and Oct 2 is an 8-bit indicator of the size of the buffer. Figure 6C is a diagram of a long BSR MAC CE format with m + 1 Octs according to an embodiment, where Oct 1 includes an 8-bit LCG ID and Oct 2 to OCTm+1 each indicate the buffer size 1 to buffer size m of the corresponding buffer 1 to buffer m.

[0265] The buffer sizes included in the BSR report can be encoded according to the following table (i.e., the WTRU includes an index corresponding to the buffer size for the respective LCG).

[0266] Buffer size level of the 5-bit buffer size field (in bytes)

[0267]

[0268]

[0269]

[0270]

[0271] In an embodiment, the radio resource control (RRC) configures the following parameters to control the BSR:

[0272] - periodicBSR-Timer;

[0273] - retxBSR-Timer;

[0274] - logicalChannelSR-DelayTimerApplied;

[0275] - logicalChannelSR-DelayTimer;

[0276] - logicalChannelSR-Mask;

[0277] - logicalChannelGroup.

[0278] The MAC entity determines the UL data volume available for a logical channel according to the data volume calculation process performed at RLC and PDCP.

[0279] When performing the data volume calculation, the RLC includes RLC data PDUs with outstanding transmissions or retransmissions, RLC SDUs (or segments of RLC SDUs) that have not yet been included in RLC data PDUs, and any outstanding RLC status PDUs (e.g., TS 38.322).

[0280] The data volume calculation at PDCP takes into account PDCP SDUs for which PDCP data PDUs have not yet been constructed, PDCP data PDUs that have not yet been sent to the lower layer, any PDCP control PDUs, and any PDPC SDUs or PDUs to be retransmitted due to PDCP reconstruction or PDCP data recovery, as is known.

[0281] In an embodiment, the WTRU triggers a BSR if any of the following events occur:

[0282] - UL data for a logical channel belonging to an LCG becomes available to the MAC entity; and / or

[0283] - The UL data belongs to a logical channel with a priority higher than the priority of any logical channel containing available UL data belonging to any LCG; or

[0284] - None of the logical channels belonging to the LCG contain any available UL data.

[0285] In this case, the BSR is referred to as a "regular BSR";

[0286] - UL resources are allocated and the number of padding bits is equal to or greater than the size of the buffer status report MAC CE plus its sub-header, in which case the BSR is referred to as a "padding BSR";

[0287] - The retxBSR-Timer expires and at least one of the logical channels belonging to the LCG contains UL data, in which case the BSR is also referred to as a "regular BSR";

[0288] - The periodicBSR-Timer expires, in which case the BSR is referred to as a "periodic BSR".

[0289] When regular BSR trigger events occur simultaneously for multiple logical channels, each logical channel triggers a separate regular BSR.

[0290] A scheduling request (SR) is used to request UL-SCH resources for a new transmission.

[0291] The MAC entity can be configured with zero, one, or more SR configurations. An SR configuration includes a set of PUCCH resources for SR across different BWPs and cells. For example, each BWP is configured with at most one PUCCH resource for SR.

[0292] Each SR configuration corresponds to one or more logical channels. Each logical channel can be mapped to zero or one SR configuration configured by the RRC. The SR configuration of the logical channel that triggers the BSR is considered the corresponding SR configuration for the triggered SR.

[0293] In an embodiment, the RRC configures the following parameters for the scheduling request procedure:

[0294] - sr-ProhibitTimer (per SR configuration);

[0295] - sr-TransMax (per SR configuration).

[0296] In an embodiment, the following WTRU variables are used for the scheduling request procedure:

[0297] - SR_COUNTER (per SR configuration).

[0298] If an SR is triggered and there are no other SRs pending corresponding to the same SR configuration, the MAC entity sets the SR_COUNTER for the corresponding SR configuration to 0.

[0299] When an SR is triggered, it is considered pending until it is cancelled.

[0300] All pending SRs for a BSR triggered according to the BSR procedure are cancelled before MAC PDU assembly, and when a MAC PDU is sent, each corresponding sr-ProhibitTimer stops, and the PDU includes a long or short BSR MAC CE that contains the buffer status up to (and including) the last event that triggered the BSR before MAC PDU assembly. When the (one or more) UL grants can accommodate all the pending data available for transmission, all pending SRs for a BSR triggered according to the BSR procedure are cancelled, and each corresponding sr-ProhibitTimer stops.

[0301] PUCCH resources on a BWP that are active only at the time of an SR transmission occasion are considered valid.

[0302] Regarding BSRs, 3GPP designers have started to investigate the use of AI / ML mechanisms for improved and even optimized operation of the radio access network (RAN). For example, several use cases have been identified, such as:

[0303] Network energy savings; load balancing; and mobility optimization.

[0304] AI / ML models are proposed to be used by the network and / or the WTRU to predict different aspects, such as WTRU trajectories, WTRU traffic, service, and adjacent cell signal levels, etc. And based on these predictions, the network can make better and proactive decisions, rather than in the traditional reactive manner (e.g., performing a handover when the signal level of an adjacent cell becomes better than that of the serving cell, and performing traffic steering / load balancing once the serving cell becomes overloaded).

[0305] Predictions can be made by the network, the WTRU, or in cooperation between the two. For example, in an area related to traffic prediction, the WTRU can be provided with an AI / ML model (e.g., provided by the network, a proprietary model of the WTRU vendor or operator), and once the model is well-trained (e.g., within a certain time period until the WTRU has verified that the prediction has a certain level of acceptable accuracy or error tolerance), the WTRU can be configured to send a predicted BSR even before the actual traffic has reached the WTRU buffer, giving the network advance time and enabling it to make better decisions (e.g., giving more configured / dynamic grants, configuring additional carriers or / and dual connectivity, preemptively offloading the relevant WTRU or other WTRUs to neighboring cells), whereby resources will be available for the WTRU before the time when the predicted data is actually available and ready to be sent at the WTRU buffer.

[0306] Regarding WTRU delivery, as Figure 7 shown, in NR, once the WTRU 700 receives a WTRUCapabilityInquiry message from the network 702 at 704, the WTRU 700 compiles and delivers its WTRU capability information by sending a UECapabilityInformation message to the network at 706.

[0307] When the WTRU needs (additional) WTRU radio access capability information, the network 702 initiates this process for the WTRU 700 in the RRC_CONNECTED mode. The network 702 retrieves the capabilities of the WTRU 700 after AS security activation. The network does not forward the capabilities of the WTRU 700 retrieved before AS security activation to the CN.

[0308] The WTRU 700 capabilities can be requested according to radio access technology (RAT) type (e.g., NR, E-UTRA). Additional filters can also be included in the capability request to limit UL signaling, as the size of all WTRU capability information may be large and the network 702 may already have the capability information of some WTRUs (e.g., from an earlier capability delivery of the WTRU 700, or from an earlier capability delivery from the CN).

[0309] As discussed below, the WTRU 700 can be configured to perform measurements when it is in the RRC_IDLE or RRC_INACTIVE mode, and once it transitions to the connected mode (e.g., due to receiving a paging indicating DL data arrival or detecting UL data arrival), the WTRU 700 can provide these measurements.

[0310] Based on these measurements, network 702 may configure CA or / and DC for WTRU 700. However, such a mechanism only considers the availability of carriers for configuring CA or / and DC for WTRU 700. Thus, WTRU 700 may ultimately be configured with CA or / and DC, but may not utilize the configuration (e.g., the WTRU will only have limited UL / DL data to transmit / receive for a significant period of time after CA / DC is configured). Of course, network 702 is able to detect and release the CA or / and DC configuration. However, during that time, the resources that have been provisioned for that WTRU 700 may not be available for other WTRUs. Additionally, there may be unnecessary signaling for configuring and then releasing CA or / DC.

[0311] A potential problem with the current mechanism for early measurement configuration is that reporting and CA / DC configuration based on the current mechanism do not take into account the WTRU's need for CA / DC.

[0312] Reference Figure 8 , at 800, WTRU 802 is in the RRC - connected mode.

[0313] At 804, network 806 detects that WTRU 802 is not exhibiting activity, and at 808, the network sends an RRCRelease message and one or more early measurement configurations to the WTRU.

[0314] At 810, WTRU 802 enters and is in the RRC - inactive mode, and at 812, the WTRU begins to perform and executes one or more early measurements on parameters such as UL or DL, such as data size, data throughput, number of carriers, or QoS of the channel on which UL or DL is transmitted or received. The WTRU continues to perform one or more early measurements 815 during the idle measurement duration.

[0315] At 814, when WTRU 802 is performing early measurements in the RRC - inactive mode, UL data arrives for the WTRU to send to network 806.

[0316] At 816, WTRU 802 sends an RRCResumeRequest to network 806, and at 818, the network sends an RRCResume message and a request for one or more early measurements performed by the WTRU during and after 812.

[0317] At 820, WTRU 802 sends an RRCResumeComplete message and a report of one or more early measurements performed by the WTRU during and after 812 to network 806.

[0318] At 822, the WTRU 802 transmits uplink data to the network 806 while in RRC - connected mode.

[0319] At 824, the network 806 determines whether there are available candidate cells for the WTRU 802 to operate in dual - connection (DC) mode.

[0320] At 826, the network 806 sends an RRCReconfiguation message to the WTRU 802, which includes, for example, DC setup configuration, and the WTRU configures itself to operate in DC mode (or CA / DC mode).

[0321] At 828, the network 806 detects that the WTRU 802 does not need to operate in carrier aggregation (CA) mode or dual - connection (DC) mode because, for example, UL / DL load or other parameters of data delivery (such as the number of available carriers and QoS) are suitable for the WTRU to operate in a mode other than CA mode, DC mode, and / or CA / DC mode. A WTRU 802 operating in CA / DC mode may waste one or more resources of the network 806 during interval 829 when it is not necessary to do so.

[0322] And at 830, the network 806 sends an RRCReconfiguration message to the WTRU 802 that includes, for example, SCG release and / or CA release, and the WTRU reconfigures itself to operate in a mode other than single - cell mode or DC mode (and / or CA mode and / or CA / DC mode).

[0323] As described below, another issue regarding the validity of these early measurements is that the early measurement configuration has an associated idle measurement duration / time, and the WTRU performs measurements only for that duration after transitioning to the idle / inactive mode. For example, if the measurement duration is 10 seconds and the WTRU has been in the idle / inactive mode for 30 seconds, the measurement it has will be 20 seconds. And these measurements can be completely different from the current situation at the WTRU. For example, a cell measured as strong may be very weak when the WTRU becomes active, or the WTRU may even be out of the coverage of such a cell. Therefore, if the network uses the early measurements reported during setup / resumption to configure CA or / and DC, some failures may occur (e.g., radio link failure on the SCG, which the WTRU typically needs to report and the network has to re - configure itself or re - configure the WTRU).

[0324] Another potential problem with the current mechanism for early measurement configuration is that reporting and CA / DC configuration based on such early measurement(s) may lead to incorrect CA / DC configuration due to outdated measurement results.

[0325] Reference Figure 9 , at 900, the WTRU 902 is in RRC - connected mode.

[0326] At 904, the network 906 detects that the WTRU 902 is not exhibiting activity, and at 908, the network sends an RRCRelease message and one or more early measurement configurations to the WTRU.

[0327] At 910, the WTRU 902 enters and is in RRC - inactive mode, and at 912, the WTRU starts to perform and executes early measurements on parameters such as UL or DL, such as data size, data throughput, number of carriers, or QoS of the channel for sending or receiving UL or DL.

[0328] During the interval 914, the WTRU 902 performs early measurements in idle / inactive mode.

[0329] At 916, the WTRU 902 stores the early measurements in on - board memory (i.e., stores the results of the performed early measurements).

[0330] During the interval 918, the WTRU 902 does not perform early measurements.

[0331] At 920, UL data arrives for the WTRU 902 to send to the network 906 or elsewhere.

[0332] At 922, the WTRU 902 sends an RRCResumeRequest to the network 906, and at 924, the network sends an RRCResume message and a request for one or more early measurements performed by the WTRU at 912 and 914.

[0333] At 926, the WTRU 802 sends an RRCResumeComplete message to the network 906 along with a report of the early measurements taken by the WTRU at 912 and 914.

[0334] At 928, the WTRU 902 sends uplink data to the network 906 while in RRC - connected mode.

[0335] At 930, the network 906 determines whether there are available candidate cells for the WTRU 902 to operate in dual - connection (DC) mode.

[0336] At 932, network 906 sends an RRCReconfiguation message to WTRU 902 that includes, for example, DC setup configuration, and the WTRU configures itself accordingly to operate in DC mode (or CA / DC mode).

[0337] At 934, WTRU 902 determines that it cannot access (e.g., cannot perform random access) the primary cell (PSCell) of a secondary cell group (SCG).

[0338] At 936, WTRU 902 notifies network 906 of this inability to access by sending an SCGFailureInformation message to the network.

[0339] And at 938, network 906 sends an RRCReconfiguation message to WTRU 902 that includes, for example, one or more other SCG identifiers and an SCG release (to release the WTRU from the current SCG that has a PSCell that the WTRU cannot access), and the WTRU configures itself accordingly to operate in DC mode (or CA / DC mode) with another SCG.

[0340] One or more embodiments disclosed herein (such as the foregoing embodiments) may address the potential problems and situations described above and elsewhere herein.

[0341] The terms “early measurement,” “idle mode measurement,” “idle measurement,” and “idle / inactive measurement” may be used interchangeably to refer to measurements performed by a WTRU while in the RRC_IDLE or RRC_INACTIVE mode.

[0342] In this disclosure, the terms “mode” and “state” may be used interchangeably (e.g., idle mode and idle state).

[0343] In this disclosure, the terms “data volume / type” and “traffic volume / type” may be used interchangeably.

[0344] In this disclosure, the terms “connection setup” and “connection establishment” may be used interchangeably.

[0345] The terms AI / ML (Artificial Intelligence / Machine Learning) are used to describe any models and associated learning algorithms used by a WTRU (e.g., UE) and / or the network to predict future behavior (e.g., in the present disclosure, the behavior of the data arrival rate / amount at the WTRU to be sent to the network or from the network to the WTRU). The models and associated learning algorithms are assumed to utilize large datasets collected by WTRUs and / or the network that are currently or previously connected to the network. Details regarding the models and associated learning algorithms are outside the scope of the present disclosure. However, it can be assumed that the AI / ML mode makes predictions based on several conditions such as the current time, the current WTRU location, the WTRU mobility pattern, etc. For example, the AI / ML model may be able to predict future UL / DL data arrivals based on current and / or historical measurements of UL / DL data arrival / amount (e.g., considering the UL / DL data arrival rate / amount at a time of day and / or a location similar to the current time / location, or considering the current active bearers / applications).

[0346] At least some of the embodiments described in the present disclosure are independent / unrelated to the AI / ML models / techniques being used (e.g., the algorithms used, the mechanisms such as neural networks, or what kind of neural networks, e.g., the depth and parameters / weights of the network). However, it can be assumed that the WTRU has a pre-trained AI / ML model that can generate predictions of UL / DL data arrival rate / amount. For example, the model can be provided to the WTRU by the network (e.g., a mobile network) that the WTRU is registered with or seeking to register with, or the model can be loaded into the memory of the WTRU by the WTRU manufacturer or other provider.

[0347] In an embodiment, the prediction can be made for only one time point (e.g., the model generates an expected UL / DL data arrival rate / amount X milliseconds (ms) from the current time), or it can be extended over several time steps (e.g., in a time series of predictions for the next Y ms at intervals of every X ms).

[0348] As described above, the AI / ML model at the WTRU can be implementation-based (e.g., installed / provided by the WTRU vendor), or the WTRU can obtain the AI / ML model from the network (NW).

[0349] For any predicted value, the predicted value itself can be associated with and / or represented by a confidence or error tolerance limit, and can be represented by an average, peak, minimum, etc. along a short time window representing the validity of the prediction.

[0350] Furthermore, it is assumed that the following:

[0351] - There is some WTRU capability communication regarding AI / ML capabilities between the WTRU and the network (e.g., where the WTRU can indicate to the network the supported AI / ML models / functions, the confidence level of the prediction, e.g., the prediction time span (how far into the future the prediction is made));

[0352] - The WTRU can support several AI / ML models for a certain function (e.g., having different prediction time spans, prediction confidence levels, processing requirements, trained or for which trained under different cells / locations / time of day / application types);

[0353] - A given AI / ML model can operate in different modes (e.g., having different levels of prediction confidence levels within different prediction time spans);

[0354] - The WTRU can select an AI / ML model for a certain function (e.g., the network determines for which functions the WTRU can use AI / ML-based operations, and the WTRU selects an AI / ML model to use), or the network can explicitly control this (e.g., the WTRU provides details of one or more AI / ML models and their capabilities, and the network determines which one of the one or more models to activate for a specific function);

[0355] - The AI / ML model can be available at the WTRU where it has been trained, or the WTRU can be provided with an untrained AI / ML model and perform the training itself;

[0356] - The AI / ML model is available at the WTRU where it has been trained, and the WTRU can be enabled / configured to perform further training (e.g., for different conditions such as cells / locations / time of day, for conditions different from the initial training, for conditions the same as the initial training but for increasing the confidence level and / or prediction time span);

[0357]

[0358] - In the case of an output time series, the prediction confidence can be variable from one output to another (e.g., the confidence level of a prediction X ms away is higher than that of a prediction Y ms away, where Y > X);

[0359] ​- The prediction confidence level can be a percentage confidence (e.g., the expected likelihood that the prediction will become true), regarding an error tolerance (e.g., within Y ms, the predicted UL data rate is expected to be between X-(lower_error_margin) and X+(upper_error_margin)), or both a confidence percentage and an error tolerance (e.g., within Z ms, the predicted UL data rate is expected to be between X-(lower_error_margin) and X+(upper_error_magin)

[0360] and a confidence level of 90%); and / or

[0361] - For a given prediction time horizon, there can be different ranges of predicted values with different confidence levels or error tolerances (e.g., within Y ms, the predicted UL data rate is expected to be between X1-(lower_error_margin1) and X1+(upper_error_magin1) with a confidence level of 95%, and between X2-(lower_error_margin2) and X2+

[0362] (upper_error_magin2) with a confidence level of 85%).

[0363] In the present disclosure, the terms "expected", "anticipated", "estimated", "predictive", and "predicted" (and their adverbial variants) are used interchangeably.

[0364] In the present disclosure, the term "time horizon" is used to refer to the time (i.e., the incremental time from the current time) at which the WTRU expects the predicted UL data to arrive (i.e., be ready to transmit).

[0365] Also, in the present disclosure, the term "normal BSR" is used to describe the traditional BSR reports (e.g., up to NR rel-17) (e.g., regular BSR, padding BSR, periodic BSR) that are triggered when UL data actually arrives at the WTRU.

[0366] In an embodiment, the WTRU is configured to start performing early measurements in the idle / inactive mode based on the predicted UL data arrival.

[0367] In an embodiment, the WRTU may be configured to perform measurements when in an idle mode or an inactive mode, but the WRTU only starts performing measurements when it predicts that UL data is expected to arrive within a given configured time. This may be further constrained by the accuracy level (or error range) of the predicted configuration. For example, the WTRU may be configured to start performing measurements only when it is expected that UL data will arrive within x ms with an accuracy level of ≥90% (or an error level of ≤±y Kbits). In an embodiment, the accuracy level may be configured and / or determined based on the confidence level associated with the prediction of the AIML model.

[0368] In an implementation, the WTRU may be configured to perform measurements while in an idle or inactive mode, but the WTRU only starts performing measurements when it predicts that a certain amount of UL data is expected to arrive within a given configured time. This may be further constrained by the accuracy level (or error range) of the predicted configuration. For example, the WTRU may be configured to start performing measurements only when it is expected that at least k bits of UL data will arrive within x ms with an accuracy level of ≥90% (or an error level of ≤±Y k bits).

[0369] In a variant of the above embodiment, further granularity configuration may be provided to the WTRU, where the UL data volume is specific to a certain or certain types of services. For example, if the WTRU is in an inactive state or mode, the traffic volume may be associated with one of the LCIDs or bearer IDs of the saved WTRU context. As another example, the traffic volume may be associated with a certain QoS level of the service, for example, in terms of latency, bit rate, etc. As another example, the traffic volume may be associated with a specific application type (e.g., web browsing, streaming service). Different traffic volume levels may also be specified for different types of services. The traffic volume for a certain type of data (e.g., LCID, bearer ID, QoS level, application type) may be set to a very low value (e.g., 0) to indicate to the WTRU to start performing measurements in case any level of UL data is expected for this type of service.

[0370] In an embodiment, the WTRU may be configured to keep performing the measurements it has started based on any of the above conditions until the configured idle measurement duration expires.

[0371] In an embodiment, the WTRU may be configured to keep performing the measurements it has started based on any of the above conditions as long as the UL prediction is still met. For example, if at time t1, the WTRU has started measuring, and at time t2, the prediction now indicates otherwise (e.g., the predicted UL data is now below the configured threshold), then the WTRU may stop performing the measurements.

[0372] In an embodiment, the same configuration / behavior is applied to the idle and inactive modes.

[0373] In an embodiment, the configuration / behavior applied to the idle mode and the inactive mode is different (e.g., different parameters such as thresholds specified for the idle mode and the inactive mode).

[0374] In an embodiment, the same configuration / behavior is applied to all frequencies being measured (i.e., both NR and E-UTRA frequencies).

[0375] In an embodiment, different configurations / behaviors are applied for NR and E-UTRA frequencies. For example, different parameters such as thresholds are configured for NR and E-UTRA frequencies.

[0376] In an embodiment, the WTRU can be configured to apply different configurations / behaviors even for different frequency sets within NR and / or E-UTRA. For example, different parameters such as thresholds can be specified for NR FR1 frequencies and NR FR2 frequencies.

[0377] In an embodiment, the WTRU can be configured to apply different configurations / behaviors for different cell sets (intra-frequency or inter-frequency or inter-RAT). For example, the WTRU can be configured with different cell sets to measure, each cell set being associated with different parameters such as thresholds.

[0378] In an embodiment, the WTRU can be configured to apply traditional configuration / behavior (i.e., without considering UL data prediction) for certain frequencies of a given RAT, while being configured to apply a UL data prediction-based method according to any of the above embodiments for other frequencies of the given RAT. For example, the WRTU can be configured to apply traditional configuration / behavior for NR FR1 frequencies, but apply a UL data prediction-based method for NR FR2 frequencies.

[0379] In an embodiment, the WTRU can be configured to apply a UL data prediction-based method for a first set of pre-configured LCIDs, and apply traditional configuration / behavior for a second set of LCIDs. For example, the second set of LCIDs can be associated with services whose arrival patterns are difficult to predict or for which a UL prediction-based method is not desired. For example, the WTRU can be configured to perform measurements when conditions for the first set of LCIDs or the second set of LCIDs are met. For example, the conditions for the second set of LCIDs can be associated with transitioning to the idle / inactive mode, and measurements are performed within a duration corresponding to the idle measurement duration configuration or the expiration timer.

[0380] In an embodiment, the WTRU may be configured to start UL data arrival prediction according to pre-configured conditions. For example, the WTRU may be configured to perform legacy early measurements for a duration corresponding to an idle measurement duration and / or perform legacy early measurements until a timer expires. The WTRU may be configured to store the measurement results performed during this initial idle measurement duration (referred to herein as the initial idle measurement results). Once the timer expires, the WTRU may start UL data arrival prediction. Based on the results of the UL data arrival prediction, the WTRU may then perform measurements during subsequent idle measurement durations (referred to herein as subsequent idle measurement results). The WTRU may be configured to store the results of the subsequent measurement durations separately from the initial idle measurement duration.

[0381] In an embodiment, the WTRU may be configured to perform prediction of one or more measurement results at a future time.

[0382] In an embodiment, the WTRU may be configured to transmit the results of measurements based on UL and / or DL data prediction in an RRC message. For example, in an RRC resume request, RRC resume complete, RRC connection request, RRC setup request, RRC setup complete, RRC reconfiguration complete, WTRU assistance information, etc. In an embodiment, the WTRU may be configured to perform both legacy early measurements and idle measurements based on data arrival prediction. In an embodiment, the WTRU may send the results of measurements performed during the initial idle measurement duration and the subsequent idle measurement duration. In this case, the WTRU may explicitly or implicitly indicate the type of measurement results, e.g., the initial idle measurement results and / or the subsequent idle measurement results are included in the RRC message.

[0383] In an embodiment, the WTRU may be configured at a current time T to perform a prediction of measurements associated with a future time T+n. The time unit may be expressed as an offset in terms of symbols, number of time slots, subframes, radio frames, or milliseconds. Optionally, the WTRU may use a reference signal received at time t and one or more optional historical measurements (e.g., obtained at time t<T) to determine the measurement result at future time t+n. Optionally, the WTRU may initiate measurement prediction based on one or more criteria defined herein associated with UL / DL data arrival prediction. In an embodiment, the WTRU may be configured to send the result of the predicted measurements to the network in an RRC message. For example, in an RRC resume request, RRC resume complete, RRC connection request, RRC setup request, RRC setup complete, RRC reconfiguration complete, WTRU assistance information, etc. In an embodiment, the WRTU may be configured to perform measurement prediction during an initial idle measurement duration. In an embodiment, the WTRU may be configured to perform measurement prediction during a subsequent idle measurement duration. Such measurement prediction may be an alternative or supplement to direct measurements performed during idle and / or subsequent measurement durations. The WTRU may be configured to include in an RRC message, at the same time as or after transitioning to the connected mode, measurement results based on direct measurements (e.g., based on reference signal measurements or values derived therefrom) and / or based on predicted measurements (e.g., based on an AIML model).

[0384] In an embodiment, a WTRU may trigger a random access procedure to initiate an RRC connection or an RRC resume procedure. The WTRU may be configured to include the results of predicted measurements in one or more of RRC messages (RRC resume request, RRC resume complete, RRC connection request, RRC setup request, RRC setup complete, RRC reconfiguration complete, WTRU assistance information, etc.). For example, the WTRU may initiate a random access procedure at time T, and the WTRU may send a connection request or a resume request at time T+m. The WTRU may be configured to perform initial and / or subsequent idle measurements during time T-x (where x>0). In an embodiment, the WTRU may be configured to predict the measurement results at a future time T-y (where 0<y<x) based on reference signals received at time T-x and / or earlier. The WTRU may include the measurement results associated with time T-y in the RRC message sent at T+m. In an embodiment, after initiating a random access procedure at time T, the WTRU may continue to perform measurement prediction applicable to time T+n (where n>0, and even possibly n>m) using reference signals received until T+m or earlier. The WTRU may be configured to include the predicted measurement results associated with time T+n in the RRC message. The WTRU may be configured to include both direct measurement results and predicted measurement results in the RRC message. The WTRU may explicitly or implicitly indicate that the measurement results are prediction-based. The WTRU may also indicate at what time the predicted measurement results should be assumed to be applicable (e.g., T-y or T+n). Optionally, the WTRU may also include an accuracy level or a confidence level associated with the prediction. In an embodiment, the values of x, y, n, and m may be based on the WTRU capabilities and may be indicated by the WTRU to the network. In an embodiment, the values of x, y, n, and m may be configured by the network considering the WTRU capabilities.

[0385] In an embodiment, the WTRU may be configured to apply traditional configurations / behaviors to a certain set of cells (intra-frequency, inter-frequency, or inter-RAT) (i.e., without considering UL data prediction), while applying a UL data prediction-based method according to any of the above embodiments (or other means herein) to other sets of cells.

[0386] The WTRU may be configured to stop performing early measurements while in an idle / inactive mode based on predicted UL data arrival.

[0387] In an embodiment, the WTRU may be configured to start performing measurements while in an idle or inactive mode, as in a traditional mode (i.e., immediately or almost immediately after transitioning to the idle / inactive mode), but if the WTRU predicts that no UL data (or more than a certain amount of UL data) is expected to arrive within a given time, then the WTRU may even stop performing measurements before the configured idle measurement duration expires. This may be further constrained by the accuracy level (or error range) of the configured prediction. For example, assume the WTRU is configured with an idle measurement duration of 10 seconds and starts performing measurements immediately after entering the idle / inactive mode. After five seconds, if the WTRU determines that no UL data will arrive within the next 5 seconds within the configured accuracy (e.g., 90%), then the WTRU may stop performing measurements.

[0388] In a variant of the above embodiment, further granularity configuration may be provided to the WTRU, where the UL data prediction is related to a certain type of traffic (e.g., LCID, bearer ID, QoS level, application type). For example, the WTRU may be configured to stop measurements only based on the UL data prediction of a streaming application / bearer.

[0389] In an embodiment, the same configuration / behavior is applied to both the idle and inactive modes.

[0390] In an embodiment, the configuration / behavior applied to the idle mode and the inactive mode is different (e.g., different parameters, such as thresholds specified for the idle mode and the inactive mode).

[0391] In an embodiment, the same configuration / behavior is applied to all frequencies being measured (i.e., both NR and E-UTRA frequencies).

[0392] In an embodiment, different configurations / behavior are applied to NR and E-UTRA frequencies. For example, different parameters such as thresholds are configured for NR and E-UTRA frequencies.

[0393] In an embodiment, the WTRU may be configured to apply different configurations / behavior even to different frequency sets within NR and / or E-UTRA.

[0394] In an embodiment, the WTRU may be configured to apply different configurations / behavior to different cell sets (e.g., intra-frequency or inter-frequency or inter-RAT).

[0395] In an embodiment, the WTRU may be configured to apply traditional configuration / behavior (i.e., not considering UL data prediction) to certain frequencies of a given RAT, while applying a UL data prediction-based method to stop measurements of other frequencies of the given RAT based on any of the above solutions.

[0396] In an embodiment, the WTRU may be configured to apply traditional configurations / behaviors (i.e., stop measurements without considering UL data prediction) for certain cell sets (intra-frequency, inter-frequency, or inter-RAT), and apply UL data prediction-based methods according to any of the above embodiments (or otherwise herein) for other cell sets.

[0397] The WTRU may be configured to start / stop measurements based on UL data prediction provided by the network to the WTRU.

[0398] However, in the above embodiments, it is assumed that the behavior of the WTRU performing idle / inactive measurements is based on UL data prediction performed by the WTRU itself.

[0399] In an embodiment, the UL data prediction is performed by the network, and the network sends an indication of the UL data prediction to the WTRU. For example, the WTRU may receive a paging from the network (e.g., CN paging when in idle mode, RAN paging when in inactive mode), and the paging includes information related to the UL prediction performed by the network (e.g., whether there will be UL data within a given time range, the accuracy or error level of the prediction, and / or the expected traffic level). The WTRU may then apply a behavior similar to the behavior discussed above based on these predictions.

[0400] In an embodiment, the UL data prediction is performed by both the network and the WTRU, and the WTRU may make a decision based on either or both of these predictions, such as:

[0401] - WTRU prediction takes precedence

[0402] - Network prediction takes precedence

[0403] - The WTRU independently considers both predictions (e.g., start measurements based on WTRU prediction or the provided network prediction)

[0404] - The WTRU combines the two predictions (e.g., if the network predicts x Mbs of UL data and the WTRU predicts y Mbs of data, the WTRU will assume (x + y) / 2 Mbs of data; as another example, the WTRU may predict one traffic type and the network predicts another traffic type, and the WTRU has different thresholds associated with different traffic types and will thus consider both).

[0405] - The WTRU takes the prediction with the highest accuracy or / and the lowest error level

[0406] - Other examples are envisioned.

[0407] In an embodiment, instead of the network indicating UL data prediction information to the WTRU, the network can simply command the WTRU to stop / (re)start idle / inactive measurements, e.g., via a paging-like message.

[0408] The WTRU can be configured to start / stop measurements based on DL data prediction.

[0409] In the above embodiment, it is assumed that the behavior of the WTRU when performing idle / inactive measurements is based on UL data prediction (performed by the WTRU itself or provided by the network, e.g., via a paging-like message).

[0410] In an embodiment, the WTRU is also capable of predicting DL data traffic and can be configured to apply behavior similar to that described above for the embodiments based on UL data prediction to DL data traffic and DL data traffic prediction.

[0411] In an embodiment, DL data prediction is performed by the network and provided to the WTRU (e.g., in a paging-like message). This indication from the network can include information such as whether there will be DL data within a given time span, the accuracy or error level of the prediction, the expected traffic level, etc.

[0412] There are embodiments regarding how to configure the WTRU.

[0413] In an embodiment, the WTRU is configured with the parameters / behaviors discussed for any of the above embodiments when it is in the connected mode (e.g., in an RRC reconfiguration message).

[0414] In an embodiment, the WTRU is configured with the parameters / behaviors discussed for any of the above embodiments during the transition to the idle / inactive mode (e.g., in an RRC Release message).

[0415] In an embodiment, broadcast information (e.g., SIB) is used to configure the WTRU with the parameters / behaviors discussed for any of the above embodiments.

[0416] Combinations of all of the above are possible (e.g., a portion of the configuration provided in an RRC Reconfiguration message when the WTRU is in the connected state, an incremental configuration on top of the configuration provided in an RRC Release message, and / or the WTRU updating its configuration based on the SIB of the target cell when it performs cell reselection).

[0417] In an embodiment, the WTRU can indicate its data prediction capabilities to the network when the WTRU is in the connected mode. This can include information such as the (one or more) prediction time spans, confidence / accuracy / error levels, prediction granularity, etc.

[0418] In an embodiment, the WTRU may be configured by the network to use a specific prediction capability (or capabilities) (e.g., if the WTRU has multiple capabilities for making predictions, each with a different time span value and accuracy level, the network may indicate to the WTRU which one of the one or more capabilities to use).

[0419] In an embodiment, the WTRU is configured to indicate to the network (e.g., in an RRC resume complete message) the reason that the WTRU does not include a measurement report as part of or otherwise associated with the message, even if the network has indicated a request in the RRC resume message. The indication may inform the network of information such as:

[0420] - The current and / or predicted UL / DL traffic volume is not large enough (e.g., below a certain threshold)

[0421] - The current and / or predicted UL / DL traffic type does not require CA / DC (e.g., best effort traffic).

[0422] In an embodiment, the WTRU may include additional information related to the measurement report it is transmitting (e.g., in an RRC resume complete message, in the measurement report included in the message, or in an information element separate from the RRC resume complete message), such as time information related to earlier measurements (e.g., the time elapsed since the measurement was taken, the timestamp when the WTRU started performing the measurement).

[0423] In an embodiment, the WTRU transmits a current and / or predicted BSR to the network during connection setup or resume (e.g., in a BSR MAC CE multiplexed with msg3 or msg5, in one or more new IEs in the RRC resume complete message).

[0424] In an embodiment, the WTRU may perform measurements regardless of whether upcoming UL / DL traffic is determined to be needed. However, the WTRU may include indication information, such as whether CA and / or DC configuration is desired, or a predicted / current BSR (e.g., using any of the embodiments discussed above or in other ways herein).

[0425] In an embodiment, the predicted BSR transmitted by the WTRU during the resume / setup process may include more detailed information, such as a predicted traffic pattern for a longer duration.

[0426] In an embodiment, instead of the network indicating UL or / and DL data prediction information to the WTRU, the network may simply command the WTRU to stop / (re)start idle / inactive measurements, e.g., via a paging-like message.

[0427] In an embodiment, the WTRU may be capable of both UL and DL traffic prediction (or be provided with either or both of UL / DL data prediction from the network), and may be configured to apply behavior similar to the above solutions by considering either UL or DL prediction or a combination thereof. For example:

[0428] - UL prediction is prioritized (i.e., measurement decisions are based only on UL prediction)

[0429] - DL prediction is prioritized

[0430] - The WTRU may be configured with different parameters / thresholds for UL and DL traffic and may apply the corresponding behavior independently.

[0431] - The WTRU considers UL or DL prediction, depending on which has the highest accuracy or / and lowest error level.

[0432] - Other examples are envisioned.

[0433] In an embodiment, depending on the conditions, the start / stop behavior may be applied multiple times. For example, the WTRU may have stopped measurements based on a prediction performed at time t1, and if later at time t2, the prediction indicates differently (e.g., there will be UL data), the WTRU may resume measurements.

[0434] In an embodiment, the WTRU retains (e.g., stores in the memory on the WTRU) the measurement results it has performed, even after it has stopped measuring.

[0435] In an embodiment, the WTRU deletes the measurement results it has performed when it stops measuring.

[0436] In an embodiment, the WTRU may be configured with a certain validity duration, which indicates how long the WTRU may retain the stored measurements after it stops performing measurements.

[0437] In an embodiment, the WTRU may be configured to tag the measurements it is storing / retaining with timing information (e.g., each measurement sample is associated with a timestamp, a certain measurement set may be tagged with a duration, e.g., the duration between timestamp t1 and timestamp t2 or a start timestamp and a duration).

[0438] Figures 10 to 11 Some features of the embodiments disclosed above are shown.

[0439] In an embodiment, according to Figure 10In the figure, according to an embodiment, the WTRU 1000 is provided with a configuration related to early measurement configuration depending on traffic prediction (when in connected mode or when transitioning to inactive mode). The WTRU 1000 will not start performing the (one or more) measurements until the WTRU has predicted that UL data is predicted to arrive and the CA / DC setting is desired (e.g., a large amount of data is expected, the data belongs to a service that requires high reliability, where replication via CA or DC is needed). When the UL data arrives, the WTRU 1000 will send an RRC Resume Request message to the network 1002 and will send more up-to-date measurements indicating CA / DC candidate cells in the RRC Resume Complete message. If there are suitable cells for CA / DC, the network 1002 will configure the WTRU to use those cells.

[0440] Reference Figure 10 , at 1004, the WTRU 1002 is in RRC - connected mode.

[0441] At 1006, the network 1002 detects that the WTRU 1000 is not exhibiting activity, and at 1008, the network sends an RRC Reconfiguration message to the WTRU, which includes, for example, a configuration related to traffic prediction, and the WTRU configures itself to operate according to one or more of the configurations.

[0442] Alternatively, at 1010, the network 1002 sends an RRC Release message to the WTRU 1000 along with one or more early measurement configurations and a configuration related to traffic prediction, and the WTRU configures itself to operate according to one or more of the configurations.

[0443] At 1012, the WTRU 1000 enters and is in RRC inactive mode and does not perform early measurements during the interval 1014.

[0444] At 1016, the WTRU 1000 predicts that UL data with suitable prediction and data parameters (e.g., probability, accuracy, quantity, type, traffic) will arrive within a specific period (e.g., 5 ms, 10 ms).

[0445] At 1018, the WTRU 1000 determines that CA / DC is suitable for the predicted UL data traffic.

[0446] At 1020, while still in RRC inactive mode, the WTRU 1000 begins to perform and performs one or more early measurements regarding, for example, UL parameters such as data size, data throughput, number of carriers, or QoS of the (one or more) channels on which UL is to be transmitted or received or QoS for the channel.

[0447] During interval 1022, the WTRU 1000 continues to perform one or more early measurements.

[0448] At 1024, UL data arrives for the WTRU 1000 to send to the network 1002 or elsewhere.

[0449] At 1026, the WTRU 1000 sends an RRCResumeRequest to the network 1002, and at 1028, the network sends an RRCResume message to the WTRU and a request for the early measurements performed by the WTRU at 1020 and during 1022.

[0450] At 1030, the WTRU 1000 sends an RRCResumeComplete message to the network 1002 and a report of the early measurements performed by the WTRU at 1020 and during 1022.

[0451] At 1032, the WTRU 1000 transmits uplink data to the network 1002 while in RRC-connected mode.

[0452] At 1034, the network 1002 determines whether there are available candidate cells for the WTRU 1000 to operate in dual connectivity (DC) mode.

[0453] At 1036, the network 1002 sends an RRCReconfiguation message to the WTRU 1000, which includes, for example, one or more CA setup configurations and / or one or more DC setup configurations, and the WTRU configures itself accordingly to operate in CA / DC mode (or DC mode).

[0454] At 1038, the WTRU 1000 is configured and operates in CA / DC (or DC) mode suitable for the UL (and possibly other) data traffic that the WTRU is handling.

[0455] Figure 11 Is a diagram showing an embodiment where the WTRU 1100 determines that CA / DC settings are not required according to an embodiment.

[0456] Reference Figure 11 , at 1102, the WTRU 1100 is in RRC-connected mode.

[0457] At 1104, network 1106 detects that the WTRU 1100 is not exhibiting activity, and at 1108, the network sends a RRCReconfiguation message to the WTRU, which message includes configurations related to, for example, traffic prediction, and the WTRU configures itself to operate according to one or more of the configurations.

[0458] Alternatively, at 1110, network 1106 sends a RRCRelease message to the WTRU 1100 along with one or more early measurement configurations and traffic prediction related configurations, and the WTRU configures itself to operate according to one or more of the configurations.

[0459] At 1112, the WTRU 1100 enters and is in the RRC inactive mode and does not perform early measurements during interval 1114.

[0460] At 1116, the WTRU 1100 predicts that UL data with appropriate prediction and data parameters (e.g., probability, accuracy, quantity, type, traffic) will arrive within a specific time period (e.g., 5 ms, 10 ms).

[0461] At 1118, the WTRU 1000 determines that CA / DC is not appropriate or otherwise not required for the predicted UL data traffic.

[0462] During interval 1120, while still in the RRC inactive mode, the WTRU 1100 does not perform early measurements.

[0463] At 1122, UL data arrives for the WTRU 1100 to send to network 1106 or elsewhere.

[0464] At 1124, the WTRU 1100 sends a RRCResumeRequest to network 1106, and at 1126, the network sends a RRCResume message to the WTRU and a request for the results of early measurements that the network "believes" were taken by the WTRU.

[0465] However, since the WTRU 1100 did not perform early measurements, at 1128, the WTRU 1100 sends a RRCResumeComplete message to network 1106 along with an indication that the WTRU did not perform early measurements. For example, the lack of an early measurement report can indicate to network 1106 that the WTRU 1100 did not perform early measurements.

[0466] At 1130, the WTRU 1100 sends uplink data to network 1106 while in the RRC - connected mode.

[0467] At 1132, network 1106 sends an RRCReconfiguation message to WTRU 1100, which message includes or is accompanied by one or more configurations, and the WTRU configures itself accordingly to operate in an appropriate configuration.

[0468] Figure 12 FIG. is a diagram showing a WTRU provided with a configuration related to an early measurement configuration depending on traffic prediction (when in connected mode or when transitioning to inactive mode) according to another embodiment.

[0469] Reference Figure 12 , at 1200, WTRU 1202 is in RRC - connected mode.

[0470] At 1204, network 1206 detects that WTRU 1202 is not exhibiting activity, and at 1208, the network sends an RRCReconfiguation message to the WTRU, which message includes, for example, one or more traffic prediction - related configurations, and the WTRU configures itself to operate according to one or more of the configurations.

[0471] Alternatively, at 1210, network 1206 sends an RRCRelease message to WTRU 1202, as well as one or more early measurement configurations and / or trigger conditions for performing early measurements based on traffic prediction, and the WTRU configures itself to operate according to one or more of the configurations and / or trigger conditions.

[0472] At 1212, WTRU 1202 enters and is in RRC inactive mode, and does not perform early measurements during interval 1214.

[0473] During interval 1214, at 1216, WTRU 1202 predicts that UL data with appropriate prediction and data parameters (such as probability, accuracy, quantity, type, traffic) will arrive within a specific period (such as 5 ms, 10 ms).

[0474] Still during interval 1214, at 1218, WTRU 1202 determines that the predicted UL data traffic satisfies at least one trigger condition for performing one or more early measurements.

[0475] At 1220, while still in RRC - Inactive mode, the WTRU 1202 starts one or more early measurements, and during interval 1222, the WTRU 1202 performs one or more early measurements, for example, regarding UL parameters such as data size, data throughput, number of carriers, or QoS of the (one or more) channels on which UL is to be transmitted or received or the QoS for the channel.

[0476] At 1224, UL data arrives for the WTRU 1202 to send to the network 1206 or elsewhere.

[0477] At 1226, the WTRU 1202 sends an RRC Resume Request message to the network 1206, and at 1228, the network sends an RRC Resume message to the WTRU and a request for one or more early measurements performed by the WTRU at 1202 and during interval 1222.

[0478] At 1230, the WTRU 1202 sends an RRC Resume Complete message to the network 1206 along with a report of one or more early measurements performed by the WTRU during interval 1222. In addition to the report, the WTRU 1202 may also send, for example, UL traffic prediction and predicted BSR to the network 1206.

[0479] At 1232, the WTRU 1202 sends uplink (UL) data to the network 1206 or elsewhere while in RRC - Connected mode.

[0480] At 1234, the network 1206 determines whether there are available candidate cells for the WTRU 1202 to operate in dual - connection (DC) mode.

[0481] If at 1234 the network 1206 determines that there is at least one candidate cell available for the WTRU 1202 to operate in DC mode, then at 1236, the network 1206 sends an RRC Reconfiguation message to the WTRU 1202, which includes, for example, one or more CA setting configurations and / or one or more DC setting configurations, and the WTRU configures itself accordingly to operate in CA / DC mode (or DC mode).

[0482] At 1238, the WTRU 1000 is configured and operates in CA / DC (or DC) mode suitable for the UL (and possibly other) data traffic being processed by the WTRU.

[0483] Figure 13It is a flowchart of a method for performing measurements and reporting results in response to the satisfaction of a trigger condition according to an embodiment.

[0484] At 1300, a device such as a WTRU receives configuration information indicating one or more trigger conditions for performing measurements. For example, the WTRU may receive configuration information from a mobile network, and the trigger conditions may include thresholds, such as thresholds for data volume and / or channel QoS, may include data types (e.g., streams, voice), and / or may include data arrival times, and the measurements may include, for example, channel data capacity and / or throughput, channel QoS, channel fading, and / or carriers available on the channel.

[0485] At 1302, the WTRU performs one or more measurements in response to predicting the satisfaction of at least one of the one or more trigger conditions. For example, the WTRU may execute a prediction algorithm to predict one or more conditions, such as the arrival time of UL / DL data, the volume of UL / DL data, and / or the type of UL / DL, and if at least one of the one or more predicted conditions satisfies a corresponding threshold, the WTRU performs at least one of the one or more measurements. For example, the predicted data volume may be equal to or exceed the threshold required for the WTRU to perform one or more measurements, the predicted data arrival time may be equal to or less than the threshold required for the WTRU to perform one or more measurements, and / or the predicted data type may be the type required for the WTRU to perform one or more measurements.

[0486] And, at 1304, the WTRU sends a report based on the one or more measurements performed to, for example, a mobile network. For example, the report may include at least one of the one or more measurements and / or may include the (one or more) condition prediction results.

[0487] Although the features and elements are described above in specific combinations, those of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can 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 (sent via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memories, semiconductor storage devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media, such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receiving configuration information that indicates a trigger condition for measurements to be performed when operating at a first activity level; Receiving an indication of a transition from operating at a second activity level to operating at the first activity level; Performing measurements when operating at the first activity level in response to predicting that the trigger condition is met; And Sending a report based on the measurements in response to transitioning to the second activity level.

2. The method according to claim 1, wherein, The trigger condition includes a threshold amount of uplink traffic.

3. The method according to claim 1, wherein, Predicting that the trigger condition is met includes predicting that the uplink traffic will exceed the threshold.

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

5. The method according to claim 1, wherein Performing the receiving when operating at the second activity level, when transitioning from the second activity level to the first activity level, or when operating at the first activity level.

6. The method according to claim 1, wherein, The report includes an indication of the measurements, an indication of the current uplink traffic, or an indication of predicted uplink traffic.

7. The method according to claim 1, wherein The report includes an indication of a preference for carrier aggregation (CA) or dual connectivity (DC).

8. The method according to claim 7, wherein The indication is included in one or more of a connection establishment request message, a connection resume request message, a connection establishment complete message, or a connection resume complete message sent by the WTRU during or after transitioning to the second activity level.

9. The method according to claim 7, wherein The indication is excluded from any one of a connection establishment request message, a connection resume request message, a connection establishment complete message, and a connection resume complete message sent by the WTRU during or after transitioning to the second activity level.

10. The method according to claim 1 further comprises: Sending an indication of the traffic prediction capability of the WTRU, and receiving the configuration information in response to the indication of the traffic prediction capability of the WTRU.

11. The method according to claim 1, wherein The configuration information includes information for performing the prediction.

12. The method according to claim 11, wherein, The information for performing the prediction includes a configuration for an artificial intelligence machine learning (AI / ML) model or an indication of an AI / ML model.

13. The method according to claim 1, further comprising: Receiving configuration information for a CA mode; And Operating according to the CA mode.

14. The method according to claim 1, further comprising: Receiving configuration information for a DC mode; And Operating according to the DC mode.

15. A wireless transmit / receive unit (WTRU) configured to: Receive configuration information that indicates a trigger condition for measurements to be performed when operating at a first activity level; Receive an indication of a transition from operating at a second activity level to operating at the first activity level; Perform measurements when operating at the first activity level in response to predicting that the trigger condition is met; And Send a report based on the measurements in response to transitioning to the second activity level.

16. The WTRU according to claim 15, wherein The trigger condition includes a threshold amount of uplink traffic.

17. The WTRU according to claim 15, wherein Predicting that the trigger condition is met includes predicting that the uplink traffic will exceed the threshold.

18. The WTRU according to claim 15, wherein The first activity level is the Radio Resource Control (RRC) idle state or the RRC inactive state, and the second activity level is the RRC connected state.

19. The WTRU according to claim 15, configured to receive the indication when operating in the second activity level, when transitioning from the second activity level to the first activity level, or when operating in the first activity level.

20. The WTRU according to claim 15, wherein The report includes an indication of the measurement, an indication of the current uplink traffic, or an indication of the predicted uplink traffic.

21. The WTRU according to claim 15, wherein, The report includes an indication for the implementation of carrier aggregation (CA) or dual connectivity (DC).

22. The WTRU according to claim 15, wherein, The indication is included in one or more of a connection establishment request message, a connection resume request message, a connection establishment complete message, or a connection resume complete message sent by the WTRU during or after transitioning to the second activity level.

23. The WTRU according to claim 22, wherein, The indication is a report excluded from any one of a connection establishment request message, a connection resume request message, a connection establishment complete message, and a connection resume complete message sent by the WTRU during or after transitioning to the second activity level.

24. The WTRU according to claim 15, further configured to send an indication of the traffic prediction capability of the WTRU and receive the configuration information in response to the indication of the traffic prediction capability of the WTRU.

25. The WTRU according to claim 15, wherein The configuration information includes information for performing the prediction.

26. The WTRU according to claim 25, wherein, The information for performing the prediction includes a configuration for an artificial intelligence machine learning (AI / ML) model or an indication of an AI / ML model.

27. The WTRU according to claim 15, further configured to: receive configuration information for the CA mode; and operate according to the CA mode.

28. The WTRU according to claim 15, further configured to: receive configuration information for the DC mode; and operate according to the DC mode.

Images