Method and apparatus for transitioning between connected states in wireless communication network

Abstract

In an embodiment, a method implemented in a wireless transmit receive unit (WTRU) includes receiving information about a predictive data configuration from a network in one or more first messages, the information about the predictive data configuration indicates one or more trigger conditions for performing a connection with the network and indicates one or more data traffic prediction parameters; determining a data traffic prediction level based on the one or more data traffic prediction parameters while in an idle / inactive state; in response to determining that the data traffic prediction level satisfies at least one of the one or more trigger conditions, transmitting a second message to the network, the second message including request information for a connection and at least one cause value information for the connection; receiving a third message from the network, the third message comprising a response to the request for connection; and initiating a transition to the connected state.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 410,519, filed on September 27, 2022, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to methods and apparatus for a wireless transmit / receive unit to transition between connection states in a network based on predictions of future arrival of uplink or downlink data to be transmitted / received by the wireless transmitter / receiver unit WTRU. Background Art

[0004] The transition of a wireless transmitter / receiver (WTRU) unit from a connected mode to an inactive / idle state is currently mainly based on the network monitoring the activity level of the WTRU and deciding to transition the WTRU to the inactive / idle state. Thereafter, a WTRU that has entered the idle / inactive state may eventually transition back to the connected state soon due to the arrival of UL or DL ​​data. On the other hand, the WTRU may remain in the inactive / idle state for a long time, which means that it may be optimal for the network (and also for WTRU energy saving) to transition the WTRU to the inactive / idle state even earlier. The current mechanism for transitioning the WTRU from RRC_CONNECTED to RRC_INACTIVE / RRC_IDE or from RRC_INACTIVE / RRC_IDLE to RRC_CONNECTED is based only on the current data activity of the WTRU and may result in suboptimal resource utilization, unnecessary signaling and even suboptimal WTRU power usage.

[0005] There is a need to improve the current mechanisms to transition the WTRU from a connected state to an inactive / idle state or vice versa based not only on current data activity. Summary of the invention

[0006] In an embodiment, a method implemented in a wireless transmit receive unit WTRU may include the following steps: receiving information about a predictive data configuration from a network in one or more first messages, the information about the predictive data configuration indicating one or more trigger conditions for performing a connection with the network and indicating one or more data service prediction parameters. The method may also include the following steps: determining a data service prediction level based on the one or more data service prediction parameters when in an idle / inactive state. In response to determining that the data service prediction level satisfies at least one of the one or more trigger conditions, the method may include the following steps: transmitting a second message to the network, the second message including a request for a connection and at least one cause value for the connection. The method may also include: the step of receiving a third message from the network, the third message including a response to the request for a connection; and the step of initiating a transition to a connected state. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, each of the figures in such drawings is exemplary. Therefore, each of the figures and detailed description should not be considered limiting, and other equally effective examples are possible and possible. In addition, the same reference numerals ("reference numerals") in the various figures ("Figures") indicate the same elements, and wherein:

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

[0009] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the communication system is shown;

[0010] Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0011] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of yet another example RAN and yet another example CN used within the communication system shown;

[0012] Figure 2 is a signal flow diagram illustrating a radio resource control (RRC) connection / establishment procedure;

[0013] Figure 3 is a signal flow diagram illustrating a connection recovery process;

[0014] Figure 4 is a transition diagram illustrating different RRC states of a WTRU and the transitions therebetween;

[0015] Figure 5 is a diagram illustrating a short buffer status report BSR MAC CE;

[0016] Figure 6 is a diagram showing an extended short BSR;

[0017] Figure 7 is a diagram showing a long BSR MAC CE;

[0018] Figure 8 is a signal flow diagram illustrating the transfer of WTRU capability information between a WTRU and a network;

[0019] Fig. 9 is a signal flow diagram illustrating signal flow occurring between a WTRU and a network in response to a WTRU's predicted UL data according to an embodiment;

[0020] Fig.10 is a signal flow diagram illustrating signal flow between a WTRU and a network in response to a prediction that the WTRU will have no UL data for a period of time in accordance with an embodiment; and

[0021] Fig.11 is a flow chart illustrating an example of a method implemented in a WTRU for transitioning between connected states in a wireless communication network. DETAILED DESCRIPTION

[0022] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, procedures, components, and circuits are not described in detail to avoid obscuring the following description. In addition, embodiments and examples not specifically described herein can be practiced or combined with embodiments and other examples that are explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively referred to as "provided") herein.

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

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

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

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

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

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

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

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

[0031] 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, for example using dual connectivity (DC) principles. Thus, 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., eNBs and gNBs).

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

[0033] Figure 1A The base station 114b in the example may be, for example, a wireless router, a master Node B, a master eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement wireless technologies 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 wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-a Pro, NR, etc.) to establish a microcell or a femtocell. Figure 1A As shown, base station 114b may be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

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

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

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

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

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

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

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

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

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

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

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

[0045] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, frequency modulation (FM) wireless unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographic location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors and / or humidity sensors.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0059] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form the 40 MHz wide channel.

[0060] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, the data can be passed through a fragment parser after channel coding, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed on each stream respectively. The stream can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operation of the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0061] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in 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 can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0062] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, 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 operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports a 1MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

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

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

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

[0067] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as the eNode Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRU 102a, 102b, 102c may 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-standalone configuration, the eNode-B 160a, 160b, 160c may serve as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

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

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

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

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

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

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

[0074] Given that Figures 1A to 1D and Figures 1A to 1D 102a to 102d, base stations 114a to 114b, eNode-Bs 160a to 160c, MME 162, SGW 164, PGW 166, gNBs 180a to 180c, AMFs 182a to 182b, UPFs 184a to 184b, SMFs 183a to 183b, DNs 185a to 185b, and / or any other devices described herein. A simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0075] The simulation device can be designed to implement one or more tests of 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 when 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 when temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes, and / or can use over-the-air wireless communication to perform testing.

[0076] One or more simulation devices can perform one or more (including all) functions when not implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., testing) to implement testing of one or more components. One or more simulation devices can be test equipment. The simulation device can use direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) to transmit and / or receive data.

[0077] In NR (New Radio), a WTRU may be in one of three radio resource control (RRC) states: RRC_CONNECTED (also referred to herein as “connected mode”); RRC_INACTIVE (also referred to herein as “inactive mode”); RRC_IDLE (also referred to herein as “idle mode”).

[0078] In RRC_CONNECTED, the WTRU may be actively connected to the network, establish signaling and data radio bearers (signaling radio bearers (SRBs) and data radio bearers (DRBs)), and may be able to receive downlink (DL) data from the network and also send uplink (UL) data to the network in a unicast manner. The mobility of the WTRU from one cell / node to another is controlled by the network. The network may configure the WTRU to send measurement reports periodically or when certain conditions are met (e.g., a neighboring cell becomes better than the serving cell by more than a certain threshold), and based on these reports, a handover command may be sent to the WTRU to move the WTRU to another cell / node. The network may also be configured with conditional handover (CHO), where the WTRU executes a pre-configured handover command instead of sending a measurement report when certain conditions are met. The network may also send a handover (HO) command to the WTRU without receiving any measurement report (e.g., based on implementations such as determination of the current location).

[0079] Keeping the WTRU in the connected state / mode may be power intensive for the WTRU (e.g., the WTRU needs to continuously monitor the PDCCH (Physical Downlink Control Channel) of the serving cell, e.g., for determining the arrival of DL data, for UL data scheduling, etc.). In addition, a certain cell / gNB may be able to accommodate a certain number of WTRUs in connected mode (e.g., due to resource limitations). Therefore, the network may put the WTRU into the RRC_INACTIVE or RRC_IDLE state when there is no activity on the UL or DL ​​of the WTRU for a certain duration (e.g., based on an inactivity timer maintained at the network).

[0080] If the network expects the WTRU to be inactive for a long duration, it may put the WTRU into the RRC_IDLE state. While in RRC_IDLE, the WTRU may camp on the best cell (the cell with the best signal level in the highest priority RAT and with the highest priority frequency within that RAT), which will help the WTRU to establish a connection via that cell if the WTRU needs to transition back to the connected state. More details on the cell reselection process to ensure that the WTRU always camps on the best cell are given below. The WTRU may also monitor the downlink paging channel to monitor the arrival of DL data. If the WTRU detects a paging from the network indicating the arrival of DL data, or if the WTRU needs to send UL data, the WTRU may initiate a connection setup / establishment process.

[0081] During connection setup or recovery, the WTRU may perform a random access (RA) procedure (also referred to in this disclosure as a random access channel (RACH) procedure) before sending an RRCSetupRequest or RRCResumeRequest message. The RA procedure may serve two main purposes: UL synchronization between the WTRU and the network (e.g., gNB); and obtaining resources to be used to send the request message.

[0082] During the RA procedure, the WTRU may send a message (referred to as msg1) containing a preamble and RA-RNTI (Random Access - Radio Network Temporary Identifier) ​​to the gNB on the RACH. In the case of Contention Based Random Access (CBRA), the preamble may be randomly selected from a set of possible preamble values ​​(i.e., there may be contention if another WTRU uses the same preamble value to initiate a random access procedure). In the case of Contention Free Random Access (CFRA), the WTRU may be provisioned with a specific preamble in advance (e.g., when the WTRU is in a connected state, during a transition to an idle / inactive state, etc.). The RA-RNTI may be calculated based on the PRACH (Physical RACH) occasion on which the random access message will be sent to the network.

[0083] The gNB responds with msg2 containing a random access response (RAR) after receiving msg1. In order for the WTRU to detect the RAR, the network may also send a DCI (downlink control indicator) scrambled with the RA-RNTI in the PDCCH, which may be used by the WTRU to determine on which resources (e.g., time and frequency) the RAR (and other related information) is provided to the WTRU. The WTRU may attempt to detect the DCI within a period of time (referred to as the RAR window) after the preamble is sent. If such a DCI is not received, the WTRU may resend the preamble. If the DCI is received, the WTRU may detect the RAR at the indicated time and frequency resources in the PDSCH (physical downlink shared channel). In the RAR and associated information, the WTRU may be provided with the timing advance (TA) applied to send UL data, the TC-RNTI (temporary cell RNTI), and the UL resources for sending the setup / recovery request message.

[0084] The WTRU may obtain detailed information / configuration regarding the use of random access channels, such as RACH opportunities, random access response window, etc., when in a connected state, when transitioning during an idle / inactive state, or via dedicated configuration from a system information broadcast (SIB).

[0085] Figure 2 and Figure 3 The RRC connection establishment / setup procedure and the connection recovery procedure are shown respectively, as described in Sections 9.2.1.3 and 9.2.2.4.1 of TS38.300 [4] respectively.

[0086] The RA process, e.g., msg1 and msg2, is not shown in these figures. However, some of the subsequent signals, e.g., msg3, msg4, and msg5, are shown. For clarity, it should be noted that: msg3 corresponds to a message sent after receiving a RA response from the gNB (e.g., RRCResumeRequest or RRCSetupRequest); msg4 corresponds to a response from the network to msg3 sent from the UE (e.g., RRCResume or RRCSetup); and msg5 corresponds to a confirmation from the UE that msg4 was executed correctly (e.g., RRCResumeComplete or RRCSetupComplete). It should also be noted that if the WTRU resumes the connection in the same gNB, messages between the two gNBs and between the gNB and the core network (CN) CN may not be required, and therefore, the WTRU can recover without involving the CN.

[0087] If you can Figure 2As can be seen in Figure 1, the RRC connection setup procedure may be a lengthy process that requires several round trips to complete and involves the core network (CN). If the WTRU enters idle mode, the RRC context of the WTRU may be released and, therefore, the cellular network at the RAN level may not be aware of the WTRU. Therefore, the RAN may obtain the WTRU context from the CN. In addition, security may be reestablished thereafter and the WTRU may be reconfigured with DRBs and SRBs before UL / DL data transmission / reception occurs.

[0088] This lengthy setup process may not be compatible with low latency services, and therefore, NR introduces an intermediate state between the connected and idle states, called the inactive state. This state may have most of the energy-saving advantages of the idle state (for example, the WTRU does not need to continuously monitor the PDCCH, which is one of the most power-consuming processes in the connected state), but at the same time, the RAN still maintains the RRC / security context of the WTRU. When the WTRU needs to be transferred to the connected state / mode (for example, due to the arrival of UL data or the receipt of a paging indicating the arrival of DL data), the connection can be restored very quickly without involving the CN, reestablishing the WTRU's security context, or reconfiguring the bearers.

[0089] Figure 4 Summarizes the different RRC modes / states and the transitions between them.

[0090] When the WTRU performs a connection setup / establishment or resumption procedure, it may include (in the RRCSetupRequest or RRCResumeRequest) the establishment or resumption cause. Currently, the following causes may be defined:

[0091] EstablishmentCause::=ENUMERATED{

[0092] emergency,highPriorityAccess,mt-Access,mo-Signalling,

[0093] mo-Data,mo-VoiceCall,mo-VideoCall,mo-SMS,

[0094] mps-PriorityAccess,mcs-PriorityAccess,spare6,spare5,

[0095] spare4, spare3, spare2, spare1}

[0096] ResumeCause::=ENUMERATED{emergency,highPriorityAccess,

[0097] mt-Access,mo-Signalling,

[0098] mo-Data,mo-VoiceCall,mo-VideoCall,mo-SMS,rna-Update,

[0099] mps-PriorityAccess,mcs-PriorityAccess,

[0100] spare1,spare2,spare3,spare4,spare5}

[0101] For example, if the connection is being set up / restored due to a voice call or video call originating from the WTRU, the WTRU may set the establishment / restore 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 / restored due to a downlink paging indicating DL data, the WTRU will set the establishment / restore cause to one of mt-Access (mobile terminated access), highPriorityAccess, mps-PriorityAccess, or mcs-PriorityAccess (depending on the access category of the WTRU).

[0102] When the WTRU enters the inactive state, the network may include the suspendConFig in the Radio Resource Control Release (RRCRelease) message. The SuspendConfig contains information such as:

[0103] - resumeIdentity to be used by the WTRU (shortI-RNTI and longI-RNTI). The WTRU shall determine which identity to use based on the system information broadcasted in the target cell (eg, if useFullResumeID is indicated in the SIB, use the long identity; otherwise, use the short identity).

[0104] -RAN Paging Area (eg, cell list): This is the RAN area where the WTRU can be paged at the RAN level. If the WTRU performs a cell reselection to a cell outside the RAN area, the WTRU performs a RAN area update procedure.

[0105] -nextHopChaining count: This is used to derive security context (e.g., encryption / integrity protection keys) when resuming a connection.

[0106] The base station (gNB), in particular the MAC entity at the gNB, may be responsible for scheduling both uplink and downlink physical resources in NR.

[0107] In order to efficiently utilize the radio resources of the network and also in a manner that is fair to the different WTRUs being served by the network, the gNB may use information such as:

[0108] - Buffer status related to the WTRU (e.g., pending data to be transmitted in the DL of the WTRU at the gNB, UL buffer status reported by the WTRU, etc.)

[0109] -QoS requirements for each WTRU and associated radio bearer

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

[0111] - The 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 (eg, as indicated by a power headroom report from the WTRU).

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

[0113] In the uplink, the gNB can dynamically allocate resources to the WTRU via the C-RNTI on the PDCCH. The WTRU always monitors the PDCCH to find possible grants for UL transmissions. When CA (carrier aggregation) is configured, the same C-RNTI applies to all serving cells.

[0114] The gNB may cancel a PUSCH (Physical Uplink Shared Channel) transmission, or a repetition of a PUSCH transmission, or an SRS transmission of a WTRU to another WTRU with a latency critical transmission. The gNB may configure the WTRU to monitor for the cancel transmission indication using the CI-RNTI on the PDCCH.

[0115] In addition, through configured grants, the gNB can allocate uplink resources for the WTRU for initial HARQ transmission and HARQ retransmission. There are two types of configured uplink grants:

[0116] - Type 1: RRC directly provides configured uplink grants (including periodicity).

[0117] - Type 2: RRC defines the periodicity of the configured uplink grant, and the PDCCH sent to the CS-RNTI (Configured Scheduling-RNTI) can signal and activate the configured uplink grant, or deactivate it; that is, the PDCCH sent to the CS-RNTI indicates that the uplink grant can be implicitly reused according to the periodicity defined by RRC until deactivated.

[0118] For a given BWP (bandwidth part) of a serving cell, the WTRU may be configured with up to 12 active configured uplink grants. When more than one is configured, the network decides which of these configured uplink grants are active at a time (including all of them). Each configured uplink grant may be of type 1 or type 2. For type 2, activation and deactivation of configured uplink grants are independent between serving cells. When more than one type 2 configured grant is configured, each configured grant may be activated individually using a DCI command, and deactivation of a type 2 configured grant may be accomplished using a DCI command that may deactivate a single configured grant or multiple configured grants jointly.

[0119] For both dynamic grants and configured grants, for a transport block, two or more repetitions may be in one slot, or across slot boundaries in consecutive available slots, with each repetition being in one slot. For both dynamic grants and configured grant type 2, the number of repetitions may also be dynamically indicated in L1 signaling. The dynamically indicated number of repetitions shall override the RRC configured number of repetitions, if both are present.

[0120] Uplink Buffer Status Report (BSR) may be required to provide support for QoS-aware packet scheduling. In NR, BSR is reported at Logical Channel Group (LCG) granularity. A WTRU may be configured with up to 32 Logical Channel IDs (LCIDs) and these may be grouped into up to 8 LCGs. It should be noted that some special WTRUs may 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 may be configured with up to 65855 LCIDs and 256 LCGs).

[0121] The BSR can be sent in two formats: a short BSR format for reporting data for only one LCG; and a long BSR format for reporting data from multiple LCGs.

[0122] The BSR may be transmitted using a MAC Control Element (MAC CE). When a BSR is triggered (e.g., when new data arrives at the WTRU's transmit buffer), if the WTRU does not have any available UL grant to send the BSR, a Scheduling Request (SR) may be sent by the WTRU to request the required UL resources to transmit the BSR.

[0123] There are several variations of short BSR and long BSR (e.g., for the case of IAB MT), but for the sake of brevity, only a subset of them are included as follows. For details, the reader is referred to TS 38.321.

[0124] exist Figures 5 to 7 Some BSR formats are shown in Figure 5 The short BSR MAC CE shown, Figure 6 The extended short BSR shown and Figure 7 The long BSR MAC CE is shown.

[0125] The buffer size included in the BSR report may be encoded and decoded according to Table 1 and Table 2 below (eg, the WTRU may include an index corresponding to the buffer size of the corresponding LCG).

[0126] index BS value index BS value index BS value index BS value 0 0 8 ≤102 16 ≤1446 24 ≤20516 1 ≤10 9 ≤142 17 ≤2014 25 ≤28581 2 ≤14 10 ≤198 18 ≤2806 26 ≤39818 3 ≤20 11 ≤276 19 ≤3909 27 ≤55474 4 ≤28 12 ≤384 20 ≤5446 28 ≤77284 5 ≤38 13 ≤535 21 ≤7587 29 ≤107669 6 ≤53 14 ≤745 22 ≤10570 30 ≤150000 7 ≤74 15 ≤1038 23 ≤14726 31 >150000

[0127] Table 1: Buffer size levels (in bytes) for the 5-bit buffer size field

[0128]

[0129]

[0130]

[0131]

[0132] Table 2: Buffer size levels (in bytes) for the 8-bit buffer size field

[0133] RRC can configure the following parameters to control BSR:

[0134] -periodicBSR-Timer;

[0135] -retxBSR-Timer;

[0136] -logicalChannelSR-DelayTimerApplied;

[0137] -logicalChannelSR-DelayTimer;

[0138] -logicalChannelSR-Mask;

[0139] -logicalChannelGroup.

[0140] The MAC entity may determine the amount of UL data available for the logical channel based on a data amount calculation process performed at the Radio Link Control (RLC) and the Packet Data Convergence Protocol (PDCP).

[0141] When performing data amount calculation, the RLC may include RLC data PDUs waiting to be transmitted or retransmitted, RLC service data units (SDUs) (or fragments of RLC SDUs) not yet included in the RLC data PDUs, and any pending RLC status PDUs (see TS 38.322 [1]).

[0142] The data volume calculation at the PDCP may take into account the PDCP SDUs for which a PDCP data PDU has not yet been constructed, the PDCP data PDUs that have not yet been transmitted to lower layers, any PDCP control PDUs, and any PDCP SDUs or PDUs to be retransmitted due to PDCP re-establishment or PDCP data recovery (see TS 38.323 [2]).

[0143] The WTRU may trigger a BSR if any of the following events occurs:

[0144] -UL data for logical channels belonging to the LCG becomes available to the MAC entity; and

[0145] - the UL data belongs to a logical channel having a higher priority than any logical channel containing available UL data belonging to any LCG; or

[0146] - None of the logical channels belonging to the LCG contains any available UL data, in which case the BSR is called a "Normal BSR";

[0147] - 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 subheader, in which case the BSR is called a "padding BSR";

[0148] -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 called a "regular BSR";

[0149] -periodicBSR-Timer expires, in which case the BSR is called a "periodic BSR".

[0150] When regular BSR triggering events occur on multiple logical channels simultaneously, each logical channel may trigger a separate regular BSR.

[0151] A Scheduling Request (SR) may be used to request uplink shared channel (UL-SCH) resources for a new transmission.

[0152] The MAC entity may be configured with zero, one, or multiple SR configurations. The SR configuration may include a set of PUCCH resources for SR across different BWPs and cells. Each BWP may be configured with at most one PUCCH resource for SR.

[0153] Each SR configuration may correspond to one or more logical channels. Each logical channel may be mapped to zero or one SR configuration configured by RRC. The SR configuration of the logical channel that triggers the BSR may be considered as the corresponding SR configuration for the triggered SR.

[0154] RRC can configure the following parameters for the scheduling request process: sr-ProhibitTimer (configured per SR); sr-TransMax (configured per SR).

[0155] The following WTRU variables may be used for the scheduling request procedure: SR_COUNTER (per SR configuration).

[0156] If a SR is triggered and there is no other SR pending corresponding to the same SR configuration, the MAC entity may set the SR_COUNTER of the corresponding SR configuration to 0.

[0157] When a SR is triggered, it can be considered pending until it is canceled.

[0158] All pending SRs for BSRs triggered according to the BSR procedure before MAC PDU assembly may be canceled and each corresponding sr-ProhibitTimer may be stopped when the MAC PDU is transmitted and the PDU may include a long or short BSR MAC CE (which contains the buffer status up to (and including) the last event that triggered the BSR before MAC PDU assembly). When the UL grant can accommodate all pending data available for transmission, all pending SRs for BSRs triggered according to the BSR procedure may be canceled and each corresponding sr-ProhibitTimer may be stopped.

[0159] Only PUCCH resources on the BWP that are active at the time of the SR transmission opportunity may be considered valid.

[0160] 3GPP has started studying the use of artificial intelligence / machine learning (AI / ML) mechanisms to optimize the operation of the radio access network (RAN). For example, in the rel-17 study on enhancing data collection for NR and EN-DC, several use cases have been identified [TS 37.817[3]], such as: network energy saving, load balancing, and mobility optimization.

[0161] AI / ML models may be proposed to be used by the network and / or WTRU to predict different aspects such as WTRU trajectory, WTRU traffic, serving and neighbor cell signal levels, etc. And based on these predictions, the network can make more optimized and proactive decisions instead of the traditional way of operating in a reactive manner (e.g., handover when the signal level of a neighbor cell becomes better than the serving cell, traffic steering / load balancing once the serving cell becomes overloaded, etc.).

[0162] The prediction may be made by the network, the WTRU, or a collaboration between the two. For example, in areas related to traffic prediction, an AI / ML model may be provided to the WTRU (e.g., provided by the network, a proprietary model of the WTRU vendor or operator, etc.), and once the model is well trained (e.g., trained for a specific period of time until the WTRU verifies that the prediction has a specific acceptable level of accuracy or error tolerance), the WTRU may be configured to send a predictive BSR even before the actual traffic arrives at the WTRU buffer, thereby giving the network lead time and enabling it to make more optimized decisions (e.g., granting more configured / dynamic grants, configuring additional carriers or / and dual connectivity, preemptively offloading the associated WTRU or other WTRUs to neighboring cells, etc.) to ensure that resources will be available to the WTRU when the predicted data is actually available and ready to be sent at the WTRU buffer.

[0163] like Figure 8As shown, in NR, the WTRU may compile and may transmit its WTRU capability information after receiving a UECapabilityEnquiry message from the network by sending a UECapabilityInformation message.

[0164] When the network requires (additional) WTRU radio access capabilities information, the network may initiate this procedure to the WTRU in RRC_CONNECTED mode. The network may retrieve WTRU capabilities only after AS (Access Stratum) security activation. The network may not forward WTRU capabilities retrieved before AS security activation to the CN.

[0165] The WTRU capabilities may be requested per radio access technology (RAT) type (e.g., NR, EUTRA, etc.) Since the size of all WTRU capability information may be large and the network may already have some of the WTRU's capability information (e.g., from an earlier capability transfer from the WTRU, from an earlier capability transfer from the CN, etc.), additional filters may also be included in the capability request to limit the UL signaling.

[0166] Another issue relates to the WTRU transitioning between different activity levels, e.g., from connected to inactive / idle and vice versa. The current mechanism for transitioning a WTRU from RRC_CONNECTED to RRC_INACTIVE / RRC_IDE / RRC_INACTIVE / RRC_IDLE to RRC_CONNECTED may be based solely on the WTRU's current data activity and may result in suboptimal resource utilization, unnecessary signaling and even suboptimal WTRU power usage.

[0167] Thereafter, a WTRU that has entered the idle / inactive state may quickly transition back to the connected state due to the arrival of UL or DL ​​data. On the other hand, a WTRU may remain in the inactive / idle state for a long time, which means that it may be optimal for the network (and also for WTRU energy saving) to transition the WTRU to the inactive / idle state even earlier.

[0168] In the following discussion, the term AI / ML is used to describe any model and associated learning algorithm used by the WTRU and / or the network to predict future behavior (in the present disclosure, behavior at the WTRU or data arrival to be sent to the network). It may be assumed that the model and associated learning algorithm utilize a large set of data collected by the WTRU and / or the network. Details regarding the model and associated learning algorithm are beyond the scope of this disclosure. However, it may be assumed that the AI / ML model can make predictions based on several conditions such as the current time, the current WTRU location, the WTRU mobility pattern, etc.

[0169] In the following discussion, the terms "mode" and "state" may be used interchangeably (eg, idle mode and idle state).

[0170] In the following discussion, the terms "data volume / type" and "traffic volume / type" are used interchangeably.

[0171] In the following discussion, the terms "connection setup" and "connection establishment" are used interchangeably.

[0172] In the following discussion, the terms "anticipated," "expected," "estimated," "predictive," and "predicted" (and adverbial variations thereof) are used interchangeably.

[0173] In the following discussion, the term "time horizon" is used to refer to the time (ie, delta time from the current time) at which the UL data is expected to arrive (ie, be ready to be sent) by the WTRU.

[0174] In the following discussion, the term “normal BSR” is used to describe the traditional BSR (e.g., regular BSR, padding BSR, periodic BSR, etc.) reported until NR rel-17 which is triggered when UL data actually arrives at the WTRU.

[0175] The WTRU is configured to trigger a connection setup or resumption based on predicted UL data arrival

[0176] In some embodiments, the WTRU may be configured to trigger a connection setup (if in an idle state) or a connection recovery (if in an inactive state) when it predicts that UL data is expected to arrive within a given configured time. This may be further constrained by a configured accuracy level (or error range) of the prediction. For example, if UL data is expected to arrive within x ms with an accuracy level of 90% (or an error level of ±y kilobits), the WTRU may be configured to trigger a connection setup or recovery. More than one such configuration may be provided for the WTRU. For example, if UL data is expected to arrive within x ms with an accuracy level a1, or if UL data is expected to arrive within y ms with an accuracy level a2, etc., the WTRU may be configured to trigger a connection setup or recovery.

[0177] In some embodiments, the WTRU may be configured to trigger a connection setup or connection recovery 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 a configured accuracy level (or error range) of the prediction. For example, the WTRU may be configured to trigger a connection setup / recovery if at least A kilobits of UL data are expected to arrive within x ms with a 90% accuracy level (or an error level of ±y kilobits). In some embodiments, the accuracy level may be configured and / or determined based on a confidence level associated with the prediction of the AIML model. The WTRU may be configured with multiple such configurations (i.e., different amounts of data, different time ranges, different accuracy levels).

[0178] In a variation of the above embodiment, a further granular configuration may be provided to the WTRU, where the UL data volume is specific to a particular type of service. For example, if the WTRU is in an inactive mode, the traffic volume may be associated with one of the LCID or bearer ID of the saved WTRU context. As another example, the traffic volume may be associated with a particular 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 particular application type (e.g., web browsing, streaming media services, etc.). Different traffic volume levels for different types of services may also be specified. The traffic volume of a particular type of data (e.g., LCID, bearer ID, QoS level, application type, etc.) may be set to a very low value, such as 0, to indicate to the WTRU that a connection setup / recovery is triggered when any level of UL data is expected for this type of service. In an embodiment, the WTRU may be configured with a traffic volume threshold for state transition based on a UL data prediction for a subset of data streams (e.g., LCID, bearer ID, QoS level, application type, etc.). In a first example, one or more data streams may be configured with a very high data volume threshold (e.g., infinity). In a second example, one or more data flows may not be configured / associated with any data volume threshold. In both examples, the WTRU may disable UL data prediction for those configured data flows and may not trigger an RRC connection request and / or a resumption request based on data arrival prediction. The WTRU may be configured with several such configurations (e.g., different traffic types, different data volumes, different time ranges, different accuracy, etc.).

[0179] In some embodiments, the same configuration / behavior may apply to both idle and inactive states.

[0180] In some embodiments, the configuration / behavior applied to the idle and inactive states may be different (eg, different parameters, such as thresholds specified for the idle versus inactive states).

[0181] The WTRU is configured to trigger connection setup or resumption based on predicted DL data

[0182] In the above embodiments, it is assumed that the WTRU behavior to trigger the connection setup / resumption may be based on UL data prediction (performed by the WTRU itself or provided by the network, for example, via a paging-like message).

[0183] In some embodiments, the WTRU may also be able to predict DL data traffic and may be configured to apply similar behavior as the above embodiments to trigger connection setup / resumption based on DL data prediction.

[0184] In some embodiments, the network may be able to predict the arrival of future DL data. The WTRU may be configured to receive an indication of the upcoming arrival of DL data from the network and then trigger a connection setup or recovery process at a future preconfigured time that may be closer to the timing of the actual DL data arrival or consistent with the timing of the actual DL data arrival. For example, the WTRU may receive a paging message from the network, and the paging message may additionally indicate the cause of the paging. For example, a new access type indicating the predicted arrival of DL data may be defined. Additionally, the WTRU may receive an indication of the timing of the arrival of DL data. Possibly, the timing may be expressed as an offset in terms of a time slot, a subframe, or a number of ms relative to the actual DL data arrival. The WTRU may be configured to initiate a random access process at the earliest available RACH opportunity immediately after the offset time from the paging message. Such an embodiment may be beneficial in reducing the latency between the arrival of DL data at the network and the delivery of DL data to a WTRU in an idle / inactive state. Possibly, such a paging message with predicted DL data arrival may carry the configuration of CFRA (contention-free random access) resources. Possibly, such CFRA resources may be configured to be valid only for the purpose of connection setup with predicted DL data arrival. Possibly, such CFRA resources may be configured to be valid for a pre-configured duration starting from an offset time. The above embodiments may also be extended to use cases where the network may also predict UL data traffic arrival.

[0185] In some embodiments, the WTRU may be configured with multiple thresholds (e.g., a first threshold and a second threshold) associated with the prediction of UL data arrival, where satisfying each threshold results in a different action for the WTRU. In one example, the threshold may be associated with the amount of data (e.g., the first threshold may correspond to a first data amount value / range, and the second threshold may correspond to a second data amount value / range). In another embodiment, the threshold may be associated with a configured time frame (e.g., the first threshold may correspond to a first time frame, and the second threshold may correspond to a second time frame). In another embodiment, the threshold may be associated with a predicted accuracy level / confidence level (e.g., the first threshold may correspond to a first accuracy level / confidence level, and the second threshold may correspond to a first accuracy level / confidence level). In yet another embodiment, the threshold may be associated with a combination of predicted data amount, time frame, and confidence level. In some embodiments, the WTRU may be configured with different actions based on determining whether the UL data prediction satisfies the first threshold or the second threshold. For example, if the UL data prediction satisfies the first threshold, the WTRU may start an early measurement process, and if the UL data prediction satisfies the second threshold, the WTRU may trigger a transition to a connected state and transmit a connection request or a recovery request.

[0186] The WTRU is configured to indicate a connection setup or resumption reason based on predicted UL / DL data

[0187] In some embodiments, the WTRU may be configured to include a cause value in a connection setup / resumption request message (e.g., RRCSetupRequest, RRCResumeRequest) indicating that the connection setup / resumption request is due to predicted UL data (e.g., introducing a new cause value indicating that mobile initiated data is predicted, e.g., mo-Data-predicted).

[0188] In some embodiments, the WTRU may be configured to include a cause value in the connection setup / resumption request indicating that the setup / resumption request is due to predicted DL data (e.g., introducing a new cause value indicating predicted mobile terminated data, e.g., mt-Data-predicted).

[0189] In some embodiments, the WTRU may be configured to include in the connection setup / resumption request message a cause value indicating that the setup / resumption request is due to predicted UL or / and DL data (e.g., introducing a new cause value indicating that UL or DL ​​data is predicted, e.g., predicted-Data; introducing a new cause value indicating that both UL and DL data are predicted, e.g., mt-and-mo-Data-predicted).

[0190] In some embodiments, the WTRU may be configured to implicitly indicate that a connection is being setup / resume due to predicted traffic. For example, the WTRU may be configured with certain dedicated RACH preambles that may be used during a RACH procedure prior to sending a setup / resume request associated with data prediction. For example, the WTRU may be configured with preamble 1, preamble 2, and preamble 3, and if a connection is being setup / resume due to UL data prediction, preamble 1 is used, if a connection is being setup / resume due to DL data prediction, preamble 2 is used, and if a connection is being setup / resume due to both UL and DL data prediction, preamble 3 is used.

[0191] In some embodiments, the WTRU may be configured to indicate additional information about predicted UL and / or DL ​​data during connection setup / request. For example, the additional information may include specific data streams associated with the UL and / or DL ​​data prediction (e.g., LCID, bearer ID, QoS level, application type, etc.). For example, the additional information may include the accuracy / confidence level of the prediction. Alternatively or in addition, the additional information may include a time offset from the arrival of the predicted data. In one embodiment, the indication may be explicit, for example, included in a connection setup / recovery request. In another embodiment, the indication may be implicit, for example, may be indicated via selection of a RA resource pre-configured for a specific value and / or value range associated with one or more of the above-mentioned additional information.

[0192] In some embodiments, the WTRU may indicate only the legacy cause value in the RRCSetupRequest or RRCResumeRequest message, but the network may request (e.g., in the RRCSetup or RRCResume message) an indication of whether the WTRU is resuming the connection due to a prediction of data arrival or actual data arrival. The WTRU may send a response in the RRCSetupComplete or RRCResumeComplete message.

[0193] In some embodiments, the WTRU may be configured with different RACH related settings (e.g., power level to use, power ramp parameters during preamble retransmissions, RAR window, RACH timing, etc.) for use in situations where a connection setup / recovery is performed due to predicted UL data rather than actual data arrival. In another embodiment, the RACH related settings may be configured as a function of the accuracy level and / or confidence level associated with the prediction.

[0194] The WTRU is configured to indicate the predicted traffic volume during connection setup / restore

[0195] In some embodiments, the WTRU may be configured to implicitly indicate the amount of predicted traffic during connection setup / resumption. For example, the WTRU may be configured with certain dedicated RACH preambles (i.e., msg1) associated with different levels of traffic that may be used during the RACH procedure. For example, the WTRU may be configured with preamble 1, preamble 2, preamble 3, and preamble 4, and if the connection is being setup / resumption due to a low amount of UL data being predicted, preamble 1 is used, if the connection is being setup / resumption due to a medium amount of UL data being predicted, preamble 2 is used, if the connection is being setup / resumption due to a high level of UL data being predicted, preamble 3 is used, and if the connection is being setup / resumption due to a very high amount of UL data being predicted, preamble 4 is used. Similarly, preambles associated with the amount of DL data (or a combination of UL / DL data amounts) may be configured. Preambles associated with predicted time ranges may also be configured (e.g., a certain set of preambles for time ranges less than a certain amount, another set of preambles for time ranges between two time values, etc.). Instead of or in addition to identification via the preamble, other alternatives may be used, such as using a specific beam (or using the associated RACH opportunity to send a setup / restore request if the setup / restore is triggered due to predicted data).

[0196] In some embodiments, the WTRU may send msg1 as described above implicitly indicating the predicted traffic volume, but may not receive a response thereto (ie, no msg2).

[0197] In some embodiments, the WTRU may receive msg2 (eg, including a RAR including information such as TA, TC-RNTI), but it may not have received any UL grant. This may indicate to the WTRU not to proceed with msg3.

[0198] In some embodiments, the WTRU may receive msg2 (e.g., including a RAR containing information such as TA, TC-RNTI), but the specified UL grant may indicate a future allocation (e.g., a time range based on traffic prediction) rather than a current / immediate grant. This may indicate to the WTRU not to proceed immediately with msg3, but rather to proceed with msg3 at a specified time in the future.

[0199] In some embodiments, the WTRU may receive msg2 including a RAR indicating to the WTRU an action related to the prediction. For example, the WTRU may receive an indication in the RAR that a connection request / resumption based on prediction should be disabled. For example, the WTRU may be configured to disable access attempts based on prediction for a preconfigured duration. Possibly, the preconfigured duration may be explicitly indicated in the RAR message or as part of the inactive configuration, or predefined in the standard. Possibly, the preconfigured duration may be infinite, i.e., until explicitly activated by the network.

[0200] In some embodiments, the WTRU may be configured to indicate the predicted level of traffic during connection setup / resumption by including this information in a connection setup / resumption request message (e.g., RRCSetupRequest, RRCResumeRequest). For example, an information element (IE) may be introduced (e.g., predicted traffic level), which may take specific values ​​(e.g., 2 bits: 00 indicates low amount, 01 indicates medium amount, 10 indicates high amount, and 11 indicates very high amount). Two separate IEs may be used to indicate UL and DL data prediction.

[0201] In some embodiments, the WTRU may be configured to indicate the level of predicted traffic during connection setup / recovery by including this information in the connection setup / recovery complete message (e.g., RRCSetupComplete, RRCResumeComplete). For example, an IE (e.g., predicted traffic level) may be introduced which may take specific values ​​(e.g., 2 bits: 00 indicates low amount, 01 indicates medium amount, 10 indicates high amount, 11 indicates very high amount). Two separate IEs may be used to indicate UL and DL data predictions. As another example, for a WTRU that is in an inactive state and has a WTRU context, information similar to a BSR report may be included (e.g., indexed traffic volume per LCG or even LCID), since the recovery / setup complete message is not size-limited like a request message. In some examples, the predictive BSR report may include additional information, such as a time range and accuracy level. In another example, the time range and accuracy level may be implicitly known by the network from the configuration it has provided to the WTRU.

[0202] In some embodiments, the predictive BSR may be sent as a MAC CE multiplexed with an RRCSetupRequest or RRCResumeRequest message (eg, within the same MAC transport block).

[0203] In some embodiments, the predictive BSR may be sent as a MAC CE sent immediately after an RRCSetupRequest or RRCResumeRequest message (eg, within a different MAC transport block).

[0204] In some embodiments, the predictive BSR may be sent as a MAC CE multiplexed with an RRCSetupComplete or RRCResumeComplete message.

[0205] In some embodiments, the predictive BSR may be sent as a MAC CE sent immediately after an RRCSetupComplete or RRCResumeComplete message.

[0206] In some embodiments, the WTRU may be configured to trigger connection setup / resumption as in a legacy system (e.g., based solely on UL data arrival or a paging from the network indicating DL data arrival), but it may use any of the above mechanisms to indicate the latest predicted UL and / or DL ​​traffic levels (e.g., using a new IE in the setup / resumption request message, using a RACH preamble, etc.).

[0207] In some embodiments, the WTRU may be configured to trigger connection setup / resumption as in a conventional system (e.g., based solely on UL data arrival or a paging from the network indicating DL data arrival), but it may use any combination of the above embodiments to indicate the current UL traffic level (i.e., data available at the WTRU) as well as the predicted UL and / or DL ​​traffic levels (e.g., using a new IE in the setup / resumption request message for current and predicted data amounts, using the RACH preamble for prediction while using the IE in the request message for current values, using an IE in the setup / resumption request message for current data amount indication while using the setup / resumption complete message for predicted data amounts, etc.).

[0208] In some embodiments, the network may request the WTRU to send information about the predicted traffic during the setup / resumption process. This may be, for example, in the RRCResume / RRCSetup message (e.g., a new IE), or in the Random Access Response message (e.g., a specific RAR preamble or RAR) before sending the setup / resumption request.

[0209] How WTRU configuration may be performed

[0210] In some embodiments, the WTRU may be configured with the parameters / behaviors discussed in connection with any of the embodiments discussed above while in the connected mode / state (eg, in an RRC reconfiguration message).

[0211] In some embodiments, the WTRU may be configured with the parameters / behaviors discussed in connection with any of the embodiments discussed above during transition to idle / inactive mode (eg, in an RRCRelease message).

[0212] In some embodiments, the WTRU may be configured with the parameters / behaviors discussed in connection with any of the embodiments discussed above using broadcast information (eg, SIB).

[0213] Combinations of all of the above are possible (e.g., part of the configuration provided in RRCReconfiguration when the WTRU is connected, incremental configuration on top of the configuration provided in RRCReelease, SIB update configuration based on the target cell when the WTRU performs cell reselection, etc.).

[0214] In some embodiments, the WTRU may indicate its data prediction capabilities to the network while in a connected state. This may include information such as prediction time horizon, confidence / accuracy / error level, prediction granularity, etc.

[0215] In some embodiments, the WTRU may be configured by the network to a specific prediction capability (or capabilities) to use (e.g., if the WTRU has multiple capabilities for making predictions, each with a different time range value and level of accuracy, the network may instruct the WTRU which of those capabilities to use).

[0216] Other aspects

[0217] In some embodiments, the WTRU may detect that UL data is about to arrive based on some actions of the user rather than an AI / ML model (eg, detecting that the user has unlocked the screen, etc.).

[0218] In some embodiments, the WTRU may be capable of both UL and DL traffic prediction (or provide either or both UL / DL data prediction from the network) and may be configured to apply similar behavior to the above embodiments by considering UL prediction, DL prediction, or a combination thereof. For example:

[0219] - UL prediction can take precedence over DL prediction (i.e. setup / restore decisions based on UL prediction only);

[0220] -DL prediction can take precedence over UL prediction;

[0221] - The WTRU may be configured with different parameters / thresholds for UL and DL traffic and apply corresponding behaviors independently;

[0222] - The WTRU may consider either UL or DL ​​prediction, depending on which has the highest accuracy and / or lowest error level.

[0223] In some embodiments, the WTRU may predict UL data arrival based on some actions of the user rather than an AI / ML model (e.g., detecting that the user has unlocked the screen, etc.).

[0224] In some embodiments, the WTRU may initiate a recovery / setup procedure according to any of the above embodiments, but the network may respond with an RRCRelease message instead of an RRCSetup or RRCResume message, thereby keeping the WTRU in RRC_IDLE or RRC_INACTIVE state. In one such example, the network may provide the WTRU with some additional information to use when actual data arrives (e.g., UL resources for sending data).

[0225] In some embodiments, the WTRU may be configured to trigger a connection release when it is predicted that there will be no UL data activity for a considerable period of time (e.g., a configured time range). This may be further constrained by a configured accuracy level (or error range) of the prediction. For example, the WTRU may be configured to trigger a connection release if no UL data is expected to arrive within x ms with an accuracy level of 90% (or an error level of ±y kilobits). More than one such configuration may be provided for the WTRU. For example, the WTRU may be configured to trigger a connection release if no UL data is expected to arrive within x ms with an accuracy level a1, or if no UL data is expected to arrive within y ms with an accuracy level a2, etc.

[0226] In some embodiments, the WTRU may trigger the connection release by sending a connection release request (e.g., a new RRC message RRCReleaseRequest). In other embodiments, the WTRU may only send assistance information to the network (e.g., using an enhanced version of the UEAssistanceInformation message). The RRCReleaseRequest or UEAssistanceInformation message may include information such as:

[0227] - prediction (e.g., no UL data is expected within x ms with n% accuracy);

[0228] - the preferred state to transition to (e.g., idle, inactive);

[0229] - Any additional information that may help the network decide whether to accept the release message (e.g., current battery level, time of expected UL data (if any), type of traffic, etc.).

[0230] In some embodiments, in response to sending a RRCReleaseRequest or UEAssistanceInformation message, the WTRU may receive a RRCRelease message indicating a transition to the RRC_IDLE or RRC_INACTIVE state (ie, legacy).

[0231] In some embodiments, in response to sending the RRCReleaseRequest message, the WTRU may receive a rejection message (eg, RRCReleaseReject) telling it to remain in the RRC_CONNECTED state.

[0232] In some embodiments, in response to sending a RRCReleaseRequest or UEAssistanceInformation message, the WTRU may receive an enhanced RRCRelease message. For example, time information may be included that indicates to the WTRU that if the WTRU's prediction is still correct within that time, the WTRU may release the connection. The WTRU may then start a timer, and if no UL data arrives or the WTRU prediction remains unchanged (e.g., no expected data), the WTRU may transition to an idle or inactive state (as indicated in receiving the RRCRelease message). The WTRU may send an indication of the action (e.g., a new message, such as RRCReleaseCompleted) message to the network.

[0233] In some embodiments, the WTRU may indicate in the RRCReleaseRequest message whether it prefers to transition to the idle state or the inactive state.

[0234] In some embodiments, the WTRU may include information related to the predicted buffer level (e.g., how long the WTRU expects to not receive UL data, the predicted confidence / accuracy level / error tolerance, etc.) in the RRCReleaseRequest message (or in msg1, or in a MAC CE multiplexed with the RRCReleaseRequest message, etc.).

[0235] Example

[0236] Fig. 9 9 is a signal flow diagram illustrating the signal flow between the WTRU 901 and the network 903 in response to the AI / ML at the WTRU predicting that UL data for the WTRU is coming, according to an exemplary embodiment. The WTRU 901 may start up in the connected state 910.

[0237] At 911, the network 903 may determine that the WTRU has been inactive for a threshold duration and therefore determine to configure the WTRU to release its resources and enter the RRC_INACTIVE state. At 912, the network may send WTRU configurations related to the triggering of connection recovery, which depend on traffic predictions such as time horizon, expected accuracy level, amount of data for uplink transmission, etc. (e.g., when at least X KB of UL data is expected to arrive within n ms with an accuracy of p%, trigger connection setup / recovery). At 914, the network may send a RRCRelease message to the WTRU.

[0238] Although in Fig. 9 911, 912, and 914 are shown in a particular order, but it should be understood that at least some configuration information may be transmitted when the WTRU is in the RRC_CONNECTED state (RRCReconfiguration 912 is sent before step 911) or when transitioning to the RRC_INACTIVE state. For example, the RRCReconfiguration message 912 may provide the WTRU with some "heavy" configuration information, such as the AI / ML model, while the release 914 may provide some light configuration, such as the trigger conditions for resumption (e.g., data threshold or confidence level) that will allow the WTRU to resume the connection even before data arrives. Alternatively, all configuration information may be placed only in the reconfiguration message 912 or only in the release message 914.

[0239] While in the inactive state 916, the WTRU may perform UL data prediction 918, and when the conditions for triggering connection recovery based on the prediction are met (e.g., a certain amount of UL data is expected to arrive within a certain time with a given level of accuracy), the WTRU will trigger a connection recovery request 920, which indicates in the recovery cause that the connection is being restored due to the predicted UL data.

[0240] The network 902 may respond with an RRC resume message 922. The WTRU may send an RRC ResumeComplete message 924 back to the network and return to the RRC_CONNECTED state. The WTRU may then transmit UL data 930 when the predicted data arrives.

[0241] refer to Fig. 9 , some UL grants are provided to the WTRU that are consistent with the predicted data, and if the prediction is accurate, the UL data can be sent directly (e.g., immediately) (compared to the traditional case where the WTRU must perform connection recovery and may additionally require additional round-trip time to send the SR / BSR and obtain the grant required for the UL data).

[0242] Fig.10 1 is a signal flow diagram illustrating the signal flow between a WTRU 1001 and a network 1003 in response to an AI / ML at the WTRU predicting that no UL data is forthcoming for a period of time according to an exemplary embodiment. The WTRU may start 1010 in the RRC_CONNECTED state, and the network detects that the WTRU has been inactive on the network for a period of time 1012. At 1014, the AI / ML at the WTRU predicts that there will be no UL data for a certain duration. The WTRU may transmit a RRCReleaseRequest 1016 to the network. The network may authorize the release by returning a RRCRelease message 108 to the WTRU, and the WTRU may enter the RRC INACTIVE state.

[0243] refer to Fig.11 , a method 1100 implemented in a WTRU for transitioning between connection states in a wireless communication network may include the step of receiving one or more first messages from a network 1110, the one or more first messages including information about a predictive data configuration, the information about the predictive data configuration indicating one or more trigger conditions for performing a connection with the network and one or more data traffic prediction parameters. The information about the predictive data configuration indicating the one or more trigger conditions may be received by the WTRU from the network in a first radio resource control release message. The information about the predictive data configuration indicating the one or more data traffic prediction parameters may be received by the WTRU from the network in a second RRC Release message. The method 1100 may include the step of determining 1120 a data traffic prediction level based on the one or more data traffic prediction parameters when in an idle / inactive state. Determining the data prediction level may be based on any one of a current time, a current WTRU location, and a WTRU mobility pattern. In response to determining that the data traffic prediction level satisfies at least one of the one or more trigger conditions, the method 1100 may include the step of transmitting 1130 a second message to the network, the second message including request information for a connection and at least one cause value information for the connection. The one or more data traffic prediction parameters may be related to a prediction of data arriving at the WTRU for uplink transmission and / or a prediction of data arriving at the WTRU for downlink reception. The method 1100 may include the step of receiving 1140 a third message from the network, the third message including a response to the request for connection; and the step of initiating 1150 a transition to a connected state.

[0244] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in the present application, which are intended to be illustrations of various aspects. Without departing from its spirit and scope, many modifications and changes can be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of the present application should not be interpreted as being critical or necessary to the present invention unless explicitly provided as such. In addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure are apparent to those skilled in the art from the foregoing description. Such modifications and changes are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents given by such claims. It should be understood that the present disclosure is not limited to specific methods or systems herein.

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

[0246] It will also be understood that the terms used herein are used only for the purpose of describing specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed over a time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities (e.g., wearable) that is configured with some or all of the structure and functionality of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities that is configured with less than all of the structure and functionality of a WTRU; or (iv) a similar device. References herein to Figures 1A to 1D Details of an example WTRU are provided, which may be representative of any WTRU set forth herein. As another example, various disclosed embodiments herein are described above and below as utilizing a head mounted display. Those skilled in the art will recognize that devices other than a head mounted display may be utilized, and some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0247] In addition, the methods provided herein may be implemented in a computer program, software or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of non-temporary computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0248] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that may be applied, it should be understood that the embodiments shown are merely examples and should not be considered to limit the scope of the appended claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) that provides any suitable voltage.

[0249] In addition, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices including processors are mentioned. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0250] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may cause the final conversion or reduction of electrical signals and maintain the data bits in memory locations in the storage system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may support the provided methods.

[0251] The data bits may also be maintained on a computer-readable medium, including a magnetic disk, an optical disk, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium may include cooperating or interconnected computer-readable media that reside only on a processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

[0252] In an illustrative embodiment, any operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0253] There is little difference between hardware and software implementations of various aspects of the system. The use of hardware or software is usually (but not always, as in some cases, the choice of hardware or software may become important) a design choice that represents a cost-efficiency trade-off. There may be various vehicles (e.g., hardware, software, and / or firmware) with which the processes and / or systems and / or other technologies described herein can be implemented, and the preferred vehicle may change with the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may select a primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may select a primary software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0254] The foregoing detailed description has been described various embodiments of the apparatus and / or process by using block diagrams, flow charts and / or examples. Insofar as such block diagrams, flow charts and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or indeed any combination thereof. In an embodiment, several parts of the subject matter described herein may be implemented via an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and / or other integrated formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein may be equivalently implemented in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware or almost as any combination thereof, and according to the present disclosure, designing circuit systems and / or writing codes for software and / or firmware will be completely within the skill range of those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative examples of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually carry out the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.; and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0255] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system by a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can typically include a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, a driver, a graphical user interface, and an application, one or more interactive devices such as a touch pad or screen, and / or a control system including a feedback loop and a control motor (e.g., feedback for sensing position and / or velocity; a control motor for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as components typically found in data computing / communication and / or network computing / communication systems.

[0256] The subject matter described herein sometimes illustrates different parts that are included in different other parts or connected with different other parts.It should be understood that the architecture of such description is only an example, and many other architectures that realize the same function can actually be implemented.In a conceptual sense, any arrangement of parts for realizing the same function is effectively "associated" so that the desired function can be realized.Therefore, any two parts that are combined to realize a specific function in this article can be regarded as "associated" with each other so that no matter how the architecture or intermediate parts realize the desired function.Similarly, any two parts that are associated in this way can also be regarded as "operably connected" or "operably coupled" to realize the desired function, and any two parts that can be associated in this way can also be regarded as "operably coupled" to realize the desired function.The specific example of operable coupling includes (but is not limited to) parts that can be matched physically and / or physically interact, and / or parts that can be wirelessly interacted and / or wirelessly interacted, and / or parts that can be logically interacted and / or parts that can be logically interacted.

[0257] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural where appropriate to the context and / or application. For clarity, the various singular / plural arrangements may be expressly set forth herein.

[0258] Those skilled in the art will understand that, in general, the terms used herein and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of an introduced claim statement is intended, such intent will be expressly stated in the claim, and in the absence of such a statement, such intent is not present. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce multiple claim statements. However, the use of such phrases should not be interpreted as implying that a claim recitation introduced by the indefinite article "a" or "an" will limit any particular claim including such introduced claim recitation to embodiments including only one such recitation, even if the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same is true for the use of definite articles to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited number (e.g., merely reciting "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those cases where a convention similar to “at least one of A, B, and C, etc.” is used, generally, such construction is intended to represent the convention that one skilled in the art would understand (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those cases where a convention similar to “at least one of A, B, or C, etc.” is used, generally, such meaning is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). One skilled in the art would further understand that any transitional words and / or phrases (whether in the specification, claims, or drawings) that actually give two or more alternatives should be understood to contemplate the possibility of including one of the items, either of the items, or both of the items.For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B." In addition, the term "any" as used herein followed by a list of multiple items and / or categories of items is intended to include "any," "any combination," "any multiple," and / or "any combination of multiples," either alone or in combination with other items and / or other categories of items. Furthermore, the term "set," as used herein, is intended to include any number of items, including zero. Additionally, the term "number," as used herein, is intended to include any number, including zero. And the term "plurality," as used herein, is intended to be synonymous with "multiple."

[0259] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0260] As will be understood by those skilled in the art, for any and all purposes, such as in providing a written description, all scopes disclosed herein also encompass any and all possible sub-ranges and combinations thereof.Any listed scope can be easily considered to fully describe the same scope and enable the same scope to be divided into at least equal two, three, four, five, ten, etc. As a non-limiting example, each scope discussed herein can be easily divided into the following third, the middle third, and the upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "reach", "at least", "greater than", "less than", etc. include the quantity of narration and refer to the scope that can be subsequently divided into sub-ranges as discussed above. Finally, as will be understood by those skilled in the art, scope includes each individual member.Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2 or 3 units.Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4 or 5 units, and the like.

[0261] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. Furthermore, the use of the term "means for..." in any claim is intended to refer to or means-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

[0262] By way of example, suitable processors include a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP); a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or state machine.

[0263] The WTRU may be used in conjunction with modules implemented in hardware and / or software, including software defined radio (SDR), and other components such as cameras, video camera modules, video phones, speaker phones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, module, a frequency modulation (FM) wireless unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game console module, an Internet browser, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0264] Although various embodiments have been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more functions of the various components may be implemented in software controlling a general purpose computer.

[0265] Furthermore, while the invention has been shown and described herein with reference to particular embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the range and range of equivalents of the claims and without departing from the invention.

[0266] References

[0267] [1]3GPP, "Radio Link Control (RLC) protocol specification", TS 38.322, ver.17.1.0, July 2022

[0268] [2]3GPP, "Packet Data Convergence Protocol (PDCP) specification", TS38.323, ver.17.1.0, July 2022

[0269] [3]3GPP, "General aspects for Base Station (BS) Radio Frequency (RF) for NR", TS 38.817, ver.15.9.0, October 2020

[0270] [4] 3GPP, "Group Radio Access Network NR; NR and NG0RANOverallDescription", TS 38.300, ver.17.1.0, July 2022.

Claims

1. A method implemented in a wireless transmit receive unit WTRU, the method comprising: receiving one or more first messages from a network, the one or more first messages comprising information about a predictive data configuration, the information about the predictive data configuration indicating one or more trigger conditions and one or more data traffic prediction parameters for performing a connection with the network; determining a data traffic prediction level based on the one or more data traffic prediction parameters when in an idle / inactive state; In response to determining that the data traffic prediction level satisfies at least one of the one or more trigger conditions, transmitting a second message to the network, the second message including request information for a connection and at least one cause value information for the connection; receiving a third message from the network, the third message comprising a response to the request for connection; as well as Initiates a transition to the Connected state.

2. The method of claim 1, wherein the information about the predictive data configuration indicating one or more trigger conditions is received by the WTRU from the network in a first radio resource control release (RRCRelease) message.

3. The method according to any one of claims 1 and 2, wherein the information about the predictive data configuration indicating one or more data service prediction parameters is received by the WTRU from the network in a second RRCRelease message.

4. A method according to any one of the preceding claims, wherein the cause value information for the connection indicates that the connection request is due to predicted uplink data.

5. The method of any preceding claim, wherein the one or more data traffic prediction parameters include any one of a prediction of an arrival time of traffic data at the WTRU and a predicted amount of data.

6. The method according to any one of the preceding claims, wherein the one or more trigger conditions include any one of a time range of the arrival of the data traffic, an accuracy threshold of the prediction, and an amount of data traffic.

7. A method according to any of the preceding claims, wherein determining the data prediction level is performed using an artificial intelligence / machine learning AI / ML model.

8. The method of any preceding claim, wherein determining the data prediction level is based on any one of a current time, a current WTRU location, and a WTRU mobility pattern.

9. A method according to any of the preceding claims, wherein initiating the transition to the connected state includes transmitting a request to connect to the network, the request including an indication that the request is issued due to a prediction of data arriving at the WTRU and one or more of the following: the amount of the predicted data, the predicted arrival time of the predicted data at the WTRU.

10. The method of any preceding claim, wherein the one or more data traffic prediction parameters relate to a prediction of the arrival of data at the WTRU for an uplink transmission.

11. The method of any preceding claim, wherein the one or more data traffic prediction parameters relate to a prediction of arrival of data at the WTRU for downlink reception.

12. The method according to any of the preceding claims, wherein the transition to the connected state is a transition to connection establishment.

13. The method according to any one of claims 1 to 11, wherein the transition to the connected state is a transition to connection restoration.

14. A wireless transmit / receive unit WTRU, comprising a processor, a transceiver unit and a storage unit, and configured to: receiving one or more first messages from a network, the one or more first messages comprising information about a predictive data configuration, the information about the predictive data configuration indicating one or more trigger conditions and one or more data traffic prediction parameters for performing a connection with the network; determining a data traffic prediction level based on the one or more data traffic prediction parameters when in an idle / inactive state; In response to determining that the data traffic prediction level satisfies at least one of the one or more trigger conditions, transmitting a second message to the network, the second message including request information for a connection and at least one cause value information for the connection; receiving a third message from the network, the third message comprising a response to the request for connection; as well as Initiates a transition to the Connected state.

15. The WTRU according to claim 14 is configured to receive the information about the predictive data configuration indicating one or more trigger conditions from the network in a first radio resource control release RRCRelease message.

16. The WTRU according to any one of claims 14 and 15 is configured to receive the information about the predictive data configuration indicating one or more data service prediction parameters from the network in a second RRCRelease message.

17. The WTRU of any one of claims 14 to 16, wherein the cause value information for the connection indicates that the connection request is due to predicted uplink data.

18. The WTRU of any one of claims 14 to 17, wherein the one or more data traffic prediction parameters include any one of a prediction of an arrival time of traffic data at the WTRU and a predicted amount of data.

19. The WTRU of any one of claims 14 to 18, wherein the one or more trigger conditions include any one of a time range of arrival of data traffic, an accuracy threshold of the prediction, and an amount of data traffic.

20. The WTRU of any one of claims 14 and 19, wherein being configured to determine the data prediction level comprises being configured to use an artificial intelligence / machine learning AI / ML model to perform the determination.

21. The WTRU of any one of claims 14 to 20, wherein being configured to determine the data prediction level comprises being configured to determine the data prediction level based on any one of a current time, a current WTRU location, and a WTRU mobility pattern.

22. A WTRU according to any one of claims 14 to 21, wherein being configured to initiate the transition to the connected state includes being configured to transmit a request for connection to the network, the request including an indication that the request is issued due to a prediction of data arriving at the WTRU and the amount of the predicted data.

23. The WTRU of any one of claims 14 to 22, wherein the one or more data traffic prediction parameters relate to a prediction of data arriving at the WTRU for an uplink transmission.

24. The WTRU of any one of claims 14 to 23, wherein the one or more data traffic prediction parameters relate to a prediction of data arriving at the WTRU for downlink reception.

25. The WTRU of any one of claims 14 to 24, wherein the transition to the connected state is a transition to connection establishment.

26. The WTRU of any one of claims 14 to 24, wherein the transition to the connected state is a transition to connection recovery.

Images