Method for enhancing HARQ downlink to provide services with different reliability and latency
By configuring CBG quantity and accuracy measurement information on the WTRU side and optimizing the HARQ acknowledgment process using an artificial intelligence model, the problems of low ACK/NACK acknowledgment efficiency and time delay in the HARQ downlink are solved, achieving more efficient downlink transmission.
Patent Information
- Application Number
- CN202480016926.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-02-14
- Filing Date
- 2024-02-12
- Publication Date
- 2025-11-07
AI Technical Summary
The existing HARQ downlink suffers from inefficient ACK/NACK confirmation mechanisms and long latency on the wireless transmitter/receiver side, making it difficult to meet service requirements with different reliability and latency requirements.
By configuring wireless transmit/receive units (WTRUs) to receive and process the quantity and accuracy metrics of code block groups (CBGs), artificial intelligence models are used to optimize the HARQ acknowledgment process and dynamically adjust the scheduling information of transport blocks to improve the accuracy and latency performance of ACK/NACK.
It optimizes the accuracy and latency of the HARQ confirmation process, meets downlink transmission requirements with different service quality requirements, and improves the reliability and efficiency of the system.
Smart Images

Figure CN120917692A_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims priority to U.S. Provisional Application 63 / 445,528, filed February 14, 2023, the contents of which are incorporated herein by reference. Background Technology
[0003] For the downlink, on the Wireless Transmit / Receive Unit (WTRU) side, for the Hybrid Automatic Repeat Request (HARQ) function, the WTRU uses procedures from the Media Access Control (MAC) layer and the Physical (PHY) layer to receive Protocol Data Units (PDUs) and sends Acknowledgments (ACKs) or Negative Acknowledgments (NACKs). On the gNB side, there is a MAC scheduler (Sch) and a transmission buffer (Tx) responsible for sending PDUs and receiving ACKs / NACKs. Summary of the Invention
[0004] A wireless transmit / receive unit (WTRU) can be configured to receive first configuration information indicating a first number of code block groups (CBGs). The WTRU can be configured to receive first downlink (DL) scheduling information indicating transmission of a first transport block (TB). The WTRU can be configured to receive the first TB. The first TB can consist of the first number of CBGs. The WTRU can be configured to transmit a hybrid automatic repeat request (HARQ) acknowledgment (ACK) or a HARQ negative acknowledgment (NACK) for each of the first number of CBGs. The WTRU can be configured to determine a second number of CBGs based on at least one of: a measured value, a current ratio of ACKs / NACKs, and an estimate of packet delay or latency. The WTRU can be configured to determine a precision metric associated with the second number of CBGs. The precision metric can be at least one of: a confidence interval, an error margin, and an accuracy coefficient. The WTRU can be configured to transmit an indication of the determined second number of CBGs and the determined precision metric. The WTRU can be configured to receive second configuration information indicating a third number of CBGs. The WTRU can be configured to receive second DL scheduling information indicating transmission of a second TB. The WTRU can be configured to receive the second TB. The WTRU can be configured to transmit a HARQ-ACK or a HARQ-NACK for each of the third number of CBGs. The WTRU can be configured to determine the second number of CBGs using an artificial intelligence (AI) model. The AI model can be sent by a gNB. The WTRU can receive the AI model based on registration with a network. The WTRU can receive the AI model based on association with a network cell that supports reconfiguration operations. Inputs to the AI model can include: packet data unit (PDU) delay or latency; PDU packet loss; PDU ACK / NACK statistics, such as an average number of ACKs / NACKs in a predefined time interval, a variation in time instances when these ACKs / NACKs are sent; PDU code block error distribution of code block errors; soft buffer state statistics; or receiver characteristics. The determined second number of CBGs can provide a highest probability of decoding CBGs. The determined second number of CBGs can provide a probability of decoding CBGs that is below a threshold. The first DL scheduling information can be downlink control information (DCI). The second TB can consist of the third number of CBGs. BRIEF DESCRIPTION OF DRAWINGS
[0005] The application can be understood in more detail with reference to the following description and drawings wherein:
[0006] Figure 1Ais a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;
[0007] Figure 1B is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented; Figure 1A is a system diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system shown in
[0008] Figure 1C is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented; Figure 1A is a system diagram of an example radio access network (RAN) and an example core network (CN) that can be used within the communications system shown in
[0009] Figure 1D is a system diagram of another example RAN and another example CN that can be used within the communications system shown in Figure 1A
[0010] Figure 2 is an example mapping of HARQ and ARQ on the RLC and MAC layers for WTRU and gNB for 5G NR shown;
[0011] Figure 3 is an example of the 5G NR HARQ data unit hierarchy shown;
[0012] Figure 4 is an example simplified view of the WTRU MAC layer architecture in 3GPP, focusing on HARQ;
[0013] Figure 5 is an example network of WTRU HARQ downlink communication shown;
[0014] Figure 6 is an example of the generic and newly introduced blocks of the WTRU MAC layer legacy architecture shown;
[0015] Figure 7 is an example logical flow between the WTRU and the network, where the algorithm is executed by the WTRU shown;
[0016] Figure 8 is an example logical flow between the WTRU and the network, where the algorithm is executed by the network shown;
[0017] Figure 9 is an example method for reconfiguring the number of CBGs shown; and
[0018] Figure 10 is an example flow diagram of a WTRU indicating the optimal number of CBGs for HARQ transmission shown. DETAILED DESCRIPTION
[0019] Figure 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread orthogonal frequency division multiplexing (ZT-UW DTS-S-OFDM), unique-word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and / or the like.
[0020] As shown Figure 1A , the communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can 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 can be referred to as a station (STA)), can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environments), a consumer electronics, a device operating on a commercial and / or industrial wireless network, etc. Any of the wireless transmit / receive units 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.
[0021] The communications system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node-B (such as gNode B (gNB)), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and so on. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.
[0022] The base station 114a can be part of the RAN 104, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies. The carrier frequencies can be referred to as a cell (not shown). The frequencies can be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrums. A cell can provide wireless service coverage to a particular geographic area, which can be relatively fixed or can change over time as the access to the frequencies changes. The cell can be further divided into cell sectors. For example, a cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In one embodiment, the base station 114a can employ multiple-input multiple-output (MIMO) techniques and can use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.
[0023] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which can 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 can be established using any suitable radio access technology (RAT).
[0024] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 116 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).
[0025] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro.
[0026] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.
[0027] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access together with NR wireless access, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).
[0028] In other embodiments, the base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[0029] Figure 1A The base station 114b in FIG. 10 can be a wireless router, Home eNode B, Home Node B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access points employing the 802.11 specification. The 802.11 specification is maintained by the IEEE 802.11 reflection's, for example. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as Bluetooth® Brand Wireless Technology to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b need not access the Internet 110 via the CN 106. Figure 1A
[0030] The RAN 104 can be in communication with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, a Figure 1A The RAN 104 and / or the CN 106 can also be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ a NR radio technology, the CN 106 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.
[0031] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice, video, and / or data services to users. The Internet 110 can include a global system of interconnected computer networks and devices that use the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or the internet protocol (IP) in the TCP / IP family of protocols, for example, to communicate with one another. The other networks 112 can include wired or wireless communications networks owned and / or operated by other service providers. For example, the other networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 or a different RAT.
[0032] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, Figure 1A The WTRU 102c shown in Figure 1 A can be configured to communicate with the base station 114a using a cellular-based radio technology and can be configured to communicate with the base station 114b using an IEEE 802 radio technology.
[0033] Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B The WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
[0034] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, it is to be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.
[0035] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.
[0036] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to facilitate increasing the WTRU's 102 capacity. For example, the WTRU 102 can include two transmit / receive elements 122, one for transmitting and one for receiving, or in a MIMO configuration, multiple transmit / receive elements 122 can be used to transmit and receive wireless signals.
[0037] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.
[0038] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can 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).
[0039] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0040] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or
[0041] The processor 118 can further be coupled to other peripherals 138, which can 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 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands- free headset, a Bluetooth® The peripheral device 138 can include one or more sensors, which can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor; a geopositioning sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc. The peripheral device 138 can include one or more of a module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 can include one or more sensors, which can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor; a geopositioning sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.
[0042] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for UL (e.g., for transmission) and DL (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or substantially eliminate self-interference and / or to reduce interference from other sources. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for UL (e.g., for transmission) or DL (e.g., for reception)).
[0043] Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.
[0044] The RAN 104 can include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can 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 can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.
[0045] Each of eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in Figure 1C The eNode-Bs 160a, 160b, 160c can also communicate with one another using the X2 interface.
[0046] Figure 1C The CN 106 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.
[0047] MME 162 can be connected to each of the eNode-Bs in RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activations / deactivations, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 can provide a control plane function for switching between RAN 104 and RANs (not shown) utilizing other radio technologies, such as GSM and / or WCDMA.
[0048] SGW 164 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
[0049] The SGW 164 can be connected to the PGW 166, which can 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.
[0050] The CN 106 can facilitate communications with other networks. For example, the CN 106 can 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 landline communications devices. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers.
[0051] Although WTRUs are described in Figures 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such a terminal can use a wired communication interface with the communication network (e.g., on a temporary or permanent basis).
[0052] In representative embodiments, the other networks 112 can be a WLAN.
[0053] A WLAN in an infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and can be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations. Traffic between STAs within a BSS can be sent through the AP, e.g., where the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. The traffic between STAs within a BSS can be considered and / or referred to as peer-to-peer traffic. The peer-to-peer traffic can be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS can use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode can not have an AP, and the STAs (e.g., all the STAs) within or using the IBSS can communicate directly with each other. The IBSS mode of communication can sometimes be referred to herein as "ad-hoc" mode of communication.
[0054] When using an 802.11 ac infrastructure mode of operation or similar, an AP can transmit beacons on a fixed channel, such as on a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, such as in 802.11 systems, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen to the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA can transmit in a given BSS at any given time.
[0055] High Throughput (HT) STAs can use 40 MHz wide channels, for example, by combining the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
[0056] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be separately subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described 80+80 configuration operations can be reversed, and the combined data can be sent to the medium access control (MAC).
[0057] Operation modes below 1 GHz are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers in 802.11af and 802.11ah are reduced relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter-type control / machine-type communication (MTC), such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities including support (e.g., only support) for certain and / or limited bandwidth. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
[0058] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11η, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to a maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., a MTC-type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., busy due to a STA (that only supports a 1 MHz operating mode) transmitting to the AP, then the entire available frequency band can be considered busy even if most of the available frequency band remains idle.
[0059] In the United States, the available frequency band that can be used by 802.11ah is from 902 MHz to 928 MHz. In Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz, depending on the country code.
[0060] Figure 1Dis a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.
[0061] The RAN 104 can include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 104 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can 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 can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can 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 can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).
[0062] The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) having different lengths, or scalable lengths, (e.g., containing different numbers of OFDM symbols and / or lasting varying lengths of absolute time).
[0063] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with one or more of gNBs 180a, 180b, 180c without also accessing other RANs (e.g., eNode-Bs 160a, 160b, 160c). In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can use
[0064] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking with E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. Figure 1D As shown, the gNBs 180a, 180b, 180c can be in communication with the AN 180a, 180b, 180c over an N2 interface.
[0065] Figure 1DThe CN 106, as shown in FIG. 10, can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and can include a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.
[0066] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing the WTRU 102a, 102b, 102c registration area, terminating non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b can utilize network slicing to customize CN support for the WTRU 102a, 102b, 102c depending on the type of service being accessed by the WTRU 102a, 102b, 102c. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b can provide the control plane functionality to manage the WTRU 102a, 102b, 102c
[0067] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating IP address
[0068] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which can 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 can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.
[0069] The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
[0070] In view of Figures 1A-1D and Figures 1A-1D In view of the respective descriptions of One or more, or all, of the functions described herein in relation to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices can be used to test other devices and / or to simulate network and / or WTRU functionality.
[0071] A simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices can perform one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be coupled directly to another device for testing purposes and / or can perform tests using over-the-air, wireless communication.
[0072] One or more simulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in a testing lab and / or a testing scenario in a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (which can include one or more antennas), for example.
[0073] Figure 2 Mapping of HARQ at the WTRU and gNB is shown. The solid lines between PHYs represent data flow in the downlink, and the dashed lines between MACs represent logical links for feedback and signaling.
[0074] Current HARQ implementations rely on a set of fixed or semi-static parameters, which are either configured in the WTRU through RRC configuration or are network configured and specific to the whole cell. HARQ can be a stop-and-wait asynchronous and adaptive protocol. A WTRU associated with a serving cell can have one MAC entity and one HARQ entity, which manages a variable number of HARQ processes in which a stop-and-wait procedure is performed. Each HARQ process handles the delivery of one PDU for which the sender entity waits for an ACK from the receiver entity before transmitting the next PDU. Asynchronicity allows flexible scheduling of HARQ transmissions. Adaptivity refers to the use of adaptive code rates that can be adjusted based on channel quality. The main HARQ functions for successful transmission of a PDU can include forward error correction (FEC) through soft combining of PDUs and retransmission of erroneous PDUs through the sending of acknowledgments and negative acknowledgments (ACK / NACK).
[0075] FEC via soft combining is a PHY layer function that is based on buffering error PDUs and using these PDUs with retransmitted PDUs to perform decoding. Retransmission via ACK and NACK coordination is a MAC layer function that is based on a preconfigured timing report that indicates whether a PDU has been received correctly (ACK) or whether it has been received in error or not received within an expected time window (NACK). The HARQ function directly impacts communication latency and reliability. Operation on the PHY and MAC layers allows for the establishment of a HARQ transmission cycle between a WTRU and a gNB, which can result in variable transmission latency and reliability performance. If this performance is not sufficient for a service, then procedures from upper layers (such as ARQ or TCP control mechanisms) must be invoked.
[0076] The two types of HARQ are incremental redundancy (IR-HARQ) and Chase combining HARQ. For IR-HARQ, a different redundancy version (RV) is used for each retransmission, such that the number of coded bits increases with each retransmission, and thus the probability of decoding increases. Four different RVs can be used, and the maximum number of retransmissions can be set to three. For Chase combining HARQ, only one RV can be used, and the same PDU is retransmitted and combined to increase the probability of successful decoding.
[0077] Regardless of the type of HARQ, the probability of successfully decoding a PDU is an important metric, and if the PDU is not ultimately decoded, it is discarded and left to upper layers to continue successful delivery of the PDU.
[0078] HARQ data can be structured such that the largest unit is called a transport block (TB) and it fits within one MAC PDU. TBs are transportable by the MAC layer, however, these are large data units, and if an error occurs and the data unit is not decodable, then network resource utilization is inefficient. Therefore, smaller units called code block groups (CBGs) are introduced, such that one TB can have one or more CBGs. The smallest unit is called a code block (CB), and the number of CBs within a CBG can be fixed and can be specified by an RRC message.
[0079] Figure 3HARQ data structure hierarchy is shown from TB to CB, where k represents the number of CBGs within a TB, and each CBG has a fixed number of two CBs, so 2k CBs are used to represent the entire information from a TB. HARQ retransmission can occur at the TB level or CBG level (i.e., no CB retransmission). The underlying principle behind this is that retransmitting CBs can cause a large amount of signaling, thus reducing performance. In the case of configured carrier aggregation (CA), a WTRU can acknowledge multiple TBs / CBGs, and the RRC-configured codebook shows how many ACK / NACK bits are sent and how these bits are packed.
[0080] In downlink, HARQ transmission can occur on the physical downlink shared channel (PDSCH) channel, and feedback can be sent through the physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH). The gNB can send a downlink control information (DCI) message indicating several control information, such as a new data indicator (NDI), which the WTRU can use to determine if this is a new transmission (NDI toggled) or a retransmission (NDI not toggled). Two available DCI formats are format 1-0 and format 1-1. In the case of a new transmission, the WTRU can clear the soft buffer, while for a retransmission, the WTRU can use the buffer for soft combining and improved decoding. The WTRU can follow the timing report and send an ACK or NACK back to the gNB. If CBG retransmission is configured, the WTRU can use additional fields in the DCI (e.g., two additional fields) to determine which CBGs to retransmit. The field can be a CBG transmission indicator (CBGTI), which can indicate whether a particular CBG is present in the downlink transmission. The CBGTI can be a bitmap. Another field can be a CBG flushing indicator (CBGFI), which can indicate whether a CBG should be flushed or used in soft combining. The CBGFI can be one or more bits.
[0081] When using variable transmission links, different configurations of HARQ downlink parameters provide different trade-offs between transmission reliability and latency. By introducing adaptation of HARQ related parameters over time, embodiments herein adapt to be an improvement over existing HARQ downlink procedures. This is done using a new function based on a model or algorithm that can be run or executed at the WTRU or by the WTRU, or at the network (e.g. gNB) or by the network (e.g. gNB). This model or algorithm can be empirical, probabilistic estimation, or AI inference, which facilitates overall adaptation of HARQ parameters by providing a prediction / estimation / inference on the variability of the underlying link. These can be computed or determined with specified precision metrics (e.g. confidence interval, error margin, accuracy coefficient, or a combination of these). The goal is to use the output of such a model or algorithm and adjust the HARQ procedure so that it is able to fulfill the MAC layer provision of services with different reliability and latency requirements without the need to invoke procedures from higher layers (e.g. ARQ on RLC layer or TCP on transport layer).
[0082] The current 3GPP release for 5G NR supports HARQ error correction and retransmission procedures for WTRU reception (downlink) data with a static approach that relies on a fixed set of parameters that are either configured in the WTRU by RRC configuration or are network configured and specific to the whole cell. The HARQ procedure cannot adapt to current radio link conditions and / or specific user network DL scheduling without reconfiguration of the WTRU and / or network planning changes. Figure 4 A simplified view of the current architecture focusing on HARQ is shown, where the whole MAC layer performs the multiplexing and demultiplexing of PDUs between transport channels and logical channels coordinated by a MAC control block. Logical Channel Prioritization (LCP) is only valid for uplink.
[0083] Downlink HARQ PDU exchange between WTRU and gNB starts with a PDU arriving at the gNB, which follows a slot alignment and introduces a scheduling delay after which the PDU is transmitted to the WTRU, which introduces a processing delay. The WTRU replies with an ACK or NACK depending on whether the PDU was decoded correctly or not. The ACK / NACK is processed at the gNB and in case of NACK, a retransmission is initiated after the scheduling delay, while in case of ACK, a new transmission is initiated after the scheduling delay.
[0084] Figure 5An example of network (e.g. gNB) to WTRU downlink communication is shown. Downlink scheduling at the network can be performed 510. DCI can be sent from the network to the WTRU 520. The DCI can be sent with the control information needed to configure the HARQ parameters. TBs or CBGs can be sent from the network to the WTRU 530. The WTRU can receive the DCI information 540. The WTRU can check the NDI in the DCI 550. The WTRU can send ACK or NACK 560 based on the network configured timing report to report successful or unsuccessful transmission of TBs or CBGs. The network side controls the HARQ parameter configuration in a static or semi-static manner and once configured, the WTRU keeps performing the same network reception configuration regardless of any changes and variations in the underlying transport link. The WTRU side is not actively involved in the HARQ parameter configuration.
[0085] There is an issue of how to determine and include information from the WTRU side to adjust the downlink HARQ parameters in future time transmission intervals in order to achieve better management of the latency-reliability tradeoff on the MAC layer
[0086] The WTRU information related to adjusting the HARQ parameters can not be available in a timely manner and / or maintained by the network in some cases (e.g. statistics such as successful PDU transmission, statistics on the use of soft buffer at the WTRU for decoding purposes), so actively including the WTRU in the adjustment of the HARQ parameters can enable an overall approach for optimizing the HARQ.
[0087] In one embodiment, the WTRU can send an indication to change the number of CBGs.
[0088] Based on measurements or using an algorithm (e.g. empirical, probabilistic, online / offline trained AI model or a combination of these), the WTRU can determine and indicate the optimal number of CBGs over a future time window (e.g. expressed as TTIs) and a precision metric of the indication (e.g. confidence interval, error margin, accuracy coefficient or a combination of these). This is what the WTRU considers as the most suitable solution taking into account its own estimation based on variations of the underlying physical link.
[0089] In one embodiment, a WTRU can request a change in the number of CBGs. The WTRU can receive first configuration information indicating a first number of CBGs. The WTRU can receive first DL grant information scheduling transmission of a first TB. The WTRU can receive the first TB. The first TB can be composed of the first number of CBGs. The WTRU can transmit a HARQ-ACK or a HARQ-NACK for each of the first number of CBGs. The WTRU can determine a second number of CBGs. The WTRU can determine the second number of CBGs based on one or more measured values. The WTRU can determine the second number of CBGs based on a current ratio of ACKs / NACKs. The WTRU can determine the second number of CBGs based on a prediction of packet delay or latency. The WTRU can determine the second number of CBGs based on any of the above elements or a combination of at least one of the above elements. The WTRU can determine the second number of CBGs using an AI model. The determined second number of CBGs can provide a highest probability of decoding CBGs. The determined second number of CBGs can provide a probability of decoding CBGs below a threshold. The WTRU can determine an accuracy metric associated with the determined second number of CBGs. For example, the accuracy metric can be a confidence interval, an error margin, or an accuracy coefficient. The WTRU can transmit an indication of the determined second number of CBGs and the associated accuracy metric. The WTRU can receive second configuration information indicating a third number of CBGs. The WTRU can receive second DL grant information scheduling transmission of a second TB. The WTRU can receive the second TB. The second TB can be composed of the third number of CBGs. The WTRU can transmit a HARQ-ACK or a HARQ-NACK for each of the third number of CBGs. The first number of CBGs can be a first maximum number of CBGs, and the second number of CBGs can be a second maximum number of CBGs. The second number of CBGs can be the same or different from the third number of CBGs.
[0090] In one embodiment, WTRU specific information can be included that can improve the decisions taken by the network in order to dynamically adjust the HARQ parameters over time. Figure 6 A general and newly introduced block of the WTRU MAC layer legacy architecture (as shown in Figure 4 is shown in order to facilitate the implementation of the proposed embodiments. The general and newly introduced blocks are highlighted with dashed rectangles and the interaction with the current architecture is via the MAC control block. These entities include the HARQ service access point (SAP), the HARQ controller, and the HARQ algorithm (Algo).
[0091] HARQ-SAP is a service access point (SAP) that is an interface for bi-directional communication with the reference architecture. It is used to read the actual values of the HARQ parameters, but also to monitor MAC and PHY layer related parameters, which can be relevant inputs in the generic block.
[0092] HARQ controller is an entity that uses the input parameters to control the execution of the algorithm. It can create and populate entries, such as a HARQ lookup table, from which the best value for a given HARQ parameter can be selected from the WTRU side. Using the MAC control block, this configuration can be signaled to the network. The HARQ lookup table can include elements such as Config Index, CBG (CBG_k), and HARQ Process (N_HARQ_Process).
[0093] HARQ-Algo (algorithm) is an entity or block in which an algorithm (e.g., empirical, probabilistic estimation, or AI inference) can be executed to provide a prediction / estimation / inference of the best HARQ parameter value with a certain accuracy metric. This can be used to populate entries at the HARQ controller (e.g., in a HARQ lookup table).
[0094] In contrast to the current architecture shown in Figure 4 the architecture enhancement shown in Figure 6 shows a change in the current operation as Figure 5 proposed. Figure 6
[0095] Figure 7 An example logical flow procedure between a WTRU and a network (e.g., gNB) is shown in which a model or algorithm is executed by the WTRU. The WTRU can receive the model or algorithm, or can be preconfigured 705 with the model or algorithm. Pre-configuration can include a protocol (e.g., MAC) between the network and the WTRU regarding where to execute the algorithm, determining the type of algorithm, and exchanging additional information related to the initial setup (e.g., data format entries). The WTRU can receive the model through a pre-configuration procedure in which the network transmits, sends, or indicates the model to the WTRU and is required to be used as part of the HARQ procedure. The WTRU can receive the model through a registration with the network in which the model is communicated, sent, or indicated as part of the registration. The WTRU can receive the model through an association with a specific network cell that supports the operation (i.e., the model is communicated, sent, or indicated and is only available in a predetermined number of network cells).
[0096] The WTRU can perform algorithm 710. The WTRU can send prediction / indication 715 to the network. The prediction / indication can be via a look-up table or can be a value of a specific parameter. The prediction / indication can refer to a CBG number. The CBG number can be the best CBG number that the WTRU predicts based on measured transmission parameters or status. The best number of CBGs can mean that the probability of successful decoding is the highest (e.g., above a threshold) when using the "best" number of CBGs.
[0097] The network can perform reconfiguration 720. The network can consider the WTRU prediction / indication to perform reconfiguration. The network can perform scheduling 725. The network can send and the WTRU can receive downlink control information (DCI) 730. The DCI can indicate scheduling information. The DCI can include modification information based on the WTRU prediction / indication. The network can send and the WTRU can receive a TB / CBG 735. The network sent TB / CBG can be modified based on the WTRU prediction / indication. The modification due to network reconfiguration can occur when there are no remaining retransmissions pending in the network, as reconfiguration during retransmission can cause misalignment, such as when the WTRU expects a TB / CBG of one size but receives another, the CBG FI bitmap will have an unexpected format and size, or the indicators for inactive HARQ processes can be swapped. The WTRU can send HARQ ACK or NACK 740. The HARQ ACK / NACK can be sent based on or in response to the received TB / CBG. The HARQ ACK / NACK can be sent based on or in response to a timing report (e.g., network configured timing). The HARQ ACK / NACK can be sent based on or in response to a new data indicator (NDI) in the DCI. The WTRU can send a HARQ ACK if the TB / CBG is successfully decoded. The WTRU can send a HARQ NACK if the TB / CBG is not successfully decoded. The network can perform a fallback procedure and discard the WTRU prediction / indication or measurement and continue without reconfiguration. The fallback can be triggered when performance degradation is significant (e.g., a large number of NACKs are received).
[0098] Figure 8An example logical flow procedure between a WTRU and a network (e.g., gNB) is shown in which a model or algorithm is executed by the network. The WTRU can receive the model or algorithm or can be preconfigured with the model or algorithm 805. Pre-configuration can include a protocol (e.g., MAC) between the network and the WTRU regarding where to execute the algorithm, determining the algorithm type, and exchanging additional information related to initial setup (e.g., data format entries). The WTRU can receive the model through a pre-configuration procedure in which the network communicates, sends, or indicates the model to the WTRU and is required to be used as part of a HARQ procedure. The WTRU can receive the model through registration with the network in which the model is communicated, sent, or indicated as part of the registration. The WTRU can receive the model through association with a specific network cell that supports the operation (i.e., the model is communicated, sent, or indicated and is only available in a predetermined number of network cells).
[0099] The WTRU can send measurements / inputs 810 for the algorithm to the network. The measurements / inputs can be provided via a lookup table. The measurements / inputs can be sent as a data stream. The measurements / inputs can be, for example: PDU delay / latency; PDU packet loss; PDU ACK / NACK statistics, such as the average number of ACK / NACKs in a predefined time interval, the variation in the time instances when these ACK / NACKs are sent; PDU code block error distribution of code block errors; soft buffer status statistics; or receiver specific characteristics (sensitivity threshold). The network can perform the algorithm 815. The network can perform reconfiguration 820. The reconfiguration can be based on the algorithm execution. The network can perform scheduling 825. The network can send and the WTRU can receive DCI 830. The DCI can indicate scheduling information. The DCI can include modification information based on WTRU measurements / inputs and based on the algorithm execution. The network can send and the WTRU can receive TB / CBG 835. The network sent TB / CBG can be based on WTRU measurements / inputs. Modification due to reconfiguration can occur when there are no remaining retransmissions pending in the network, as reconfiguration during retransmission can cause misalignment, such as when the WTRU expects one size of TB / CBG but receives another, the CBG FI bitmap will have an unexpected format and size, or the indicator for inactive HARQ processes can be swapped. The WTRU can send HARQ ACK or NACK 840. The HARQ ACK / NACK can be sent based on or in response to a timing report (e.g., network configured timing). The HARQ ACK / NACK can be sent based on or in response to a new data indicator (NDI) in the DCI. The WTRU can send a HARQ ACK if the TB / CBG is successfully decoded. The WTRU can send a HARQ NACK if the TB / CBG is not successfully decoded. The network can perform a fallback procedure and discard WTRU measurements / inputs and continue execution without reconfiguration. The fallback can be triggered when performance degradation is significant, such as when a large number of NACKs are received.
[0100] It can be beneficial to include WTRU based information in the reconfiguration request / decision because the granularity of information at the WTRU regarding statistics such as ACK / NACK and soft buffer decoding performance such as WTRU proximity when decoding retransmissions is not scalable to be maintained at the network, especially for a large number of users. It can be beneficial to include WTRU based information in the reconfiguration request / decision because receiver specific characteristics such as sensitivity / decoding performance are not available at the network side.
[0101] The underlying link refers to the physical air link between the WTRU and the gNB, where variations in latency and reliability occur due to propagation, fading, and similar wireless phenomena.
[0102] The ability to perform MAC layer provisioning of services with different reliability and latency requirements without the need to invoke procedures from higher layers such as RLC (e.g. operation of ARQ) and transport layer (TCP control mechanisms) is beneficial.
[0103] In one embodiment, the WTRU can send an indication to change the number of CBGs.
[0104] Based on measurements or using algorithms (e.g. empirical, probabilistic, online / offline trained AI models, or a combination of these), the WTRU can determine and indicate the optimal number of CBGs over a future time window (e.g. expressed as TTIs) and a precision metric of the indication (e.g. confidence interval, error margin, accuracy coefficient, or a combination of these). This is the solution that the WTRU considers to be the most suitable given its own estimation taking into account variations based on the underlying physical link.
[0105] Figure 9An example method 900 is shown in which a WTRU requests a change in the number of CBGs. The WTRU can receive first configuration information 905 indicating a first number of CBGs. The configuration information can be received, for example, from an upper layer or in a DCI. The WTRU can receive first DL grant information 910 scheduling a transmission of a first TB. The DL grant information can be a DCI. The DCI can be received over a physical downlink control channel (PDCCH). The WTRU can receive the first TB 915. The first TB can be received, for example, over a PDSCH. The first TB can be composed of the first number of CBGs. The WTRU can transmit a HARQ-ACK or HARQ-NACK 920 for each of the first number of CBGs. The WTRU can determine a second number of CBGs 925. The WTRU can determine the second number of CBGs based on one or more measurement values. The measurement values can be, for example, PDU delay / latency, PDU packet loss, statistics on ACKs and NACKs, PDU code block error distribution, soft buffer state statistics, and / or receiver characteristics (e.g., sensitivity threshold). The WTRU can determine the second number of CBGs based on a current ratio of ACKs / NACKs. The WTRU can determine the second number of CBGs based on an estimate or prediction of packet delay or latency (e.g., delay of a TB or time taken for a TB to be delivered from the network to the WTRU). The WTRU can determine the second number of CBGs based on any of the above elements or a combination of at least one of the above elements. The WTRU can determine the second number of CGBs using an AI model. Inputs to the AI model can include PDU delay / latency; PDU packet loss; PDU ACK / NACK statistics, such as an average number of ACKs / NACKs in a pre-defined time interval, a variation in time instances when these ACKs / NACKs are sent; PDU code block error distribution of code block errors; soft buffer state statistics; or receiver characteristics (e.g., sensitivity threshold). The determined second number of CBGs can provide a highest probability of decoding CBGs. The determined second number of CBGs can provide a probability of decoding CBGs that is below a threshold (e.g., a threshold configured by the network). The WTRU can determine an accuracy measure 930 associated with the determined second number of CBGs. The accuracy measure can be, for example, a confidence interval, an error margin, or a coefficient of accuracy. The accuracy measure can be a statistical measure. For example, a confidence interval can be an interval that is expected to contain an estimated parameter, following the formula: CI = Xmean + z(S / sqrt(n)), where Xmean is the sample mean, z is a confidence level value, S is the standard deviation, and n is the sample size. The WTRU can transmit an indication of the determined second number of CBGs and the associated accuracy measure 935. The WTRU can transmit the indication, for example, on a control channel. The WTRU can receive second configuration information 940 indicating a third number of CBGs.The WTRU can receive second DL grant information (e.g., DCI) 945 scheduling transmission of a second TB. The WTRU can receive the second TB 950. The second TB can consist of a third number of CBGs. The WTRU can transmit a HARQ-ACK or HARQ-NACK 955 for each of the third number of CBGs. The first number of CBGs can be a first maximum number of CBGs and the second number of CBGs can be a second maximum number of CBGs. The second number of CBGs can be the same or different from the third number of CBGs.
[0106] The WTRU can indicate a best number of CBGs and an accuracy metric for HARQ transmission. In one embodiment, the WTRU can use an algorithm or model (e.g., empirical, probabilistic estimation, or AI inference) to provide a prediction / estimation and determine a best or optimal number of CBGs. The WTRU can receive the model through a pre-configuration procedure, where the network communicates, sends, or indicates the model to the WTRU and is required to be used as part of the HARQ procedure. The WTRU can receive the model through registration with the network, where the model is communicated, sent, or indicated as part of the registration. The WTRU can receive the model through association with a specific network cell that supports the operation (i.e., the model is communicated, sent, or indicated and is only available in a predetermined number of network cells).
[0107] The WTRU can use the algorithm to determine a best or optimal number of CBGs by using measured transmission-related parameters or states as relevant inputs. For example, the WTRU can use one or any combination of the following: PDU latency / delay; PDU packet loss; PDU ACK / NACK statistics, such as an average number of ACK / NACKs in a predefined time interval, a variation in time instances when these ACK / NACKs are sent; PDU code block error distribution of code block errors; soft buffer state statistics; or receiver characteristics (sensitivity threshold).
[0108] The WTRU can use the algorithm to determine a best number of CBGs such that it provides a highest possible probability of decoding the PDU and / or keeps the probability of decoding below a predetermined threshold. This can be performed with a specific accuracy metric (e.g., a confidence interval, an error margin, a coefficient of accuracy, or a combination of these).
[0109] After determining the optimal or most optimal number of CBGs and the associated accuracy metric, the WTRU can choose to remain performing with the same network received CBG number, or it can indicate to the network a different or alternative number of CBGs and the accuracy metric for the indication. The determination of the optimal or most optimal number of CBGs can be performed using the WTRU's computational resources and using real-time measurements or status obtained from the underlying data transmission listed above. The accuracy metric related to the determined optimal or most optimal number of CBGs can be calculated or determined using the WTRU's computational resources by comparing the model output value to the real-time measurement / status value. If the predicted value cannot be calculated or determined, if the accuracy metric cannot be calculated or determined, or if the accuracy metric is calculated but it is below a threshold (e.g., a pre-defined threshold), the trigger to indicate to the network a change in the number of CBGs can not be generated. If the predicted value is calculated or determined, or if the accuracy metric is calculated or determined but it is above a threshold (e.g., a pre-defined threshold), the trigger to indicate to the network a change in the number of CBGs can be generated.
[0110] If there is no indication of a change in the number of CBGs, there can be no reconfiguration and no change in behavior. If the WTRU indicates a change in the number of CBGs and the associated accuracy metric for the change, the network can remain performing with the initial or current number of CGBs and discard or ignore the WTRU indication, or the network can reconfigure the number of CBGs. If the accuracy metric is not satisfactory to the network, or the network resources are constrained, and the MAC scheduler cannot support the suggested change, the network can remain performing with the initial or current number of CBGs and discard or ignore the WTRU indication. The network can reconfigure the number of CBGs by ensuring that there are no remaining PDUs waiting for retransmission, or start using the new number of CBGs (as indicated by the WTRU).
[0111] If the network reconfigures the number of CBGs, the WTRU should expect to receive modified control information indicating that a reconfiguration has occurred and that the HARQ PDUs will be transmitted with a new or modified number of CBGs. Thus, the WTRU should expect to receive a DCI including modified information (e.g., CBGFI or CBGTI) reflecting the change in the number of CBGs, and the change can be used to configure the value in the information element (e.g., IE-PDSCH- ServingCellConfig) that can be used to configure the maximum number of CBGs (e.g., through the variable maxCodeBlockGroupPerTransportBlock).
[0112] If the network estimates a performance drop after the reconfiguration, the WTRU should participate in the execution of a fallback procedure driven by the network, where the number of CBGs is restored to the initial or previously used number of CBGs and this number is signaled to the WTRU through modified control information.
[0113] The WTRU can send the relevant measurements to the network that performs the algorithm.
[0114] In one embodiment, the WTRU can not run the algorithm or provide any indication, however, the WTRU can act as a collector of relevant measurements for the algorithm and the evaluation can be done at the network side. The WTRU can format and locally store the relevant measurements and the WTRU can periodically send the stored measurements to the network, for example when the medium is idle and there is no user data transmission.
[0115] In one embodiment, the WTRU can keep performing the parameters (X) received by the network as a number of CBGs. The downlink service can have variable reliability and latency (as estimated by the network from the received ACKs and NACKs). To mitigate this impact, if the delay and reliability targets are not met, the network can initiate a preconfigured and send a model or algorithm (e.g. AI model trained offline) that the WTRU can use to make an estimation about the optimal number of CBGs (X*) that will be used to meet the specific delay and reliability targets.
[0116] The WTRU can store the received model and start collecting the model inputs. The WTRU can keep performing on the same configuration, however it can use the received measurements link information as input in the model and predict the optimal number of CBGs with a certain level of accuracy. The WTRU can perform the model and estimate X* with a precision metric. Based on the precision metric (level), the WTRU can indicate to the network the value of X* and the level of precision. The network can make a decision and reconfigure to X*, however only after the Tx buffer at the network has no pending retransmissions. The network can signal to the WTRU to use X-ray via DCI or IE (e.g. IE PDSCH-ServiceCellConfig) and can follow all the remaining standard procedures, however now the downlink service can be delivered using X* as the HARQ parameter to meet the target delay and reliability.
[0117] Figure 10An example flow diagram showing reconfiguration of the optimal number of CBGs for HARQ transmission is shown. The WTRU and network (NW) (e.g., gNB) can use a first HARQ configuration (X) 1005. The first HARQ configuration can be a number of CBGs. The network can determine whether the latency and reliability targets are met 1010. The network can determine whether the latency and reliability targets are met by comparing latency parameters (e.g., delay of TB, time taken for a TB to be delivered from the network to the WTRU) and / or reliability parameters (e.g., probability that a TB can be delivered, packet rate, error rate) to one or more thresholds. If the latency and reliability targets are met, the WTRU and gNB can remain using the current configuration. If the latency and reliability targets are not met, the gNB can initiate a pre-configuration 1015. The pre-configuration can include the gNB sending a model or algorithm (e.g., an AI model trained offline) to the WTRU. The pre-configuration can include a protocol (e.g., MAC) between the network and the WTRU regarding where to execute the algorithm, determining the type of algorithm, and exchanging additional information related to the initial setup (e.g., data format entries). The WTRU can receive the model through the pre-configuration procedure, where the network communicates, sends, or indicates the model to the WTRU and is required to be used as part of the HARQ procedure. The WTRU can receive the model through registration with the network, where the model is communicated, sent, or indicated as part of the registration. The WTRU can receive the model through association with a specific network cell that supports the operation (i.e., the model is communicated, sent, or indicated and is only available in a predetermined number of network cells).
[0118] The WTRU can store the model and start collecting model inputs 1020. The model inputs can be measured transmission related parameters or states. For example, the WTRU can use one or any combination of the following: PDU delay / latency; PDU packet loss; PDU ACK / NACK statistics, such as average number of ACK / NACK in a predefined time interval, variation in time instances when these ACK / NACK are sent; PDU code block error distribution of code block errors; soft buffer status statistics; and receiver characteristics (sensitivity threshold).
[0119] The WTRU can execute the model and estimate or determine the optimal number of CBGs (X*) and an accuracy metric 1025. For example, the accuracy metric can be a confidence interval, an error margin, or an accuracy factor that the WTRU can determine whether the accuracy metric is sufficient 1030. The WTRU can determine whether the accuracy metric is sufficient by comparing the accuracy metric to a threshold value (e.g., a network configured threshold value). If the accuracy metric is not sufficient, the WTRU and gNB can remain using the current configuration. If the accuracy metric is sufficient, the WTRU can send an indication of the estimated or determined optimal number of CBGs (X*) to the gNB 1035. The gNB can receive the indication of the estimated or determined optimal number of CBGs (X*) from the WTRU 1040. The gNB can determine whether to reconfigure the CBG number 1045. The determination can be based on X and X*. If the gNB determines not to reconfigure the CBG number, the WTRU and gNB can continue using the current configuration. If the gNB determines to reconfigure the CBG number, the network can send information to the WTRU indicating the reconfigured CBG number and use X* 1050. The information can be sent via, for example, DCI. The WTRU and gNB can use the reconfigured CBG X* 1055.
[0120] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in combination with others dependent upon the particular application. In addition, methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (optical, electrical or electromagnetic) that are transmittable through a wired or wireless connection. Examples of computer-readable media include, but are not limited to, a read only memory (ROM), random access memory (RAM), register, 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 in association with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
Claims
1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving first configuration information, the first configuration information indicating a first number of code block groups (CBGs); receiving first downlink (DL) scheduling information, the first DL scheduling information indicating a transmission of a first transport block (TB); receiving the first TB, wherein the first TB is comprised of the first number of CBGs; transmitting a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a HARQ negative acknowledgement (NACK) for each CBG of the first number of CBGs; determining a second number of CBGs based on at least one of: a measured value, a current ratio of ACKs to NACKs, and an estimate of packet delay or latency; determining a precision metric associated with the second number of CBGs, wherein the precision metric is at least one of: a confidence interval, an error margin, and an accuracy factor; transmitting the determined second number of CBGs and an indication of the determined precision metric; receiving second configuration information, the second configuration information indicating a third number of CBGs; receiving second DL scheduling information, the second DL scheduling information indicating a transmission of a second TB; receiving the second TB; and transmitting a HARQ-ACK or a HARQ-NACK for each CBG of the third number of CBGs.
2. The method of claim 1, further comprising: determining the second number of CBGs using an artificial intelligence (AI) model.
3. The method of claim 2, wherein the AI model is transmitted by a gNB.
4. The method of claim 2, wherein the WTRU receives the AI model based on registration with a network.
5. The method of claim 2, wherein the WTRU receives the AI model based on association with a network cell that supports reconfiguration operations.
6. The method of claim 2, wherein inputs to the AI model can include: packet data unit (PDU) delay or latency; PDU packet loss; an average number of ACKs / NACKs in a predefined time interval; PDU code block error distribution of code block errors; soft buffer status statistics; or receiver characteristics.
7. The method of claim 1, wherein the determined second number of CBGs provides a highest probability of decoding the CBGs.
8. The method of claim 1, wherein the determined second number of CBGs provides a probability of decoding the CBGs that is below a threshold value.
9. The method of claim 1, wherein the first DL scheduling information is downlink control information (DCI).
10. The method of claim 1, wherein the second TB is comprised of the third number of CBGs.
11. A wireless transmit / receive unit (WTRU), comprising: a receiver; a transmitter; and a processor, wherein: the receiver is configured to receive first configuration information, the first configuration information indicating a first number of code block groups (CBGs); the receiver is further configured to receive first downlink (DL) scheduling information, the first DL scheduling information indicating a transmission of a first transport block (TB); the transmitter is configured to transmit a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a HARQ negative acknowledgement (NACK) for each CBG of the first number of CBGs; the receiver is further configured to receive the first TB, wherein the first TB consists of the first number of CBGs; the transmitter is configured to transmit, for each CBG of the first number of CBGs, a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a HARQ negative acknowledgement (NACK); the processor is configured to determine a second number of CBGs based on at least one of: a measurement value, a current ratio of ACKs to NACKs, and an estimate of packet delay or latency; the processor is further configured to determine a precision metric associated with the second number of CBGs, wherein the precision metric is at least one of: a confidence interval, an error margin, and an accuracy coefficient; the transmitter is further configured to transmit an indication of the determined second number of CBGs and the determined precision metric; the receiver is further configured to receive second configuration information indicating a third number of CBGs; the receiver is further configured to receive second DL scheduling information indicating transmission of a second TB; the receiver is further configured to receive the second TB; and the transmitter is further configured to transmit, for each CBG of the third number of CBGs, a HARQ-ACK or a HARQ-NACK.
12. The WTRU of claim 11, wherein the processor is further configured to determine the second number of CBGs using an artificial intelligence (AI) model.
13. The WTRU of claim 12, wherein the AI model is transmitted by a gNB.
14. The WTRU of claim 12, wherein the WTRU receives the AI model based on registration with a network.
15. The WTRU of claim 12, wherein the WTRU receives the AI model based on association with a network cell that supports reconfiguration operations.
16. The WTRU of claim 12, wherein an input of the AI model can include: packet data unit (PDU) delay or latency; PDU packet loss; average number of ACKs / NACKs in a predefined time interval; PDU code block error distribution of code block errors; soft buffer status statistics; or receiver characteristics.
17. The WTRU of claim 1, wherein the determined second number of CBGs provides a highest probability of decoding the CBGs.
18. The WTRU of claim 11, wherein the determined second number of CBGs provides a probability of decoding CBGs that is below a threshold value.
19. The WTRU of claim 11, wherein the first DL scheduling information is downlink control information (DCI).
20. The WTRU of claim 11, wherein the second TB consists of the third number of CBGs.