Media Access Protocol Data Unit Assembly in Wireless Systems

Abstract

To provide systems for low latency MAC PDU assemblies in wireless systems, such as 5G Flexible Radio Access Technology.SOLUTION: The latency may be reduced by WTRU determination of network transmission parameters and signaling prior to transmission grant. The WTRU may receive a modulation and coding scheme, a resource range, etc., prior to granting, for example, for use in future grants. The data block may be generated / encoded prior to granting. A flexible grant size may be provided for early generation of transport blocks prior to granting. To allow early generation of MAC PDUs, a minimum guaranteed transport block size may be signaled.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] Relates to media access protocol data unit assembly in a wireless system.

Background Art

[0002] Cross - reference to related applications This application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 334,529, filed on May 11, 2016, which is incorporated herein by reference.

[0003] Mobile communication is continuously evolving. The fifth generation can be referred to as 5G. Previous (legacy) generations of mobile communication can be, for example, the fourth generation (4G) Long Term Evolution (LTE).

Summary of the Invention

[0004] Disclosed are systems, methods, and means relating to low-latency Media Access Control (MAC) protocol data unit (PDU) assemblies in wireless systems, such as 5G Flexible Radio Access Technology (RAT) (5gFLEX), including aspects of entities, interfaces, and procedures in wireless transmit / receive units (WTRUs) and / or network layers L1, L2, and L3. For example, latency can be reduced by identifying and signaling network transmit parameters by the WTRU prior to the transmit grant. The WTRU can receive the modulation and coding scheme (MCS), resource range, etc., prior to the grant, for example, for use in a future grant. Data blocks can be created / encoded incrementally prior to the grant. Data units can be segmented, assembled, and multiplexed based on a data block size that enables MAC and radio link control (RLC) processing prior to the grant, for example. Flexible grant sizes can be provided for early generation of transport blocks prior to the grant. To enable early generation of MAC PDUs, a minimum guaranteed transport block size (TBS) can be signaled. For example, transmission parameters can be selected prior to granting using blind decoding or DCI receiving procedures.

[0005] A wireless transmit / receive unit (WTRU) may include a processor configured to perform one or more of the following (for example, with executable instructions stored in memory): (i) search for and monitor downlink control information (DCI) across at least the resources of a downlink control channel; (ii) identify the resources of the downlink control channel; (iii) decode at least a first DCI on the downlink control channel, including scheduling information for at least one data transmission corresponding to one of downlink or uplink transmissions; (iv) identify at least one decoding parameter used to decode the first DCI; and (v) identify one or more transmit or receive parameters for at least one data transmission based on the at least one decoding parameter used to decode the first DCI.

[0006] At least one decoding parameter used to decode the first DCI may include one or more of the cyclic redundancy check length or aggregation level. The resources of the downlink control channel may include a set of physical resource blocks. At least one decoding parameter may indicate whether at least one data transmission is associated with one or more of the following: high-reliability data, low-latency data, or best-effort data.

[0007] The WTRU processor can be configured to send HARQ-ACK feedback via a resource associated with the identified decoding parameters of the decoded downlink control channel representation.

[0008] Decoding can include blind decoding. The decoding parameters can include a subset of resources used to decode the first DCI when performing blind decoding. The subset of resources can include one or more control channel elements (CCEs), and the identity of one or more CCEs can correspond to at least one decoding parameter.

[0009] At least one decoding parameter may include a robustness level associated with a first DCI. A higher robustness level with respect to the first DCI may indicate a higher robustness level with respect to data transmission, and a lower robustness level with respect to the first DCI may indicate a lower robustness level with respect to data transmission.

[0010] One or more transmit or receive parameters for at least one data transmission may include one or more of the Quality of Service (QoS) levels associated with at least one data transmission, or the Spectral Operating Mode (SOM) associated with at least one data transmission. One or more transmit or receive parameters for at least one data transmission may include Hybrid Automatic Retransmission Request (HARQ) feedback parameters associated with at least one data transmission. HARQ feedback parameters may include timing information for transmitting or receiving HARQ feedback.

[0011] The WTRU processor can be configured to receive configurations from network entities. This configuration can involve mappings between one or more decoding parameters and one or more transmit or receive parameters relating to at least one data transmission. At least one decoding parameter may include a DCI format.

[0012] One or more transmit or receive parameters relating to data transmission may include one or more of the following: a modulation and coding scheme (MCS), a set of physical resource blocks associated with at least one data transmission, power information associated with at least one data transmission, transmit timing information relating to at least one data transmission, or a transmit timer interval (TTI) duration associated with at least one data transmission.

[0013] A method of using WTRU may include one or more of the following steps: (i) searching for and monitoring downlink control information (DCI) across at least the resources of the downlink control channel; (ii) identifying the resources of the downlink control channel; (iii) decoding at least a first DCI on the downlink control channel, including scheduling information for at least one data transmission corresponding to one of downlink transmissions or uplink transmissions; (iv) identifying at least one decoding parameter used to decode the first DCI; and (v) identifying one or more transmit or receive parameters for at least one data transmission based on the at least one decoding parameter used to decode the first DCI.

[0014] A method of using a WTRU may include the steps of (i) sending HARQ-ACK feedback via a resource associated with a specified decoding parameter of a decoded downlink control channel representation, and / or (ii) receiving a configuration from a network entity, the configuration representing a mapping between one or more decoding parameters and one or more transmit or receive parameters relating to at least one data transmission. [Brief explanation of the drawing]

[0015] [Figure 1A] This is a system diagram of an exemplary communication system in which one or more disclosed embodiments can be implemented. [Figure 1B] Figure 1A is a system diagram of an exemplary WTRU that can be used within the communication system shown. [Figure 1C] Figure 1A is a system diagram of an exemplary wireless access network and an exemplary core network that can be used within the communication system shown. [Figure 1D] Figure 1A is a system diagram of another exemplary radio access network and another exemplary core network that can be used within the communication system shown. [Figure 1E] Figure 1A is a system diagram of another exemplary radio access network and another exemplary core network that can be used within the communication system shown. [Figure 2] This figure shows an example of transmission bandwidth. [Figure 3] This figure shows an example of flexible spectral assignment. [Figure 4] This figure shows an example of timing relationships related to TDD redundancy. [Figure 5] This figure shows an example of timing relationships related to FDD redundancy.

Best Mode for Carrying Out the Invention

[0016] Next, a detailed description of exemplary embodiments will be made with reference to various figures. It should be noted that this description provides detailed examples of possible embodiments, but those details are illustrative and are not intended to limit the scope of the present application in any way.

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

[0018] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs), e.g., WTRUs 102a, 102b, 102c, and / or 102d (which may be referred to collectively or collectively as WTRU 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the internet 110, and other networks 112, but it will be understood that the disclosed embodiments assume any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d can be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, and consumer electronics.

[0019] The communication system 100 can also include base stations 114a and 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, and / or network 112. By way of example, base stations 114a, 114b can be a base transceiver station (BTS), Node-B, eNode B, home Node B, home eNode B, site controller, access point (AP), wireless router, etc. Although base stations 114a, 114b are each shown as a single element, it will be understood that base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0020] Base station 114a can be part of RAN 103 / 104 / 105, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), radio network controller (RNC), relay node, etc. Base station 114a and / or base station 114b can be configured to transmit and / or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). A cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in some embodiments, base station 114a can include three transceivers, e.g., one transceiver for each sector of the cell. In another embodiment, base station 114a can employ multiple-input multiple-output (MIMO) technology and thus utilize multiple transceivers for each sector of the cell.

[0021] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via air interfaces 115 / 116 / 117, where air interfaces 115 / 116 / 117 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0022] More specifically, as described above, the communication 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, etc. For example, base stations 114a and WTRU 102a, 102b, 102c in RAN 103 / 104 / 105 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 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 Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0023] In another embodiment, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish air interfaces 115 / 116 / 117 using Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A).

[0024] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement wireless technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0025] In Figure 1A, base station 114b can be, for example, a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas, such as offices, homes, vehicles, or campuses. In some embodiments, base station 114b and WTRU 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRU 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRU 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. As shown in Figure 1A, base station 114b can have a direct connection to the Internet 110. Therefore, base station 114b may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0026] RAN103 / 104 / 105 can be in communication with core networks 106 / 107 / 109, 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 WTRU102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN103 / 104 / 105 and / or core networks 106 / 107 / 109 can be in direct or indirect communication with other RANs employing the same RAT as RAN103 / 104 / 105 or a different RAT. For example, core networks 106 / 107 / 109 may be connected to RANs 103 / 104 / 105, which may be using E-UTRA radio technology, and may also be in communication with another RAN (not shown) employing GSM radio technology.

[0027] Core networks 106 / 107 / 109 can also serve as gateways for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing simple old-fashioned telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as TCP, User Datagram Protocol (UDP), and IP in the Transmission Control Protocol (TCP) / Internet Protocol (IP) suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may employ the same RAT as RAN 103 / 104 / 105 or a different RAT.

[0028] Some or all of the WTRUs 102a, 102b, 102c, and 102d within the communication system 100 may include multimode functionality. For example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers to communicate with separate wireless networks via separate wireless links. For instance, WTRU 102c, shown in Figure 1A, can be configured to communicate with base station 114a, which may employ cellular-based radio technology, and base station 114b, which may employ IEEE 802 radio technology.

[0029] Figure 1B is a system diagram of an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the above elements while maintaining consistency with the embodiment. Furthermore, the embodiments assume that base stations 114a and 114b, and / or nodes to which base stations 114a and 114b can correspond (for example, among many others, a transceiver station (BTS), Node-B, site controller, access point (AP), home node-B, evolved home node-B (eNodeB), home evolved node-B (HeNB or HeNodeB), home evolved node-B gateway, and proxy node), may include some or all of the elements shown in Figure 1B and described herein.

[0030] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. 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 a transceiver 120, and the transceiver 120 can be coupled to a transmit / receive element 122. Although Figure 1B shows the processor 118 and transceiver 120 as separate components, the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0031] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interfaces 115 / 116 / 117. For example, in some embodiments, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0032] In addition, although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Therefore, in some embodiments, the WTRU 102 can include multiple transmit / receive elements 122 (e.g., multiple antennas) to transmit and receive wireless signals via the air interfaces 115 / 116 / 117.

[0033] The transceiver 120 can be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal to be received by the transmit / receive element 122. As described above, the WTRU 102 can have multimode capabilities. Therefore, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0034] The processor 118 of the WTRU102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from there. 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 any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in those memories. 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. Removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 can access information from memory on, for example, a server or home computer (not shown), which is not physically located on the WTRU 102, and store data in that memory.

[0035] The processor 118 can receive power from the power supply 134 and can also be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 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.), a solar cell, a fuel cell, etc.

[0036] The processor 118 may also be coupled to a 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 instead of, the information from the GPS chipset 136, the WTRU 102 may determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117 and / or based on the timing of signals received from multiple neighboring base stations. It will be understood that the WTRU 102 may acquire location information through any suitable location determination embodiment while maintaining consistency with the embodiment.

[0037] The processor 118 can be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide further features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, e-compass, satellite transceiver, digital camera (for photography or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, internet browser, and the like.

[0038] Figure 1C is a system diagram of RAN103 and core network 106 according to an embodiment. As described above, RAN103 can employ UTRA radio technology to communicate with WTRU102a, 102b, and 102c via air interface 115. RAN103 can also be in communication with core network 106. As shown in Figure 1C, RAN103 may include Node-B140a, 140b, and 140c, each of which can include one or more transceivers to communicate with WTRU102a, 102b, and 102c via air interface 115. Node-B140a, 140b, and 140c can each be associated with a specific cell (not shown) within RAN103. RAN103 may also include RNC142a and 142b. It will be understood that RAN103 can include any number of Node-B and RNC while maintaining consistency with the embodiment.

[0039] As shown in Figure 1C, Node-B140a and 140b can communicate with RNC142a. In addition, Node-B140c can communicate with RNC142b. Node-B140a, 140b, and 140c can communicate with each other via the Iub interface. RNC142a and 142b can communicate with each other via the Iur interface. Each of RNC142a and 142b can be configured to control each of the Node-B140a, 140b, and 140c to which it is connected. In addition, each of RNC142a and 142b can be configured to perform or support other functionalities, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0040] The core network 106 shown in Figure 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the elements described above is shown as part of the core network 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0041] RNC142a in RAN103 can be connected to MSC146 in core network 106 via the IuCS interface. MSC146 can be connected to MGW144. MSC146 and MGW144 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial communication line devices.

[0042] RNC142a in RAN103 can also be connected to SGSN148 in core network 106 via the IuPS interface. SGSN148 can be connected to GGSN150. SGSN148 and GGSN150 can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0043] As described above, the core network 106 may also be connected to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0044] Figure 1D is a system diagram of RAN104 and core network 107 according to an embodiment. As described above, RAN104 can employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via air interface 116. RAN104 can also be in communication with core network 107.

[0045] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers to communicate with WTRU102a, 102b, and 102c via the air interface 116. In some embodiments, eNode-B160a, 160b, and 160c can implement MIMO technology. Thus, eNode-B160a may use multiple antennas, for example, to transmit wireless signals to and from WTRU102a.

[0046] Each of the eNode-B160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink (UL) and / or downlink (DL), etc. As shown in Figure 1D, the eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0047] The core network 107 shown in Figure 1D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the elements described above is shown as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0048] The MME162 can be connected to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial connection of WTRU102a, 102b, and 102c. The MME162 can also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other wireless technologies, such as GSM or WCDMA.

[0049] The serving gateway 164 can be connected to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface. The serving gateway 164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The serving gateway 164 can also perform other functions, such as fixing the user plane during handover between eNode B, triggering paging when downlink data is available for WTRU102a, 102b, and 102c, and managing and storing the context of WTRU102a, 102b, and 102c.

[0050] Serving gateway 164 can also be connected to PDN gateway 166, which can provide WTRU 102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0051] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRU 102a, 102b, and 102c and conventional terrestrial communication line devices. For example, the core network 107 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and PSTN 108. In addition, the core network 107 can provide WTRU 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0052] Figure 1E is a system diagram of RAN105 and core network 109 according to an embodiment. RAN105 can be an access service network (ASN) employing IEEE 802.16 wireless technology to communicate with WTRU102a, 102b, and 102c via air interface 117. As will be discussed further below, communication links between the separate functional entities of WTRU102a, 102b, 102c, RAN105, and core network 109 can be defined as reference points.

[0053] As shown in Figure 1E, RAN105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it will be understood that RAN105 may include any number of base stations and ASN gateways while maintaining consistency with the embodiment. Each of the base stations 180a, 180b, and 180c can be associated with a specific cell (not shown) within RAN105 and may each include one or more transceivers to communicate with WTRU102a, 102b, and 102c via the air interface 117. In some embodiments, the base stations 180a, 180b, and 180c can implement MIMO technology. Thus, base station 180a may use multiple antennas, for example, to transmit wireless signals to and from WTRU102a. Base stations 180a, 180b, and 180c can also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, and quality of service (QoS) policy enforcement. The ASN gateway 182 can act as a traffic aggregation point and is responsible for paging, subscriber profile caching, and routing to the core network 109.

[0054] The air interface 117 between WTRU102a, 102b, and 102c and RAN105 can be defined as an R1 reference point implementing the IEEE802.16 specification. In addition, each of WTRU102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. The logical interface between WTRU102a, 102b, and 102c and the core network 109 can be defined as an R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0055] The communication links between base stations 180a, 180b, and 180c can be defined as R8 reference points, which include protocols to facilitate WTRU handover and data transfer between base stations. The communication links between base stations 180a, 180b, and 180c and the ASN gateway 182 can be defined as R6 reference points. These R6 reference points may include protocols to facilitate mobility management based on mobility events associated with WTRUs 102a, 102b, and 102c, respectively.

[0056] As shown in Figure 1E, RAN 105 can be connected to the core network 109. The communication link between RAN 105 and the core network 109 can be defined, for example, as an R3 reference point containing protocols to facilitate data transfer and mobility management functions. The core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication / Authorization / Accounting (AAA) server 186, and a gateway 188. While each of the elements described above is shown as part of the core network 109, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0057] The MIP-HA can be responsible for IP address management and can enable WTRU102a, 102b, and 102c to roam between separate ASNs and / or separate core networks. The MIP-HA184 can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110 to facilitate communication between them and IP-enabled devices. The AAA server 186 can be responsible for user authentication and supporting user services. The gateway 188 can facilitate interaction with other networks. For example, the gateway 188 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as the PSTN 108 to facilitate communication between them and conventional terrestrial communication line devices. In addition, gateway 188 can provide access to network 112 to WTRU 102a, 102b, and 102c, and network 112 may include other wired or wireless networks owned and / or operated by other service providers.

[0058] Although not shown in Figure 1E, RAN105 can be connected to other ASNs, and core network 109 can be connected to other core networks. The communication link between RAN105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRU102a, 102b, and 102c between RAN105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference, which may include protocols for facilitating interaction between the home core network and the visited core network.

[0059] For example, an air interface for new radio (NR) access technologies in 5G systems can support a variety of use cases, such as improved broadband performance (IBB), industrial control and communications (ICC) and vehicle-to-vehicle (V2X) applications, and massive machine-type communications (mMTC). These use cases can have associated support in the air interface (e.g., a 5G air interface).

[0060] The air interface can support, for example, ultra-low transmit latency (LLC), ultra-reliable transmit (URC), and MTC operations (including narrowband operations).

[0061] Support for ultra-low transmit latency (LLC) can include, for example, RTT of 1 ms and air interface latency such as TTI between 100 us and 250 us. Support for ultra-low access latency (e.g., time from initial system access to completion of transmission of the first user plane data unit) can be provided. For example, for IC and V2X, end-to-end (e2e) latency of less than 10 ms can be supported.

[0062] Support for Ultra-Reliable Transmission (URC) can include improved transmission reliability, such as 99.999% transmission success and service availability. Support for mobility speeds in the range of 0-500 km / h can be provided. For example, for IC and V2X, 10e -6 It is possible to support packet loss rates below a certain level.

[0063] Support for MTC operations may include, for example, narrowband operations (e.g., using frequencies below 200 kHz), extended battery life (e.g., up to 15 years of autonomy), and air interface support for minimal communication overhead for small amounts of infrequent data transmission (e.g., low data rates ranging from 1 to 100 kbps with access latency from a few seconds to several hours).

[0064] 5gFLEX systems can be implemented using OFDM and / or other waveforms for uplink and / or downlink. The examples described herein are non-limiting. Examples are applicable and adaptable to other waveforms and wireless technologies.

[0065] OFDM can be used, for example, as a signal format for data transmission in LTE and IEEE 802.11. OFDM can efficiently divide the spectrum into multiple parallel orthogonal subbands. Each subcarrier can be shaped using a rectangular window in the time domain, which can lead to a sinc-shaped subcarrier in the frequency domain. OFDM may rely on tight management of (e.g., perfect) frequency synchronization and uplink timing alignment within the duration of the cyclic prefix, for example, to maintain orthogonality between signals and to minimize interference between carriers. Tight synchronization can be difficult, for example, in systems where a WTRU may be connected to multiple access points simultaneously. Further power reductions may be applied to uplink transmissions, for example, to comply with spectral emission requirements for adjacent bands. For WTRU transmissions, the fragmented spectrum can be aggregated.

[0066] For example, OFDM (CP-OFDM) performance can be improved by more stringent RF requirements for embodiments, such as operations using large amounts of continuous spectrum that do not require aggregation. CP-based OFDM transmission schemes can provide 5G with a downlink physical layer similar to that of 4G systems, with modifications for pilot signal density and location.

[0067] The 5gFLEX downlink transmission scheme can be based on multicarrier waveforms, which can be characterized by high spectral containment (e.g., lower sidelobes and lower OOB radiation). Multicarrier (MC) waveforms for 5G can include, for example, OFDM-OQAM and / or UFMC (UF-OFDM).

[0068] A multi-carrier modulated waveform allows for the division of channels into subchannels, and data symbols can be modulated on the subcarriers within those subchannels.

[0069] In filtered-band multicarrier (FBMC) examples such as OFDM-OQAM, filtering can be applied to the OFDM signal in the time domain for each subcarrier, for example, to reduce out-of-band (OOB). OFDM-OQAM may result in very low interference to adjacent bands, may not require large guard bands, and may be implemented without cyclic prefixes. OFDM-OQAM may be sensitive to multipath effects and high delay spread in terms of orthogonality, which can complicate equalization and channel estimation.

[0070] In examples of universally filtered multicarrier (UFMC) systems, such as UF-OFDM, filtering can be applied to the OFDM signal in the time domain to reduce out-of-band (OOB). Filtering can be applied per subband to utilize spectral fragmentation, which reduces complexity and makes UF-OFDM more practical to implement. OOB emissions in unused spectral fragmentation within a band can be as high as in OFDM. While UF-OFDM offers some improvement over OFDM at the edges of the filtered spectrum, it may offer little to no improvement at spectral holes.

[0071] These waveforms enable frequency division multiplexing of signals with non-orthogonal features (such as different subcarrier spacings) and coexistence of asynchronous signals without the need for complex interference cancellation receivers. These waveforms can facilitate aggregation of spectral fragments in baseband processing, for example, as a lower-cost alternative to its embodiment as part of RF processing.

[0072] For example, to support mMTC narrowband operation using, for instance, SCMA, the coexistence of various waveforms within the same bandwidth can be considered. Various waveforms, such as CP-OFDM, OFDM-OQAM, and UF-OFDM, can be combined within the same bandwidth, for example, in all aspects, and with respect to downlink and uplink transmissions. The coexistence of various waveforms can include transmissions using different types of waveforms between separate WTRUs, or transmissions from the same WTRU, for example, simultaneously, with some overlap or continuity in the time domain.

[0073] Other coexistence modes may include support for waveforms and / or transmissions that can support hybrid-type waveforms, for example, possibly fluctuating CP durations (e.g., from one transmit to another), combinations of CP and low-power tails (e.g., zero tails), and / or forms of hybrid guard intervals (e.g., using low-power CP and a suitable low-power tail). Waveforms may support other modes of dynamic variation and / or control, such as how filtering is applied (e.g., filtering is applied at the spectral edges used for receiving any transmit with respect to a given carrier frequency, at the spectral edges used for receiving transmits associated with a particular SOM, per subband, or per group thereof).

[0074] The uplink transmission scheme can use the same or different waveforms as those used for downlink transmission.

[0075] Transmissions between separate WTRUs within the same cell can be multiplexed, for example, based on FDMA and TDMA.

[0076] 5gFLEX radio access can be characterized by a very high degree of spectral flexibility, enabling deployment across various frequency bands with a variety of features, including various duplex arrangements, such as continuous and discontinuous spectral allocation in the same or separate bands, and a variety of available spectral sizes and variable sizes. 5gFLEX radio access can support variable timing modes, such as support for multiple TTI lengths and asynchronous transmission.

[0077] Multiple redundancy schemes (e.g., TDD, FDD) can be supported. For example, with respect to FDD operations, supplemental downlink operations can be supported, for example, using spectral aggregation. FDD operations can support both full-duplex and half-duplex FDD operations. DL / UL allocation can be dynamic, for example with respect to TDD operations (e.g., not based on a fixed DL / UL frame configuration). The length of the DL transmit interval or UL transmit interval can be set for each transmit opportunity.

[0078] A feature or capability of a 5G air interface can enable separate transmit bandwidths on uplink and downlink, for example, varying between the nominal system bandwidth and the maximum value corresponding to that system bandwidth.

[0079] A single carrier operation can support a variety or range of system bandwidths, such as 5, 10, 20, 40, and 80 MHz, 160 MHz, etc. The nominal bandwidth can have one or more fixed values. Narrowband transmission (e.g., 0 to 200 kHz) can be supported within the operating bandwidth of the MTC device.

[0080] The system bandwidth can refer to the largest portion of the spectrum that can be managed by the network with respect to a given carrier. The spectral portion of the carrier that the WTRU minimally supports with respect to cell acquisition, measurement, and initial access to the network can correspond to the nominal system bandwidth. The WTRU can be configured with channel bandwidths that can be within the range of the full system bandwidth. The channel bandwidths configured in the WTRU may or may not include the nominal portion of the system bandwidth, for example, as shown in the example in Figure 2.

[0081] Figure 2 shows an example of transmit bandwidth. Figure 2 shows the nominal system bandwidth (cell) (e.g., 5 MHz), UEx channel bandwidth (e.g., 10 MHz), UEy channel bandwidth (e.g., 20 MHz), and UEz channel bandwidth (5 MHz) all as separate allocations (may or may not overlap) within the system bandwidth (e.g., 20 MHz). UE refers to WTRU. Bandwidth flexibility can be achieved, for example, by having (e.g., all) applicable sets of RF requirements for a given maximum operating bandwidth within the bandwidth satisfyable without introducing further permitted channel bandwidths for that operating bandwidth, for example, due to efficient support for baseband filtering of frequency domain waveforms.

[0082] The channel bandwidth of the WTRU for single-carrier operation can be configured, reconfigured, and / or dynamically changed. Spectra can be allocated for narrowband transmission within the nominal system, system, or configured channel bandwidth.

[0083] The 5G air interface physical layer can be bandwidth-independent and can support operations in both licensed (e.g., below 5 GHz) and unlicensed (e.g., in the 5-6 GHz range). For example, for operations in the unlicensed band, an LBT Cat4-based channel access framework similar to LTE LAA can be supported.

[0084] Cell-specific and / or WTRU-specific channel bandwidths for any spectral block size can be increased, decreased, and managed (e.g., scheduling, resource addressing, broadcast signals, measurements, etc.).

[0085] Downlink control channels and signals can support FDM operations. A WTRU can acquire a downlink carrier by receiving a transmission using, for example, a nominal portion (e.g., only) of the system bandwidth. For example, a WTRU may not initially receive a transmission that covers the entire bandwidth managed by the network for the carrier in question.

[0086] Downlink data channels can be allocated across bandwidths that may or may not correspond to the nominal system bandwidth, without any constraints other than, for example, being within the channel bandwidth configured for a WTRU. For example, a network could operate a carrier with a 12 MHz system bandwidth using a 5 MHz nominal bandwidth, allowing a device supporting a maximum RF bandwidth of 5 MHz to acquire and access the system, while potentially allocating carrier frequencies of +10 to -10 MHz to other WTRUs supporting channel bandwidths equivalent to up to 20 MHz.

[0087] Figure 3 is an example of flexible spectral allocation. Figure 3 shows an example of spectral allocation where separate subcarriers can be allocated (for example, at least conceptually) to separate modes of operation (hereafter referred to as spectral operation modes or SOMs). Separate SOMs can be used to satisfy separate requirements for separate transmissions. An SOM can consist of subcarrier spacing, TTI length, and / or one or more reliability modes (e.g., HARQ processing mode, secondary control channel). An SOM can be used to point to (for example, a specific) waveform, or can be related to a processing mode (e.g., in the coexistence of separate waveforms on the same carrier using FDM and / or TDM, or in the support of coexistence of FDD operations in the TDD band (e.g., with support in TDM mode, etc.)).

[0088] A WTRU can be configured to perform transmissions according to one or more SOMs. For example, an SOM can accommodate transmissions used for at least one of the following: a specific TTI duration, a specific initial power level, a specific HARQ processing type, a specific upper limit on successful HARQ reception / transmission, a specific transmission mode, a specific physical channel (uplink or downlink), a specific waveform type, or even transmissions according to a specific RAT (e.g., according to LTE or 5G transmission technology). An SOM can accommodate QoS levels and / or related aspects (e.g., maximum / target latency, maximum / target BLER, etc.). An SOM can accommodate spectral areas and / or specific control channels or aspects thereof (e.g., search space or DCI type). For example, a WTRU can be configured with SOMs for URC type services, LLC type services, and / or MBB type services. The WTRU can have a configuration relating to the SOM for system access and / or transmission / reception of L3 control signaling (e.g., RRC) in a portion of the spectrum associated with the system, such as in the nominal system bandwidth.

[0089] Spectral aggregation may be supported (for example, with respect to single-carrier operation). WTRUs may support the transmission and reception of multiple transport blocks across consecutive or discontinuous sets of physical resource blocks (PRBs) within the same operating bandwidth. Mapping of a single transport block to separate sets of PRBs may be supported. Support for simultaneous transmissions associated with separate SOM requirements may be provided.

[0090] For example, multi-carrier operation can be supported using consecutive or discontinuous spectral blocks within the same operating band or across multiple operating bands. Support can be provided for aggregation of spectral blocks using separate modes (e.g., FDD and TDD) and / or separate channel access methods (e.g., licensed band operation and unlicensed band operation below 6 GHz). Support can be provided for procedures to configure, reconfigure, and / or dynamically modify WTRU multi-carrier aggregation.

[0091] Downlink (DL) and uplink (UL) transmissions can be organized into radio frames characterized by multiple fixed aspects (e.g., location of downlink control information) and multiple variable aspects (e.g., transmission timing, supported transmission type).

[0092] The basic time interval (BTI) can be expressed as an integer number of one or more symbols, and the symbol duration can be a function of subcarrier spacing applicable to the time-frequency resource. Subcarrier spacing (for example, with respect to an FDD) is a function of the uplink carrier frequency f with respect to a given frame. UL and downlink carrier frequency f DL It is possible for them to differ in that respect.

[0093] The transmit time interval (TTI) may exclude the preamble and may include control information (e.g., DCI for downlink or UCI for uplink), downlink (TTI DLWith respect to the uplink (UL TRx), each can be associated with a separate transport block (TB), and it is possible to correspond to the minimum time supported by the system between consecutive transmissions. TTI can be represented by one or more integer numbers of BTI. BTI can be specific to and / or associated with a given SOM.

[0094] For example, supported frame durations can include, for instance, 100us, 125us (1 / 8ms), 142.85us (1 / 7ms, which can be a 2nCP LTE OFDM symbol), and 1ms, in order to enable alignment with LTE timing structures.

[0095] A frame is the carrier frequency involved (f in the case of TDD). UL+DL Regarding FDDs DL A fixed duration t preceding the downlink data transmission (DL TRx) related to ) dci It is possible to start with the Downlink Control Information (DCI).

[0096] A frame can consist of a downlink portion (DCI and DL TRx) (for example, in the case of TDD redundancy) and an uplink portion (UL TRx) (for example, optionally). A switching gap (swg) can precede the uplink portion of the frame (for example, if one exists) (for example, with respect to a frame in a given configuration).

[0097] A frame can consist of a downlink reference TTI (for example, with respect to TDD duplication) and one or more TTIs (for example, with respect to the uplink). The start of the uplink TTI is applied from the start of the downlink reference frame, which may overlap with the start of the uplink frame, by an offset (t offset It is possible to derive this using ).

[0098] 5gFLEX can support D2D / V2x / sidelink operations in a frame (for example, with respect to TDD) by including each downlink control and forward transmission in the DCI+DL TRx portion (for example, when quasi-static allocation of each resource is used) or in the DL TRx portion (for example, in the case of dynamic allocation), and including each reverse transmission in the UL TRx portion.

[0099] 5gFLEX can support D2D / V2x / sidelink operations in the UL TRx portion of a frame (for example, with respect to FDDs) by including the respective downlink control, forward transmit, and reverse transmit in the UL TRx portion. Dynamic allocation of each resource can be used.

[0100] Figures 4 and 5 provide examples of frame structures. Figure 4 shows an example of timing relationships for TDD redundancy. Figure 5 shows an example of timing relationships for FDD redundancy.

[0101] Scheduling functionality can be supported at the MAC layer. Support can be provided for multiple (e.g., two) scheduling modes, such as network-based scheduling (for example, with regard to tight scheduling in terms of resources, timing, and transmission parameters for downlink and / or uplink transmissions) and WTRU-based scheduling (for example, with regard to more flexibility in terms of timing and transmission parameters). Scheduling information regarding modes can be valid for one or more TTIs.

[0102] Network-based scheduling can allow the network to tightly manage available radio resources allocated to separate WTRUs, which can enable optimal resource sharing. Dynamic scheduling can also be supported.

[0103] WTRU-based scheduling can, for example, allow WTRUs to opportunistically access uplink resources with minimal latency whenever needed, within a set of shared or dedicated uplink resources allocated by the network (e.g., statically or dynamically). Support for synchronized opportunistic and unsynchronized opportunistic transmissions can be provided. Support for contention-based and contention-free transmissions can also be provided.

[0104] For example, to meet the very low latency requirements for 5G and the power saving requirements for mMTC, support for opportunistic transmissions (scheduled or unscheduled) can be provided.

[0105] 5gFLEX can support one or more forms of association between data available for transmission and available resources for uplink transmission. For example, multiplexing of data with different QoS requirements within the same transport block can be supported, provided that the multiplexing does not negatively impact services with the most stringent QoS requirements and does not result in unnecessary waste of system resources.

[0106] It is possible to encode a transmission using multiple different encoding methods. Different encoding methods can have different characteristics.

[0107] For example, the encoding method can generate a sequence of information units. Each information unit, or block, can be self-contained. For example, an error in the transmission of a first block can not impair the receiver's ability to successfully decode a second block if there is no error in the second block and / or if sufficient redundancy can be found in the second block, or in another block that has been successfully decoded in part.

[0108] An example of encoding techniques may include Raptor / Fountain Codes, for instance, a transmission may consist of a sequence of N Raptor Codes. One or more Codes may be mapped to one or more transmission "symbols" in time. A "symbol" may correspond to one or more sets of information bits, for example, one or more octets. Encoding may be used to add FEC to a transmission, for example, a transmission may use N+1 or N+2 Raptor Codes or symbols (assuming, for example, one Raptor Code symbol relationship). A transmission may have further resilience to the loss of one "symbol" due to interference or puncture by another transmission overlapping in time, for example.

[0109] A WTRU can be configured to receive and / or detect one or more system signatures. A system signature can consist of a signal structure using a sequence. The signal can be similar to a synchronization signal, for example, similar to LTE PSS and / or SSS. A signature can be specific to a particular node (or TRP) in a given area (for example, it can uniquely identify that node (or TRP)), or it can be common to multiple nodes (or TRPs) in an area, and its form can be unknown to and / or unrelated to the WTRU. A WTRU can identify and / or detect a system signature sequence and further identify one or more parameters associated with the system. For example, a WTRU can derive an index from it and use that index to retrieve the associated parameters in a table, for example, an access table. For example, a WTRU can use the received power associated with a signature for open-loop power control, for example, to set the initial transmit power when the WTRU determines that it can access (and / or transmit) using the system's applicable resources. For example, a WTRU can use the timing of an received signature sequence to set the timing of transmission (e.g., a preamble on a PRACH resource) if the WTRU determines that it is able to access (and / or send) it using applicable resources of the system.

[0110] A WTRU can consist of a list of one or more entries. This list may be called an access table. The list can be indexed, and for example, each entry can be associated with a system signature and / or a sequence thereof. The access table can provide initial access parameters for one or more areas. Each entry can provide one or more parameters necessary to perform the initial access to the system. Parameters can include one or more random access parameters in time and / or frequency (including applicable physical layer resources such as PRACH resources), an initial power level, and / or at least one of a set of physical layer resources for receiving a response. Parameters can also include access constraints (e.g., PLMN identity and / or CSG information). Parameters can also include routing-related information, such as one or more applicable routing areas. Entries can be associated with (and / or indexed by) a system signature. Such entries can be common to multiple nodes (or TRPs). WTRUs can be received via transmission using dedicated resources (e.g., via RRC configuration) and / or transmission using broadcast resources. In the latter case, the transmission period for access tables can be relatively long (e.g., up to 10240ms), which can be longer than the transmission period for signatures (e.g., in the range of 100ms).

[0111] A logical channel (LCH) can represent a logical association between data packets and / or PDUs. The association can be based on data units associated with the same bearer (similar to legacy systems) and / or the same SOM and / or slice (e.g., a processing path using a set of physical resources). For example, an association can be characterized by a chain of processing functions, an applicable physical data (and / or control) channel (or an instance thereof), or at least one of (i) a centralized part (e.g., PDCP, or everything beyond the physical layer processing part such as the radio front (RF) end) and (ii) another part closer to the edge (e.g., TRP or MAC / PHY in RF) and an instantiation of the protocol stack, potentially separated by a front-hauling interface. The term LCH as used herein may have different and / or broader meanings than similar terms relating to LTE systems.

[0112] A WTRU can be configured to identify relationships between separate data units. These relationships can be based on a matching function (for example, based on the configuration of one or more field values ​​common to data units that are part of the same logical association). The fields can correspond to fields in the protocol header associated with the data unit. For example, the matching function can use a tuple of parameters relating to fields in the data unit's IP header, such as IP source / destination addresses, transport protocol source / destination ports and transport protocol type, IP protocol version (e.g., IPv4 or IPv6), etc.

[0113] For example, data units that are part of the same logical association can share common radio bearers, processing functions, and SOMs, and / or can correspond (for example, at least conceptually) to the same LCH and / or LCG.

[0114] A Logical Channel Group (LCG) can consist of a group of LCHs (or equivalents as defined above), and the grouping can be based on one or more criteria, for example. Criteria may include, for example, that one or more LCHs can have similar priority levels applicable to all LCHs in the same LCG, or that they can be associated with the same SOM (or its type), the same slice (or its type). For example, the association can be characterized by at least one of the following: a chain of processing functions, applicable physical data (and / or control) channels (or instances thereof), or an instantiation of a protocol stack which may include (i) a specific centralized part (e.g., PDCP, or everything other than RF) and (ii) another part closer to the edge (e.g., TRP, or MAC / PHY in RF), potentially separated by a front-hauling interface. The term LCG as used herein may have different and / or broader meanings than similar terms relating to LTE systems.

[0115] A transport channel (TrCH) can consist of a specific set of processing steps and / or a specific set of functions applied to data information that may affect one or more transmission features over a radio interface.

[0116] LTE allows for the definition of multiple types of transport channels (TrCHs), including broadcast channels (BCH), paging channels (PCH), downlink shared channels (DL-SCH), multicast channels (MCH), uplink shared channels (UL-SCH), and random access channels (which may not carry user plane data). Transport channels for carrying user plane data can include DL-SCHs and UL-SCHs for downlink and uplink, respectively.

[0117] Air interfaces for 5G systems can support an increased set of requirements. For one or more WTRU devices, support for multiple transport channels, for example, for user plane data and / or control plane data, can be provided. The term TrCH as used herein can have different and / or broader meanings than similar terms for LTE systems. For example, transport channels for URLLC (e.g., URLLCH), transport channels for mobile broadband (MBBCH), and / or transport channels for machine-type communications (MTCCH) can be defined with respect to downlink transmissions (e.g., DL-URLLCH, DL-MBBCH, and DL-MTCCH) and with respect to uplink transmissions (e.g., UL-URLLCH, UL-MBBCH, and UL-MTCCH).

[0118] In the example, multiple TrCHs can be mapped to different sets of physical resources (e.g., PhCHs) belonging to the same SOM. This can be advantageous, for example, in supporting the simultaneous transmission of traffic with separate requirements over the same SOM. An example of this might be sending a URLLCH along with an MTCCH when a WTRU is configured with a single SOM.

[0119] A WTRU can be configured with one or more parameters associated with characterizing how data should be transmitted. The characterization can represent constraints and / or requirements that the WTRU is expected to satisfy and / or enforce. Based on the state associated with the data based on the characterization, the WTRU can perform separate operations and / or adjust its actions. Parameters can include, for example, time-related aspects (e.g., Time To Live (TTL) for a packet, before which the packet should be transmitted in order to satisfy or be perceived as satisfying latency requirements), rate-related aspects, and configuration-related aspects (e.g., absolute priority). Parameters may also change over time while a packet or data may be pending for transmission.

[0120] 5G air interfaces can support a variety of use cases with different QoS requirements, for example, in terms of the distinction between applicable radio resources and transmission methods. For instance, the TTI duration, reliability, diversity, and maximum latency applied to transmission can vary across different use cases.

[0121] WTRU may face further challenges in terms of processing bottlenecks, for example, due to increased throughput and reduced latency (e.g., shorter TTI duration and reduced processing time).

[0122] The procedure allows for the optimization of the creation and assembly of Layer 2 protocol data units (e.g., MAC PDUs).

[0123] RLC segmentation, assembly, MAC layer multiplexing, and PHY layer encoding can be performed after the grant is received. The grant latency for UL transmission may not be improved to the extent that it exceeds the hardware and software latency of these operations.

[0124] Procedures for segmentation, assembly, and multiplexing can be provided. Scheduling functions (for example, in a network) may or may not have timely information and / or precise knowledge of the QoS requirements associated with the data available for transmission in the WTRU buffer. WTRUs can take actions to enable services with stringent reliability and / or latency requirements (for example, for URLLC services).

[0125] A WTRU can use parameters to impact how and what data is transmitted, and how PDUs are generated. A WTRU can be composed of one or more parameters associated with characterizing how the data should be transmitted. The characterization can represent constraints and / or requirements that the WTRU is expected to satisfy and / or enforce. A WTRU can, for example, perform separate operations and / or adjust its actions based on the state associated with the data based on the characterization.

[0126] The actions may be related to PDU assembly and constraints in terms of processing time, for example. The WTRU may identify that one or more procedures, such as those described herein, may be applicable.

[0127] The procedures described herein, whether described herein or elsewhere, can be used in whole or in part, alone or in combination with any other procedures. One or more exemplary procedures described herein can be performed or applied in part or in whole on a network or WTRU.

[0128] Prior to granting, procedures for identifying PHY layer parameters may be provided. For example, a WTRU may identify or be configured with PHY layer parameters for data transmission prior to receiving a grant for UL transmission. Early identification of parameters may allow some PHY layer processing to be performed by the WTRU before the UL grant, which may be beneficial in enabling the WTRU to perform UL transmission with minimal delay from the transmission of the UL grant for a particular type of data, for example, to minimize the latency associated with UL transmission. Early identification of PHY layer parameters may be employed in conjunction with other procedures described herein (for example, also).

[0129] PHY layer parameters identified prior to a grant can be applied to a specific logical channel, transport channel, traffic type, or SOM. Parameters configured or provided to a WTRU before grant reception can consist of, for example, the modulation scheme, coding scheme and coding-related parameters to be applied to the data, HARQ-related parameters (e.g., the HARQ process type or HARQ features to be adopted), transport block size, rules for associating L2 data with a specific PHY resource (e.g., which PHY resources or ranges of PHY resources can be used to transmit a particular resource), and one or more of the PHY resources or supersets of PHY resources associated with the final grant. PHY layer information can be a superset of resources that can be refined by the grant itself.

[0130] Parameters can be signaled from the network. For example, a WTRU can receive PHY layer parameters in advance, for example, through network signaling. Parameters can be received by a WTRU with respect to a specific type of data (e.g., URLLC) or a specific type of logical channel, transport channel, etc. Parameters may be applicable to (e.g., only to) a specific PHY layer resource that is intended to carry data. Parameters may be applicable to data transmitted in a specific set of resource blocks or within a defined frequency / time range.

[0131] A WTRU can receive PHY layer parameters from the network. These parameters can be received periodically or in response to one or more triggers. Triggers may include, for example, (i) significant changes in channel characteristics detected by the network or detected by the WTRU and signaled to the network, (ii) through a request from the WTRU, and / or (iii) upon activation by the WTRU of a service or logical channel, bearer, etc. (which may require the WTRU to have prior access to the PHY layer parameters).

[0132] PHY layer parameters received by a WTRU may remain valid or applicable until one or more of the following occur: (i) the WTRU receives a new / different set of PHY layer parameters; (ii) the timer expires following the receipt of the PHY layer parameters; (iii) the grant to which the PHY layer parameters should apply is received; and / or (iv) the WTRU sends data (e.g., all of it) associated with a particular flow, logical channel, bearer, etc. (e.g., when the WTRU has finished sending all URLLC data in its buffer).

[0133] WTRUs can indicate to the network (for example, further) if one or more of the aforementioned events occur.

[0134] The MCS can be received and used for future grants. In an exemplary implementation, the WTRU can periodically receive an MCS that will be used for transmitting data over a portion of the transmit bandwidth. This can be limited to, for example, a predefined set of transport blocks (e.g., a predefined frequency range). The WTRU can apply the signaled MCS to all transmissions (e.g., all) made over the associated transmit bandwidth (e.g., upon receiving a periodic MCS transmission). The WTRU can identify (e.g., deductively or based on configuration) that one or more L2 protocol data units should be associated with the bandwidth range and (consequently) the initially signaled MCS. For example, the WTRU can identify that a set of logical channels can be supplied with the MCS. The WTRU can map those logical channels to the portion of the bandwidth to which the MCS is signaled.

[0135] Periodic transmissions of MCS can be delivered to the WTRU, for example, via dedicated signaling on the PHY channel, via MAC CE or similar communication, or via RRC signaling. The WTRU can utilize the MCS following the transmission until it receives, for example, a new or updated MCS value for the same bandwidth area. The WTRU can receive multiple different MCS values ​​for use, for example, for separate bandwidth areas. The WTRU can receive MCS for a specific bandwidth area (for example, only that area).

[0136] A WTRU can receive a subset of resources, and a grant can select from that subset (for example, subsequently). For example, a WTRU can receive a resource range within its transmit bandwidth. The resource range can be used to indicate to the WTRU, for example, a set of resources that the WTRU may need to transmit from the moment the grant arrives. A frequency range indicated by a PHY layer parameter can identify a set of resource blocks available during the validity period of the PHY layer parameter, a set of subframes, TTIs, or symbols available during the validity period of the PHY layer parameter, or a combination thereof. A grant can indicate to the WTRU specific resources within the initial resource range. For example, a PHY layer parameter can select x resource blocks for each TTI that may be available to the WTRU. A UL grant can indicate to the WTRU one or more of those x resource blocks for use by the WTRU to satisfy its grant.

[0137] One advantage of this technique is that, assuming the portion of the resource indicated by the grant is already deductively known in PHY layer information previously received by the WTRU, it can reduce the latency associated with grant decoding.

[0138] The WTRU can identify its PHY layer parameters (e.g., coding, modulation, power settings, etc.) before receiving the grant. The parameters can be identified using, for example, one or more of the following: (i) measurements such as SNR, CQI, etc., performed by the WTRU on the DL; (ii) measurements of the ACK / NACK frequency of the transmission performed over the frequency range of interest; and / or (iii) measurements such as reference signal power, SINR, etc., related to a reference signal over the frequency range of interest.

[0139] A WTRU can be configured (for example, dynamically or quasi-statically) by a network with a frequency range that the WTRU can (for example, must) use to define its own set of PHY layer parameters.

[0140] A WTRU can periodically determine its PHY layer parameters, for example, based on measurements over a frequency range or set of frequency ranges. The WTRU can then associate the applicable PHY layer parameters with transmissions made on any resource that it receives a grant from.

[0141] The frequency range for parameter WTRU specification can be dynamically configured by the network. For example, the network can be configured to perform the above-mentioned measurements and calculations of the MCS for frequency ranges A and B (for example, only those), where A and B may be subsets of the total frequencies. The WTRU can apply MCS A to uplink transmissions performed on frequency range A, and MCS B to uplink transmissions performed on frequency range B.

[0142] The configuration of the frequency range in which the WTRU can perform its own determination of PHY layer parameters can be configured by the network, for example, through RRC signaling. The configuration can be modified by updated configurations. For example, the network can utilize the frequency range with the best channel characteristics for URLLC transmission at any given time. The network can dynamically reconfigure the frequency range in which the WTRU can perform its own determination of PHY layer parameters.

[0143] A WTRU can signal PHY layer parameters. For example, a WTRU can signal PHY layer parameters that it autonomously selects to the network. A WTRU can signal parameters at, for example, (i) when selecting / specifying parameters, (ii) during the transmission of data that uses the parameters (in this case, the WTRU can signal the parameters explicitly in the control information and / or implicitly based on the properties of the transmitted data that imply the use of a particular selection of control parameters), (iii) when requested by the network, and / or (iv) when the network provides resources for the transmission of data or control that may or may not be intended for the transmission of these parameters, or in response to them.

[0144] WTRU can use any combination of the procedures discussed herein (for example). For example, WTRU can combine a first procedure capable of providing a set of physical parameters with a second procedure capable of providing a second set of parameters.

[0145] A WTRU can signal the data block size or TB size in an SR, BSR, RA, or similar uplink transmission. A WTRU can signal the data block size or TB size that it can or will use for future transmissions. For example, a WTRU can have a set of data blocks prepared and ready for transmission. A WTRU can (for example, also) combine data blocks to form a transport block. A WTRU can provide the data block size and / or TB size in an SR, BSR, or RA transmitted to the network.

[0146] A WTRU can indicate the course size or TB size for a data block, for example, to enable signaling to be transmitted with less overhead. For example, the set of TB sizes that can be signaled by a WTRU can be limited to x levels. The signaling can be transmitted with a limited number of bits, which can allow the WTRU to signal one of the x levels. For example, if a WTRU wants to transmit TB of size x, it can signal the next TB size that is larger than x.

[0147] The transport block size may be implicitly provided in the CRC check value. A WTRU may select its own modulation and coding (MCS) (for example, without the network providing it). A WTRU may select its transport block size based, for example, the number of fixed-size MAC PDUs available for transmission and the size of the resource grant. The MCS may be identified by the WTRU, for example, using the procedures described herein. A WTRU may signal its MCS to the network (for example, explicitly) based, for example, one or more of the procedures described herein. The transport block size utilized by the WTRU may be indicated (for example, implicitly) as part of the CRC check value of one or more individual MAC PDUs within the transport block. A WTRU may insert padding into fixed-size MAC PDUs (for example, each of them) to obtain a CRC check value that implicitly indicates (for example, to the network) the overall transport block size to be used, or selects from one of the acceptable transport block sizes. In the example, the CRC check value can implicitly signal the selection of a first transport block size by WTRU if, for example, the CRC check value of the first encoded block being transmitted is divisible by one value. The CRC check value can implicitly signal the selection of a second transport block size by WTRU if, for example, the CRC check value of the first encoded block being transmitted is divisible by another value.

[0148] MAC PDU / transport blocks can be created incrementally. TB can be created from a fixed data block size. This can offer advantages over performing RLC segmentation, assembly, MAC layer multiplexing, and PHY layer encoding after grant reception. Grant latency over UL transmission may not improve to the extent of the hardware and software latency of these operations.

[0149] For example, a WTRU can perform incremental creation of transport blocks through the assembly of data blocks with fixed sizes. When higher layer data arrives in the WTRU buffer, a WTRU can create data blocks immediately, or without waiting for information in the grant from the network, by creating fixed-size data blocks as soon as the data arrives. A WTRU can create TBs, for example, by allocating multiple data blocks to a grant in a way that occupies the size of the grant. A WTRU can be given a grant that can be a multiple of the fixed data block size, for example, to minimize padding. A WTRU can (for example, alternatively) fit the same number of data blocks into a transport block that is allowed by the grant size. The WTRU may occupy any remaining data with one or more of the following, for example: (i) padding, (ii) MAC control information, such as information about the required resources, pending MAC PDUs for transmission, MAC PDU size, and the indication of packets with expired TTLs, and / or (iii) further coding, rate matching, etc., which may be inserted by the PHY layer.

[0150] A WTRU can be configured to utilize a specific data block size for certain flows, bearers, logical channels, etc., or for a finite set of such sizes. A WTRU can be restricted to using a specific data block size for (for example, only) one or more specific flows, logical channels, bearers, etc., and may not need to be restricted to data block sizes for data associated with other flows, logical channels, bearers, or data types. For example, a WTRU may be required to utilize a specific data block size for data associated with a URLLC, or for flows with QoS features associated with a URLLC, but can create data blocks that are not restricted in size for other flows or data.

[0151] A data block can be composed of, for example, RLC PDUs or PDUs associated with different protocol layers (MAC, PDCP, etc.).

[0152] The data block size to be configured can be statically configured in the WTRU, for example, or signaled by the network. The WTRU can receive a set of acceptable data block sizes periodically, or intermittently, for example, based on changes in channel conditions identified by the network. The data block size can be signaled to the WTRU, for example, via broadcast or via dedicated signaling, such as part of RRC signaling in a MAC configuration.

[0153] A WTRU can receive one or more acceptable data block size configurations that will apply to a particular (e.g., first) service type, flow, logical channel, etc., and different sets of acceptable data block sizes for another set (e.g., second) service type, flow, logical channel, etc. A WTRU can receive configuration changes to acceptable data block sizes (e.g., in addition to) (e.g., the same) signaling. A WTRU can change the corresponding size of created data blocks (e.g., upon receiving a change in configuration) from, for example, the time of receiving the signaling until the reception of a new set of data block sizes.

[0154] The WTRU can derive a fixed data block size to be used based on PHY layer information that may be provided prior to the grant. For example, the WTRU can calculate an acceptable data block size based on one or more PHY layer parameters, such as the PHY layer parameters described herein. For example, the WTRU can identify a data block size equal to the coding block size provided as part of the PHY layer parameters revealed prior to the grant.

[0155] A WTRU can select one or more data block sizes from a set of acceptable sizes that will be used for each data block created (for example, independently). The selection of data block size can be made for one or more reasons, such as adapting the type of traffic at a higher layer, based on the size of packets received over the most recent time span, the WTRU's buffering capacity, and / or other implementation-related aspects. A WTRU can select a data block size from a list of acceptable sizes that will be used for a particular flow, logical channel, etc. (for example, as an alternative). A WTRU can continue to use the selected data block size for the same flow, logical channel, etc., over a finite period. WTRU can make selections in response to the occurrence of other triggers, such as (i) the arrival of a new type of data, (ii) the next reception of a new set of data block sizes, (iii) the end of a frame / superframe or a similarly defined boundary, (iv) periodically or when a timer expires, (v) when a change in channel quality or other similar measurement is detected (e.g., by the WTRU), and / or (vi) when a new configuration from the network is received (e.g., a change in frequency, HARQ parameters, PHY configuration, etc.).

[0156] A WTRU can, for example, perform segmentation / reassembly of higher-layer SDUs (e.g., IP packets or PDCP SDUs) prior to uplink grants for the transmission of associated data. Segmentation / reassembly of one or more packets that can be associated with a specific flow, data type, logical channel, etc., can be performed by a WTRU on any one or more triggers, such as (i) the arrival of a packet or SDU that can be targeted to a specific flow or associated to a specific logical channel, (ii) when the TTL of a specific packet or SDU falls below a threshold, and / or (iii) when one or more SDUs arrive with a total amount of data available for segmentation / reassembly greater than the minimum size. For example, the minimum size can correspond to an acceptable data block size or a data block size selected by the WTRU.

[0157] A WTRU can, for example, perform segmentation / reassembly of an SDU upon receiving an SDU from a higher layer, and the resulting segments can be of fixed and selected data block sizes. A WTRU can, for example, consume data in a buffer (e.g., all of it) during data block creation, and can insert padding into the data blocks (e.g., during segmentation / reassembly) if it does not occupy an integer number of data blocks with a fixed size.

[0158] A WTRU can, for example, select a data block size (e.g., from a list of acceptable data block sizes) that is closest in size to a higher-layer SDU that may be received in order to minimize the padding being inserted. For example, if a single RLC packet associated with a particular buffer or flow may (e.g., already exist) be present in the WTRU at the time data block creation is performed, the WTRU can select a data block size (e.g., from a list of acceptable sizes) that minimizes padding.

[0159] A WTRU can create a data block header for each data block of a fixed size. A WTRU can also create a header for a set of data blocks that may have a common size and / or one or more other characteristics (such as, but not limited to, logical channels, bearer type, flow type, service type, and / or TTL). A WTRU can complete header processing, for example, when it has determined the number of fixed-size data blocks to be transmitted at a given time. A WTRU can provide one or more headers, along with the data blocks, to a lower layer for encoding.

[0160] A data block may or may not include a header. A single header may be included in an entire transport block containing multiple data blocks. A header may include, for example, one or more of the following: (i) the number of data blocks in the transport block, (ii) the size of one or more of the data blocks in the transport block, (iii) the flow, logical channel, or service associated with each data block, and / or (iv) the amount of control information (e.g., MAC CE) contained within the transport block.

[0161] A WTRU can contain information such as the size of pending TBs that will be transmitted or are ready to be transmitted by the WTRU (for example, within the TB currently being transmitted). For example, this information can be included within a MAC CE that is transmitted as part of the current TB being transmitted.

[0162] A WTRU can contain one or more block sizes (for example, within the current TB) of blocks that are prepared or pending to be sent in future TBs.

[0163] A WTRU can, for example, perform a portion of the PHY layer processing (e.g., encoding) of a data block prior to receiving a grant on that data block of a fixed size. A WTRU can, for example, rely on PHY layer parameters, such as the PHY layer parameters described herein, to perform a portion of the PHY layer processing on that data block of a fixed size prior to receiving a grant. For example, a WTRU can rely on the MCS provided in the PHY layer parameters to perform CRC insertion, encoding, and modulation prior to receiving a grant. A WTRU can, for example, create transport blocks that will be transmitted incrementally by creating data blocks of a fixed size when the data arrives in the RLC buffer, and by encoding and modulating those data blocks when they are received.

[0164] The WTRU can determine, for example, the PHY layer processing to be performed based on the received PHY layer information. For example, based on having received the coding scheme and coding parameters to be used, the WTRU can determine that it is possible to perform encoding prior to receiving the grant, and that modulation can be provided as part of the grant.

[0165] The WTRU can perform one or more of the following actions (for example, upon receipt of a grant): (i) multiplexing and creating transport blocks; (ii) inserting padding bits into a single (e.g., each) fixed-size data block or the overall transport block; (iii) creating or updating one or more data block headers to include information obtained upon the arrival of the grant, such as the number of data blocks in the TB; (iv) creating data block headers; and / or (v) further PHY layer processing of a single (e.g., each) data block or the entire transport block.

[0166] MAC multiplexing and transport block creation can be provided. The WTRU can, for example, identify the number of available data blocks that have been constructed and processed prior to the grant that are ready to be transmitted (e.g., potentially using further PHY layer processing such as coding and modulation) upon receipt of the grant. The WTRU can select a subset of data blocks to be included in the grant for transmission. Selection criteria can be based on, for example, one or more of the following: (i) the selected data blocks may contain data from flows, logical channels, or services indicated in the grant, and the data blocks are acceptable based on the grant (in cases where the grant allows multiple flows), or the data blocks are fixed-size data blocks created based on prior knowledge of data block sizes; (ii) the WTRU can service the grant by including the data blocks on a first-come, first-served basis, whether on a single flow, logical channel, or service, or across one or more (e.g., all) flows, logical channels, or services; and / or (iii) the WTRU can service the grant based on several QoS-related parameters.

[0167] MAC multiplexing can occur, for example, by TTL. For instance, WTRU allows all data blocks to be inserted in ascending order of TTL.

[0168] MAC multiplexing can occur, for example, through logical channel priority and TTL. For example, WTRU can (for example, firstly) include all data blocks (in which case data can be associated with data blocks that have data whose TTL may be below a certain threshold), and (for example, secondly) perform LCP for any further space in the grant.

[0169] MAC multiplexing can occur, for example, through relationships between data blocks. For instance, a WTRU can perform data block selection based on predefined relationships between data blocks, which can be indicated as part of QoS. For example, several data blocks may be formed from the same IP or PDCP packet. A WTRU can include related data blocks within the same transport block, which may result from indications in QoS information that they are preferred or required, for example.

[0170] MAC multiplexing can occur, for example, due to constraints on acceptable QoS in the grant. For example, a WTRU can perform data block selection by selecting data blocks (for example, only those) associated with a single or limited set of flows, logical channels, or services (for example, only those). Associations can be identified in the grant, or can be deductively known in the WTRU based on grant characteristics regarding PHY layer parameters or data block size signaled to the WTRU prior to the grant.

[0171] A WTRU can (for example, autonomously) identify URLLC grants. For example, a WTRU can autonomously identify that a grant can (for example, should be used or must be used) be used to transport data from one or more specific flows, logical channels, or services. A WTRU can restrict that only the data blocks associated with those flows / logical channels / services (for example, only those) are selected and included in the transport block.

[0172] The difference between TB size and grant size can be minimized. For example, WTRU can select available data blocks such that the difference between grant size and TB size is minimized. A combination of available data blocks for transmission can be adopted that results in minimizing the difference.

[0173] The selection criteria can be used by WTRU, for example, whether it creates data blocks of a fixed size or whether the data blocks are dynamically sized (for example, when a grant arrives).

[0174] A data block ACK / NACK may be provided. The WTRU may be configured to transmit a transport block containing one or more data blocks (for example, each with its own CRC, called the data block CRC). The transport block may carry its own CRC, which may be called the TB CRC. The encoder may be configured to insert shorter length CRCs into one (for example, each) code block, for example, to allow power saving through early detection of decoding failures.

[0175] A transport block (TB) NACK can occur, for example, when a pre-configured percentage or number of data blocks are in an error state. A network may receive a transport block (e.g., all associated data blocks) without error (e.g., correctly), in which case it may be configured to send an ACK to the WTRU over a dedicated control channel. A network may detect an error associated with a transport block, for example, due to one or more data blocks being received in an error state. A network may be configured to determine whether to send an ACK or NACK (e.g., a HARQ-ACK) to an associated TB transmission, depending, for example, on the number of data blocks in the transport block that are in an error state. For example, a base station or TRP may be configured to send a NACK if more than a certain number or percentage of data blocks are in an error state (e.g., via another instance in the network or via OAM). For example, a TRP may be configured to send a NACK if more than 50% of data blocks are in an error state. An incentive could be to trigger a HARQ retransmission (e.g., only) when it is (e.g., statistically) expected that there may be a HARQ combinatorial gain. Otherwise, it may be more advantageous to retransmit the data block (e.g., only) that is in an error state, at the cost of further feedback signaling or further delay (e.g., by letting an RLC or ARQ entity handle the error case). A WTRU can be configured (e.g., as a special case) to send a HARQ-NACK when one (e.g., only one) data block is in an error state. This special case could be equivalent to an ACK or NACK on the entire TB.

[0176] One or more exemplary procedures described herein can be performed or applied partially or entirely on a network or WTRU, for example, when the network transmits multiple data blocks to a WTRU. A WTRU can be configured with a certain percentage or number of data blocks that are in an error state and are transmitting HARQ-NACKs.

[0177] High-speed aggregated data block status reports can be provided for ultra-low latency retransmissions. For example, a base station can be configured to provide high-speed status report feedback for data blocks to trigger data block retransmissions, which may be new transmissions from a HARQ perspective. For example, assuming the number of data blocks can vary, the size of the feedback can be variable. The feedback can be aggregated across multiple TTIs.

[0178] An aggregated data block Ack / Nack message can consist of one or more Ack / Nack fields (e.g., 1-bit fields). Each field can correspond to a data block in the associated uplink transmission. The aggregated data block Ack / Nack message can be transmitted by the TRP, for example, via a predefined dedicated resource. The WTRU can determine the size of the aggregated data block Ack / Nack message, for example, based on the associated uplink grant (e.g., using an implicit time association between the UL grant and DL feedback). In one example, the aggregated data block Ack / Nack message can be transmitted by the TRP via a set of resources associated with the resources of the associated UL transmission.

[0179] In the example, the TRP can schedule aggregated data block Ack / Nack messages in line with the UL grant. For example, the TRP can indicate resources for aggregated data block Ack / Nack messages that may occur at a later point in time. In the example, the WTRU can be configured to send aggregated data block Ack / Nack messages only when scheduled by the TRP (for example, only in that case).

[0180] In the example, an approach similar to that described for uplinks may also be applicable to downlinks. A TRP can be configured to transmit multiple data blocks within a transport block. A WTRU can be configured to transmit aggregated data block Ack / Nack messages. A WTRU can be scheduled with resources that may be used or required for aggregated data block Ack / Nack messages on the DCI associated with the associated transmit. A WTRU can receive aggregated data block Ack / Nack message grants and transmit those grants on the associated resources. A WTRU can be configured not to transmit aggregated data block Ack / Nack messages if they are not scheduled on the DCI, for example. The network can (for example, alternatively) configure a set of resources dedicated to transmitting aggregated data block Ack / Nacks.

[0181] In one (for example, another) example, the WTRU can be configured to send an aggregated data block Ack / Nack message via L1 if, for example, no data is being sent, or (for example, if there is data being sent) the WTRU can be configured to include the aggregated data block Ack / Nack along with the data in a control message (for example, included in the MAC header) and send it.

[0182] The size of aggregated data block Ack / Nack messages may vary per TTI, but this size can be known to the network, for example, due to scheduling grants. WTRUs can be configured to send an appropriate format for aggregated data block Ack / Nack messages, for example, following the associated DCI.

[0183] For example, flexible grant sizes can be allowed while satisfying an assembled PDU prior to grant reception. For instance, a WTRU that performs MAC PDU assembly prior to grant allocation can flexibly adopt one or more resulting grants to match the assembled MAC PDU. The WTRU can (for example, autonomously) determine the number of grants or the size of each grant required to transmit the assembled MAC PDU.

[0184] A grant can span multiple consecutive TTIs. For example, a WTRU can be allocated a grant that spans multiple TTIs, multiple subframes, multiple frequency blocks, or a combination thereof. A grant can be defined such that a portion of the grant over a given TTI, subframe, frequency block, etc., can be a unit portion of the overall grant. A WTRU can utilize a subset or multiple units of a grant, and can provide an indication to the network, for example, if it has finished using the grant, allowing the network to determine the overall size of the transport block being transmitted.

[0185] In the example, the WTRU may receive a grant for x resource blocks that may occur repeatedly across y consecutive TTIs. The x resource blocks may be the same in each of the y consecutive TTIs. The x resource blocks may vary from one TTI to the next, for example, to provide diversity in frequency (for example, alternatively). The x resource blocks may vary from one TTI to the next according to one or more of the following: (i) fixed rules known by the WTRU (e.g., [resBlock X+m] mod BW), (ii) rules indicated in the grant itself, (iii) rules defined using broadcasted or dedicated signaling preceding the grant, and / or (iv) rules specific to the cell or TRP to which the WTRU is connected, which may be potentially provided by an access table specific to the system signature or similar system information.

[0186] In the example, the value of y can be undefined, and the grant can continue indefinitely until it is indicated by the WTRU.

[0187] The WTRU can, for example, upon receiving a grant, perform PHY layer encoding and modulation of the MAC PDU ready for assembly according to the modulation and encoding provided in that grant. The WTRU can receive one (e.g., a single) modulation and encoding that will be used throughout the entire grant. The WTRU can receive separate encoding or modulation parameters for use with respect to each TTI associated with the grant (e.g., alternatively).

[0188] A WTRU can, for example, insert padding or additional redundant control information or data into the MAC PDU prior to initiating the encoding process, to ensure, for example, that the resulting encoded and modulated PDU occupies (for example, completely) an integer number of grant units (for example, the resources allowed in M ​​consecutive TTIs).

[0189] A WTRU can indicate the end / size of a transport block (TB) to the network. For example, a WTRU can indicate to the network, for example, at any point during or after grant processing, the number of consecutive TTIs that it can (for example) use and (for example) the end of the transport block, in order to inform the network of the size of the transport block to be sent. A WTRU can indicate the end of a transport block to the network using, for example, one of the following methods: (i) the WTRU can indicate the number of TTIs used to the network using PHY signaling (such as PUCCH, SRS, RACH, or similar signaling, but not limited to these); (ii) the WTRU can indicate the number of TTIs used to the network using MAC CEs provided as part of the transport block; (iii) the WTRU can transmit a special signal indicating the end of transmission, for example, by including it as part of the resources for the last TTI; and / or (iv) the WTRU can perform padding or subdivision of MAC PDUs into blocks at the PHY layer, so that one or more block CRCs have CRC values ​​indicating the number of TTIs used to transmit the transport block.

[0190] A WTRU can decide to combine separate grants to transmit a single TB. For example, a WTRU can select multiple UL grants to use when transmitting a single TB. If a WTRU receives multiple grants in the same subframe or TTI, for example, it can decide to combine those grants and use them to transmit a single TB.

[0191] A WTRU can, for example, select a set of parameters associated with one of those grants to perform modulation and coding over the entire TB (assuming it allows the TB to be transmitted with the entire set of resources), provided that separate grants are provided with potentially separate transmission parameters (MCS, coding, power, etc.). For example, a WTRU can select a grant that results in the least whole data bits being transmitted, allowing it to transmit the TB to the associated grant. A WTRU can include control (e.g., MAC CE, which can include buffer status), padding, and / or further coding, for example, if the resulting encoded TB does not fully occupy the entire combination of resources in the selection made by the WTRU.

[0192] A WTRU may not need to indicate the selected transmit parameters used to perform the transmit. A WTRU can signal the selected transmit parameters using PHY signaling (for example, as an alternative). A WTRU can indicate the selected transmit parameters by transmitting an index that can reference the grants selected for those transmit parameters. The association between the indicated index and the grants can be defined using static rules, for example. For example, a grant that references a resource in the lowest frequency range can be associated with the lowest frequency range. A WTRU can provide properties associated with the grant itself in PHY layer signaling (for example, as an alternative). For example, a WTRU can provide a modulation index for a grant with transmit parameters that can (for example, will be used) be used to transmit the entire grant.

[0193] A WTRU can decide to combine resources, or to combine initial and retransmissions. For example, a WTRU can combine resources allocated to it for the initial and retransmission of a TB, for instance, to send a single TB instead of multiple TBs.

[0194] A WTRU may provide resources for a final retransmission (for example, in the case of a failed transmission), either explicitly or implicitly. A WTRU may indicate this to the network (for example, if the TB occupies more resources than those provided for the initial transmission), for example, by using one or more of the procedures described herein with respect to UL indications.

[0195] A WTRU can encode the entire transport block according to the modulation and coding provided by the grant. A WTRU can transmit a portion of the transport block on the resources for the initial transmission. A WTRU can transmit the remainder of the resources in the TB block (for example, when resources for retransmission become available). This can be repeated multiple times (for example, the number of retransmissions allowed for the initial UL transmission) until the TB is fully transmitted.

[0196] For example, if sending and retransmitting a TB through multiple resources associated with a UL grant fails, the WTRU can perform the retransmission of the TB on a new resource or set of resources scheduled by the network. The WTRU can also retransmit the entire TB on a single grant provided by the network, for example, if the grant size can be adjusted to match the TB size.

[0197] A WTRU can send an indication to allocate more resources to complete a TB transmission. For example, a WTRU can transmit a portion of the TB within a grant provided by the network, indicating to the network that the entire transport was not transmitted. The indication can provide the remaining size of the TB (for example, further). If the network provides a grant, the WTRU can perform the transmission of the remaining TB. The grant can be dedicated to addressing the remaining data associated with the transport block (for example, in particular).

[0198] Transport blocks can be generated early. For example, a WTRU may be enabled to generate one or more transport blocks (or MAC PDUs) prior to receiving signaling, enabling the transmission of one or more transport blocks on a particular resource, where the signaling may include grants received from downlink control information. Pre-generation may be feasible, for example, when used with a variable transmission duration.

[0199] In the example, one or more applicable transmit parameters for physical layer processing of the MAC PDU may be identified, for example, at the time of MAC PDU creation (e.g., prior to the receipt of the grant). For example, the WTRU may identify an applicable coding scheme and / or coding rate for a pre-generated MAC PDU on a given transport channel, based on indications received, for example, from the physical layer, MAC, or RRC signaling, prior to the receipt of the grant. One or more remaining applicable transmit parameters for physical layer processing may be signaled, for example, as part of the grant. For example, the WTRU may identify a modulation scheme (e.g., QPSK or 16-QAM) based on information received from the grant. For example, the grant may indicate a modulation scheme (e.g., explicitly). The grant may indicate a duration and / or frequency allocation for transmission (e.g., alternatively). The WTRU may implicitly derive a modulation scheme that can (e.g., needs to be applied) to adapt (e.g., all) coded bits in the indicated duration and / or frequency allocation.

[0200] The WTRU can determine the size of the MAC PDU according to one or more of the following: (i) a solution from an explicit indication, and / or (ii) a solution from a recently used set of target duration and / or transmission parameters.

[0201] In the example, the size can be identified, for example, from explicit indications from the physical layer, MAC, or RRC signaling, potentially for each type of service or transport channel. For example, a WTRU could be signaled with a MAC PDU size of 3000 bits for the first transport channel and a MAC PDU size of 10000 bits for the second transport channel.

[0202] In the example, the WTRU can determine the size of the MAC PDU based on one or more of the required durations of the transmission carrying the MAC PDU with respect to a assumed set of transmission parameters, such as (i) the target duration for the transmission, (ii) the frequency allocation, modulation scheme, coding scheme, and / or the multiple spatial layers to which the MAC PDU is mapped.

[0203] One or more of the assumed sets of transmit parameters can be identified based on, for example, one or more of the following: (i) the most recent or latest transmit or latest initial HARQ transmit (e.g., modulation and coding) that occurred with respect to the MAC PDU of the corresponding transport channel; (ii) currently applicable transmit parameters for the physical layer processing of the MAC PDU (e.g., coding scheme and / or rate); and / or (iii) explicit indications from the physical layer, MAC, or RRC signaling (e.g., the number of frequency allocations or subcarriers or resource blocks that the WTRU may assume may be signaled).

[0204] The target duration for transmission can be identified, for example, from explicit indications from the physical layer, MAC, or RRC signaling. The target duration can be provided for each type of transport channel. The WTRU can, for example, size the MAC PDU such that the transmission duration for the MAC PDU can match or nearly match (for example, would match) the target duration with a assumed set of transmission parameters. This approach makes it possible to ensure that the (e.g., required or maximum) duration for MAC PDU transmission remains relatively close to the target, despite the fact that other transmission parameters that may be applicable to the transmission of the MAC PDU may differ from the assumed set of transmission parameters, for example, due to changes in radio conditions.

[0205] Conditions for pre-generating additional MAC PDUs may be provided or otherwise known. For example, a WTRU may pre-generate one or more new MAC PDUs (e.g., only one) if one or more conditions are met, such as (i) the number of unprocessed pre-generated MAC PDUs cannot exceed a first threshold (in which case the threshold can be, for example, predefined or obtained from the physical layer, MAC, or RRC signaling), or (ii) the amount of data in the unprocessed pre-generated MAC PDUs (which may include one or more new MAC PDUs that will be pre-generated) does not exceed a second threshold.

[0206] In the example, the second threshold can be predefined or obtained from the physical layer, MAC, or RRC signaling. The threshold can be based on (for example, alternatively,) the amount of data that can be transmitted within a target duration with respect to a assumed set of transmit parameters. The assumed set of transmit parameters can be obtained, for example, according to one or more techniques described herein. In the example, the WTRU can pre-generate new MAC PDUs if, for example, the total duration required for the transmission of (for example, all) unprocessed pre-generated MAC PDUs cannot exceed a threshold such as 5 ms. The target duration can be, for example, predefined or obtained from the physical layer, MAC, or RRC signaling.

[0207] Pre-generated MAC PDUs can be transmitted. For example, a WTRU can receive signaling (e.g., a grant) that enables the transmission of one or more MAC PDUs on a resource. Transmission is conditional, for example, based on clear channel assessment conditions, such as when the WTRU is operating in unlicensed bandwidth. One or more MAC PDUs can be pre-generated, for example, according to one or more techniques described herein.

[0208] A WTRU can receive one or more transmit parameters, such as frequency allocation, modulation scheme, coding scheme and / or rate, or one or more of several spatial layers. One or more parameters can be provided prior to signaling that enables the MAC PDU's transmission. The WTRU can specify the required transmission duration, for example, so that a sufficient number of resource elements are available to map the modulation symbols. This specification can take into account one or more parameters and / or any (e.g., required) reference signals and / or physical control information that will be multiplexed with higher layer data. The WTRU can then perform the transmission accordingly.

[0209] In one example, the WTRU can transmit control information to assist the receiver in determining the transmission duration. For example, the WTRU can provide a representation of the duration, represented as multiple time units (e.g., symbols or subframes) encoded in uplink or sidelink control information, such as in scheduling allocations. In one (for example, another) example, the WTRU can transmit an indication in the transmission symbols (e.g., in the last symbol or after the last symbol) that the transmission will not continue. In another (for example, another) example, the WTRU can multiplex control information indicating whether the transmission will continue in subsequent time units in predefined resources occurring in (e.g., each) time unit (e.g., each subframe).

[0210] A WTRU can receive the maximum transmit duration, for example, as part of a grant or from previous signaling. If the transmit duration for a MAC PDU could (for example) exceed the maximum value, the WTRU can perform one or more of the following actions: (i) discard the MAC PDU; (ii) transmit an indication that the maximum transmit duration is too short for the transmission of the MAC PDU (in this case, the indication can be encoded, for example, as physical control information in a MAC PDU created for this purpose, or as MAC signaling); and / or (iii) modify at least one transmit parameter, such as a coding scheme, coding rate, or modulation scheme, compared to the signaled transmit parameter, for example, so that the total required duration cannot exceed the maximum value. In the example, the WTRU can employ a higher-order modulation (e.g., 16-QAM instead of QPSK), a higher (e.g., more effective) coding rate (e.g., 3 / 4 instead of 1 / 3) (this can be done, for example, by puncturing multiple coded bits). The WTRU can transmit an indication of whether a modification has been applied, and / or an indication of the modified value, for example, within uplink or sidelink control information.

[0211] A minimum guaranteed TBS can be provided. For example, a WTRU can be configured with a minimum guaranteed TBS. The configuration can be received, for example, by the RRC or by the MAC CE. The configuration may be applicable to one (e.g., a specific) data unit based on the data type, a logical association (e.g., with data flow, LCH, LCG, corresponding SOM, corresponding service, a group thereof, etc.). A WTRU can be configured, for example, to allow it to perform one or more processing steps for the creation of a MAC PDU, for example, before receiving downlink control information and / or before final determination of the TBS regarding uplink transmissions.

[0212] MAC processing can occur before TBS information. For example, a WTRU can perform multiple MAC processing steps before the final identification of transmission parameters (e.g., all of them), such as TBS for transmission and / or applicable data units (e.g., MAC SDU). A MAC PDU can include segments of data units (e.g., by RLC segmentation or MAC segmentation).

[0213] A MAC PDU can be assembled with a single TBS value, padding, and / or concatenation. For example, a WTRU can assemble a MAC PDU using the configured minimum guaranteed TBS (TBSmin). A single value can be configured. A WTRU can consider a single value valid from among several values, based on (for example, alternatively,) the reception of control signaling (DCI, MAC CE) which can indicate a valid value, based on previously reported QoS parameters such as minimum PDU size, based on reported channel quality information, etc. A WTRU can (for example, subsequently) determine the final value of TBS for transmission (TBSfinal) from the reception of DCI which allows uplink resources, for example.

[0214] The WTRU can assemble the MAC PDU for each of the configured minimum guaranteed TBS (TBSmin) values ​​(for example, if there are multiple values). The WTRU can then determine the final TBS value for transmission (TBSfinal) (for example, from the DCI reception that allows uplink resources).

[0215] TBS can be adapted over time. For example, a WTRU can determine the final set of parameters for a transmission (TBSfinal) that uses a minimum TBS guarantee associated with a single transport block, for example, from the reception of downlink control signaling. The received DCI can explicitly indicate the specific data units that will be supplied with the transmission. The received DCI can indicate the processing time applicable to the transmission, for example, thereby instructing the WTRU to perform the transmission at time n+x μsec / ms / subframe or some other unit in time with respect to the DCI received at time n. In the example, the WTRU can determine the shortest duration of a TB transmission, for example, based on the signaled MCS, PRB set, etc., using the smallest configured TBS value greater than the TBS resulting from the information contained in the DCI signaling. In the example, the WTRU can identify the shortest duration that matches the framing boundary in time (e.g., matching the end of the DL transmission portion of a subframe), which can fit the smallest configured TBS value greater than the TBS resulting from the information contained in the DCI signaling. For example, this can be conceptually similar to a bundling operation in time based on an implicit indication (e.g., a signaled TBS smaller than the minimum TBS) or an explicit indication (e.g., indicated in the DCI). In the example, the WTRU can perform multi-TTI TB transmissions (e.g., for a single MAC PDU related to an applicable data unit) or TTI bundling (e.g., for multiple segments such as RLC or MAC as separate MAC PDUs related to an applicable data unit) with respect to the transmission of pre-assembled MAC PDUs. The number of TTIs can be an integer determined based on the guaranteed / configured TBS value (e.g., TBSmin) and the TBS value resulting from the information in the DCI.

[0216] WTRU can add padding to a pre-assembled MAC PDU so that the PDU size matches the value TBSfinal (for example, if the size of TBSfinal is greater than TBSmin). The padding can include one or more MAC CEs, such as BSRs or padding BSRs. WTRU can also concatenate additional data (for example, with or without padding information) to a pre-assembled MAC PDU so that the PDU size matches the value TBSfinal.

[0217] The WTRU can select a pre-assembled PDU that can be associated with a different (e.g., specific) data unit, if such a PDU exists, for example, if the size of the TBSfinal (with or without multi-TTI transmission) is smaller than that of a pre-assembled PDU with an applicable value for TBSmin. The WTRU can assemble a new MAC PDU that matches the TBS of the transmission (for example, as an alternative), or the WTRU can perform a padding-only transmission.

[0218] A WTRU can include a desired TBS indication, and / or an increment / decrement indication thereof, for example, separate values ​​within a configured set of values, within the uplink transmission. The indication may be applicable to a specific type of data unit and / or configuration. The indication can be contained within the BSR or provided using bits in the MAC PDU header representing an index to a pre-configured set of values. The indication can be a request for an increase in processing time.

[0219] The WTRU may use information on the minimum guaranteed TBS to identify the source LCH (or equivalent) from which data can be supplied for the assembly of the MAC PDU. For example, one or more other aspects, such as latency, lifespan, PBR, priority, etc., may be taken into consideration by following one or more procedures described herein.

[0220] For example, if the WTRU is configured to supply data from a specific LCH (or equivalent) based on the minimum configured data unit size, and the grant is decoded and (e.g.) all information is known, then one of the above procedures may be applicable when the WTRU performs assembly of MAC PDUs.

[0221] A network (NW) can configure one or more minimum TBSs (for example, using the procedures described herein). A WTRU can determine whether it is possible for the received transmit to include padding, for example, to determine whether the WTRU performs pre-assembly and / or concatenation of MAC PDUs. A network can modify the TTI duration of a transmit to ensure that the minimum TBS size is available (for example, always), even if, for example, the radio link and / or HARQ operating point changes. In other words, a network can perform WTRU transmit adaptations for data units and / or MAC SDUs in time, in addition to adaptations based on MCS and / or frequency. For example, this adaptation may be useful when a network can (for example, needs to) guarantee a minimum TBS with a particular HARQ operating point for various link adaptation needs and / or various link qualities. In the example, DCI may indicate a longer processing time for the WTRU following, for example, the reception of an empty MAC PDU (for example, containing only padding) and / or the reception of an indication that the current TBS is insufficient.

[0222] The transmission parameters can be selected, for example, using blind decoding or DCI receiving procedures.

[0223] In the example, the WTRU may identify one or more parameters associated with the transmission, for example, based on the decoding of the control channel. The WTRU may perform identification based, for example, on the parameters used for a decoding attempt that was deemed successful in the result. The WTRU may identify success based, for example, on successful CRC verification of the received DCI. The DCI may indicate an uplink and / or downlink transmission.

[0224] One or more parameters can correspond to a set of parameters. A WTRU can use a procedure to identify one or more of several sets of parameters. A set can be a configuration of the WTRU. For example, one or more parameters (e.g., of a set) can correspond to a transmission characterized by higher reliability, lower latency, and best-effort type transmission, or to another type of service, such as paging, receiving system information, or broadcast transmission. A set can correspond to a System of Mail (SOM).

[0225] Decoding control channels can accommodate blind decoding attempts. WTRU can perform one or more decoding attempts, each attempt, for example, using a separate set of decoding modes (e.g., parameters and / or procedures). A decoding mode can include a set and / or amount of physical resources used with respect to the channel (e.g., control channel elements), the aggregation level (AL), the size of the CRC (e.g., distinguished using 8-bit, 16-bit, and / or separate polynomials), the associated search space, the identity of the corresponding control channel, or a combination thereof.

[0226] The robustness of the DCI can indicate something about the transmission. For example, the WTRU can determine that the received DCI has been successfully decoded according to one of several robustness / reliability levels. The WTRU can identify appropriate values ​​for one or more parameters associated with the transmission, for example, thereby allowing a similar reliability level to be assumed for the transmission. For example, the network can identify explicit / implicit indications for use based on applicable link-fitting mechanisms, such as uplink control information and / or channel status indicators received from the WTRU.

[0227] A WTRU can, for example, identify the minimum level of robustness and / or QoS level applicable to a transmission based on a specified set of one or more parameters. For example, a WTRU can identify the applicable SOM. A WTRU can also identify data applicable to a UL transmission based on the associated QoS level.

[0228] A WTRU can identify HARQ processing and / or feedback. For example, a WTRU can identify the type of HARQ processing to apply to a transmission (e.g., in the case of the initial transmit, uplink, or downlink), and / or the type of HARQ feedback (e.g., required) for the transmit, based on, for example, an identified set of parameters. For example, a WTRU can identify, based on, an identified set of parameters (e.g., with respect to the reception of a DL transmit), that HARQ feedback can be expected at (or within) a specific time interval using a specific transmit procedure (e.g., an applicable uplink control channel), or that the feedback should not be generated automatically (e.g., should only be generated on request). For example, a WTRU can identify an applicable SOM and perform HARQ processing and / or feedback accordingly.

[0229] Robustness can be included and signaled within a grant. For example, a WTRU can receive signaling in the DCI (e.g., implicitly or explicitly) to indicate that a send associated with a particular grant can be performed based on a separate set of parameters associated with the flow, service type, SOM, etc. For example, a WTRU can receive an indication (e.g., in the grant) that the corresponding send can be used for sending URLLC data (if any), and that the send parameters can be modified and / or selected accordingly to enable, for example, a more robust send and / or lower latency.

[0230] For example, a WTRU can perform a similar identification of downlink transmissions with respect to the Scheduled DCI, thereby enabling it to properly identify the parameters for decoding the associated transmission.

[0231] WTRU can determine the robustness level of a received grant, for example, based on decoding the DCI. WTRU can determine such robustness levels according to, for example, (i) the characteristics of a successful decoding attempt, such as the AL associated with a successfully decoded DCI, the size of the CRC associated with a successfully decoded DCI, the CRC polynomial associated with a successfully decoded DCI, the CCE (or first CCE) associated with a successfully decoded DCI, the search space (or its beginning) associated with a successfully decoded DCI, and / or one or more of the associated control channel type, time / frequency resources, and / or identity; (ii) the received DCI format; and / or (iii) one or more of the explicit representations within the fields in the DCI format.

[0232] WTRU can be configured for association with robustness levels and / or sets of parameters.

[0233] Robustness levels can be determined from aggregation levels or CRCs. For example, WTRU can determine its robustness level based on the aggregation level or search space that resulted in successful decoding of DCI. For instance, robustness levels can be determined as a first value if the aggregation level is determined to be 1, 2, or 4 (e.g., aggressive AL with respect to a particular reliable operating point), and as a second value if the aggregation level is determined to be 8 or 16 (e.g., conservative AL with respect to a higher reliable operating point).

[0234] In the example, the WTRU can determine the robustness level based on the size of the CRC that was successfully decoded from the DCI. For example, an 8-bit CRC may indicate the use of a normal robustness level (e.g., a first set of transmit parameters), while a 16-bit or 32-bit CRC may indicate the use of an even higher robustness level (e.g., a second set of transmit parameters).

[0235] Transmit parameters can be selected based on robustness levels. For example, a WTRU can select the transmit parameters used for UL transmissions associated with a grant, depending on the signaled robustness level. The selection can be based on predefined rules, for example, or can be configured by the network (for example, in RRC signaling). The selection can be combined with other procedures, such as one or more of those described herein. In the example, the selection can be based on one or more of the following, for example: (i) the physical resources available for uplink transmissions (for example, when the identification of a set of applicable resources for transmissions can itself be independent of such identification); (ii) the type of data being transmitted (for example, when the selection of data can itself be independent of such identification); (iii) the current state of the WTRU (for example, the current power headroom); and / or (iv) the current state of the data (for example, the TTL of the data).

[0236] In the example, the WTRU can identify separate values ​​for each parameter, for example, based on whether the robustness level indicates a normal transmission or a reliable transmission. The WTRU can identify separate values ​​for one or more parameters, such as (i) MCS, (ii) the set of applicable PRBs, (iii) applicable PRBs within the identified set of applicable PRBs, (iv) HARQ process type, (v) applicable procedures for generating and / or transmitting (e.g., if DCI is scheduling a DL transmission) or receiving (e.g., if DCI is scheduling a UL transmission) HARQ feedback, (vi) power boosting and / or power prioritization (e.g., if DCI is scheduling a UL transmission), and / or (vii) applicable framing and / or frame structure (e.g., TTI duration). The WTRU can perform data reception / transmission according to the identified set of parameters.

[0237] Systems, methods, and means (e.g., embodiments of entities, interfaces, and procedures at network layers L1, L2, and L3) relating to low-latency MAC PDU assembly in wireless systems such as 5gFLEX have been disclosed. For example, latency can be reduced by identifying and signaling network transmit parameters by a WTRU prior to the transmit grant. The WTRU can receive MCS, resource ranges, etc., prior to the grant, for example, for use in future grants. Data blocks can be created / encoded incrementally prior to the grant. Data units can be segmented, assembled, and multiplexed based on a data block size that enables MAC and RLC processing prior to the grant, for example. Flexible grant sizes can be provided for early generation of transport blocks prior to the grant. A minimum guaranteed TBS can be signaled to enable early generation of MAC PDUs. For example, transmit parameters can be selected prior to the grant using blind decoding or DCI receiving procedures.

[0238] The processes and means described herein are applicable in any combination and are applicable to other wireless technologies and other services.

[0239] A WTRU can refer to the identity of a physical device, or to a subscription-related identity, such as a user identity including MSISDN, SIP URI, etc. A WTRU can also refer to an application-based identity, such as a username that can be used on a per-application basis.

[0240] Each of the computing systems described herein may have one or more computer processors having memory configured with executable instructions, or hardware for achieving the functions described herein, including identifying the parameters described herein and sending and receiving messages between entities (e.g., a WTRU and a network) to achieve the functions described herein. The processes described above can be carried out in computer programs, software, and / or firmware incorporated on computer-readable media for execution by a computer and / or processor.

[0241] The processes described above can be carried out in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections), and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, as well as magneto-optical media, and / or optical media such as CD-ROM discs and / or digital multi-purpose discs (DVDs). A processor associated with software can be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A method implemented by a wireless transceiver unit (WTRU), The WTRU receives an indication of a set of multiple sets of transmission parameters for uplink transmission, wherein the WTRU receives an indication that a first set of transmission parameters among the multiple sets of transmission parameters is applicable to the transmission of data on at least a first logical channel, and the WTRU receives an indication that a second set of transmission parameters among the multiple sets of transmission parameters is applicable to the transmission of data on at least a second logical channel, wherein the first set of transmission parameters includes a modulation and coding scheme (MCS) and a set of one or more resource blocks used for transmission. It is determined that in the first transmission, data will be transmitted from at least the first logical channel using the first set of transmission parameters, Sending the first transmission, which includes the data from at least the first logical channel, using the MCS and the set of one or more resource blocks, Methods that include...

2. The method according to claim 1, wherein the second set of transmission parameters includes a second MCS and a second set of one or more resource blocks used for transmission.

3. The determination to transmit data from at least the second logical channel in the second transmission using the second set of transmission parameters, Sending the second transmission, which includes the data from at least the second logical channel, using the second MCS and the second set of one or more resource blocks, The method according to claim 2, further comprising:

4. The method according to claim 1, wherein the first set of transmission parameters includes a first subcarrier space, and the second set of transmission parameters includes a second subcarrier space.

5. The method according to claim 1, wherein the first set of transmission parameters includes a hybrid automatic retransmission request (HARQ) processing type, and the second set of transmission parameters includes a second HARQ processing type.

6. The method according to claim 1, wherein the first set of transmission parameters includes a first transmission duration, and the second set of transmission parameters includes a second transmission duration.

7. The method according to claim 1, wherein the indication of a plurality of sets of transmission parameters is received in a radio resource control (RRC) message.

8. The method according to claim 7, wherein the indication of the plurality of sets of transmission parameters received in the RRC message includes one or more explicit indications.

9. The method according to claim 1, wherein the first set of transmission parameters includes first power information, and the second set of transmission parameters includes second power information.

10. A wireless transceiver unit (WTRU), The WTRU receives an indication of a plurality of sets of transmission parameters for uplink transmission, and the WTRU receives an indication that a first set of transmission parameters among the plurality of sets of transmission parameters is applicable to the transmission of data on at least a first logical channel, and the WTRU receives an indication that a second set of transmission parameters among the plurality of sets of transmission parameters is applicable to the transmission of data on at least a second logical channel, and the first set of transmission parameters includes a modulation and coding scheme (MCS) and a set of one or more resource blocks used for transmission. It is decided to transmit data from at least the first logical channel in the first transmission using the first set of transmission parameters. Using the MCS and the set of one or more resource blocks, send the first transmission including the data from at least the first logical channel. A WTRU equipped with a processor configured as such.

11. The WTRU according to claim 10, wherein the second set of transmission parameters includes a second MCS and a second set of one or more resource blocks used for transmission.

12. The aforementioned processor, It is decided to transmit data from at least the second logical channel in the second transmission using the second set of transmission parameters. Send the second transmission, which includes the data from at least the second logical channel, using the second MCS and the second set of one or more resource blocks. The WTRU according to claim 11, configured as described above.

13. The WTRU according to claim 10, wherein the first set of transmission parameters includes a first subcarrier space, and the second set of transmission parameters includes a second subcarrier space.

14. The WTRU according to claim 10, wherein the first set of transmission parameters includes a hybrid automatic retransmission request (HARQ) processing type, and the second set of transmission parameters includes a second HARQ processing type.

15. The WTRU according to claim 10, wherein the first set of transmission parameters includes a first transmission duration, and the second set of transmission parameters includes a second transmission duration.

16. The WTRU according to claim 10, wherein the processor is configured to receive the indication of a plurality of sets of transmission parameters in a radio resource control (RRC) message.

17. The WTRU according to claim 10, wherein the indication of the plurality of sets of transmission parameters includes one or more explicit indications.

18. The WTRU according to claim 10, wherein the first set of transmission parameters includes first power information, and the second set of transmission parameters includes second power information.

Images