Media access protocol data unit assembly in a wireless system

Abstract

To provide a system for low latency MACPDU assembly in wireless systems, such as 5G flexible radio access technology.SOLUTION: The determination and signaling of network transmission parameters by the WTRU prior to the transmission grant may reduce latency. The WTRU may receive the modulation and coding scheme, resource range, etc. prior to the grant, for example, for use in a future grant. The data block may be incrementally created / encoded prior to the grant. A flexible grant size may be provided for early generation of the transport block before the grant. In order to enable early generation of MAC PDUs, a minimum guaranteed transport block size may be signaled.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] Media Access Protocol Data Unit Assembly in Wireless Systems. [Background technology]

[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 May 11, 2016, which is incorporated herein by reference.

[0003] Mobile communications continues to evolve. The fifth generation may be referred to as 5G. Previous (legacy) generations of mobile communications may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0004] Systems, methods, and means (e.g., aspects of entities, interfaces, and procedures in a wireless transmit / receive unit (WTRU) and / or network layers L1, L2, and L3) for low latency medium access control (MAC) protocol data unit (PDU) assembly in wireless systems such as 5G Flexible Radio Access Technology (RAT) (5gFLEX) are disclosed. For example, latency can be reduced by specifying and signaling network transmission parameters by the WTRU prior to a transmission grant. The WTRU can receive modulation and coding scheme (MCS), resource ranges, etc., prior to a grant, e.g., for use in future grants. Data blocks can be incrementally created / encoded prior to a grant. Data units can be segmented, assembled, and multiplexed, e.g., based on a data block size that enables MAC and radio link control (RLC) processing prior to a grant. Flexible grant sizes can be provided for early generation of transport blocks prior to a grant. To enable early generation of MAC PDUs, a minimum guaranteed transport block size (TBS) can be signaled. For example, blind decoding or DCI reception procedures can be used to select transmission parameters prior to the grant.

[0005] A wireless transmit / receive unit (WTRU) may include a processor configured (e.g., with executable instructions stored in a memory) to perform one or more of: (i) looking for and monitoring downlink control information (DCI) across at least resources of a downlink control channel; (ii) identifying 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 the downlink transmission or the uplink transmission; (iv) determining at least one decoding parameter used to decode the first DCI; and (v) determining one or more transmit or receive parameters for the at least one data transmission based on the at least one decoding parameter used to decode the first DCI.

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

[0007] The WTRU processor may be configured to transmit HARQ-ACK feedback over a resource associated with the identified decoding parameters of the decoded downlink control channel indication.

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

[0009] The at least one decoding parameter may include a robustness level associated with the first DCI, where a higher robustness level for the first DCI may indicate a higher robustness level for the data transmission, and a lower robustness level for the first DCI may indicate a lower robustness level for the data transmission.

[0010] The one or more transmission or reception parameters for the at least one data transmission may include one or more of a quality of service (QoS) level associated with the at least one data transmission or a spectrum operating mode (SOM) associated with the at least one data transmission. The one or more transmission or reception parameters for the at least one data transmission may include hybrid automatic repeat request (HARQ) feedback parameters associated with the at least one data transmission. The HARQ feedback parameters may include timing information for transmission or reception of HARQ feedback.

[0011] The WTRU processor may be configured to receive a configuration from a network entity, where the configuration may indicate a mapping between one or more decoding parameters and one or more transmit or receive parameters for at least one data transmission. The at least one decoding parameter may include a DCI format.

[0012] The one or more transmission or reception parameters for the data transmission may include one or more of a modulation and coding scheme (MCS), a set of physical resource blocks associated with the at least one data transmission, power information associated with the at least one data transmission, transmission timing information for the at least one data transmission, or a transmission timer interval (TTI) duration associated with the at least one data transmission.

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

[0014] The method of using the WTRU may include (i) transmitting HARQ-ACK feedback over resources associated with the identified decoding parameters of the decoded downlink control channel indication, and / or (ii) receiving a configuration from a network entity, the configuration indicating a mapping between one or more decoding parameters and one or more transmission or reception parameters for at least one data transmission. [Brief explanation of the drawings]

[0015] [Figure 1A] 1 is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram of an example WTRU that may be used within the communication system shown in FIG. 1A. [Figure 1C] 1B is a system diagram of an example radio access network and an example core network that may be used within the communication system shown in FIG. 1A. [Figure 1D] 1B is a system diagram of another example radio access network and another example core network that may be used within the communication system shown in FIG. 1A. [Figure 1E] 1B is a system diagram of another example radio access network and another example core network that may be used within the communication system shown in FIG. 1A. [Figure 2] FIG. 1 illustrates an example of a transmission bandwidth. [Figure 3] FIG. 1 illustrates an example of flexible spectrum allocation. [Figure 4] FIG. 1 illustrates an example of timing relationships for TDD duplexing. [Figure 5] FIG. 10 is a diagram illustrating an example of timing relationships related to FDD duplexing. DETAILED DESCRIPTION OF THE INVENTION

[0016] A detailed description of exemplary embodiments will now be provided, with reference to various figures. It should be noted that while this description provides detailed examples of possible implementations, these details are intended to be illustrative and in no way limit the scope of the present application.

[0017] 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, e.g., voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, e.g., 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] 1A, communications 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 WTRUs 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronics devices, etc.

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

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

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

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

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

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

[0025] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as an office, home, vehicle, campus, etc. In some embodiments, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0026] The RANs 103 / 104 / 105 may be in communication with the core networks 106 / 107 / 109, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core networks 106 / 107 / 109 may 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 FIG. 1A , it will be understood that the RANs 103 / 104 / 105 and / or the core networks 106 / 107 / 109 may be in direct or indirect communication with other RANs employing the same RAT as the RANs 103 / 104 / 105 or a different RAT. For example, the core networks 106 / 107 / 109, in addition to being connected to the RANs 103 / 104 / 105 which may utilize E-UTRA radio technology, may also be in communication with another RAN (not shown) which employs GSM radio technology.

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

[0028] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with separate wireless networks over separate wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ cellular-based wireless technology and with a base station 114b that may employ IEEE 802.11 wireless technology.

[0029] 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment. Embodiments also contemplate that the base stations 114a and 114b, and / or the nodes to which the base stations 114a and 114b may correspond (e.g., but not limited to, a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB or HeNodeB), a home evolved node-B gateway, and a proxy node, among others), may include some or all of the elements shown in FIG. 1B and described herein.

[0030] The processor 118 may be a general-purpose processor, a special-purpose 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 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0032] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some embodiments, the WTRU 102 may include multiple transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

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

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

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

[0036] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. The WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 in addition to or in lieu of information from the GPS chipset 136 and / or determine its location based on the timing of signals received from multiple neighboring base stations. It will be appreciated that the WTRU 102 may obtain location information through any suitable location determination implementation while remaining consistent with an embodiment.

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

[0038] 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. Each of the Node-Bs 140a, 140b, and 140c may be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and 142b. It will be understood that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0039] As shown in FIG. 1C , Node-Bs 140a and 140b may be in communication with RNC 142a. Additionally, Node-B 140c may be in communication with RNC 142b. Node-Bs 140a, 140b, and 140c may communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b may be in communication with each other via an Iur interface. Each of RNCs 142a and 142b may be configured to control its respective Node-B 140a, 140b, and 140c. Additionally, each of RNCs 142a and 142b may be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

[0040] 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. Although each of the above elements 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] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to an MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communication devices.

[0042] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

[0044] 1D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

[0046] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and / or downlink (DL), etc. As shown in FIG. 1D, the eNode-Bs 160a, 160b, 160c may communicate with one another via an 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. Although each of the above elements 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 MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during initial connection of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as GSM or WCDMA.

[0049] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as fixing the user plane during handover between eNode Bs, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

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

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

[0053] 1E, the RAN 105 may include base stations 180a, 180b, and 180c and an ASN gateway 182, although it will be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and 180c may each be associated with a particular cell (not shown) within the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 117. In some embodiments, the base stations 180a, 180b, and 180c may implement MIMO technology. Thus, the base station 180a may use multiple antennas, for example, to transmit wireless signals to and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, etc. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching subscriber profiles, routing to the core network 109, etc.

[0054] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. Additionally, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0055] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point that includes protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0056] 1E, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, including protocols for facilitating data forwarding and mobility management functions, for example. 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 above elements 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 may be responsible for IP address management and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. In addition, the gateway 188 may provide access to the network 112 for the WTRUs 102a, 102b, 102c, which may include other wired or wireless networks owned and / or operated by other service providers.

[0058] 1E, the RAN 105 may be connected to other ASNs, and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0059] For example, the air interface for new radio (NR) access technology in a 5G system can support various use cases, such as improved broadband performance (IBB), industrial control and communications (ICC), and vehicular applications (V2X) and massive machine-type communications (mMTC). A use case can have associated support in the air interface (e.g., the 5G air interface).

[0060] The air interface may support, for example, Ultra Low Latency (LLC), Ultra Reliable Transmission (URC) and MTC operation (including narrowband operation).

[0061] Support for ultra-low transmission latency (LLC) can include, for example, an air interface latency such as an RTT of 1 ms and a TTI between 100 us and 250 us. Support for ultra-low access latency (e.g., the time from initial system access to the 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 ranging from 0 to 500 km / h can be provided. For example, for IC and V2X, 10e -6 A packet loss rate of less than 1000 s can be supported.

[0063] Support for MTC operation may include, for example, narrowband operation (e.g., using less than 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 in the range of 1-100 kbps with access latencies of a few seconds to a few hours).

[0064] The 5gFLEX system may be implemented using OFDM and / or other waveforms for the uplink and / or downlink. The examples described herein are non-limiting. The 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. The (e.g., each) subcarrier can be shaped using a rectangular window in the time domain, which can lead to sinc-shaped subcarriers in the frequency domain. OFDMA 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 preserve orthogonality between signals and minimize inter-carrier interference. Tight synchronization may be difficult, for example, in systems where a WTRU may be simultaneously connected to multiple access points. For example, to comply with spectral emission requirements for adjacent bands, further power reduction may be applied to uplink transmissions. Fragmented spectrum may be aggregated for WTRU transmissions.

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

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

[0068] A multi-carrier modulation waveform can divide a channel into sub-channels and modulate data symbols onto sub-carriers within those sub-channels.

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

[0070] In an example of universal filtered multicarrier (UFMC), such as UF-OFDM, a filter can be applied to the OFDM signal in the time domain to reduce OOB. Filtering can be applied subband-by-subband to use spectral fragmentation, which can reduce complexity and make UF-OFDM more practical to implement. OOB emissions in unused spectral fragmentation within a band can be as high as in OFDM. UF-OFDM may offer some improvement over OFDM at the edges of the filtered spectrum, while offering little to no improvement in spectral holes.

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

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

[0073] Other coexistence aspects can include support for waveforms and / or transmissions that can support hybrid-type waveforms, e.g., by way of example, perhaps varying CP duration (e.g., from one transmission to another), a combination of CP and low-power tail (e.g., zero tail), and / or a form of hybrid guard interval (e.g., using a low-power CP and an adapted low-power tail), etc. The waveforms can support dynamic variation and / or control of other aspects, such as how filtering is applied (e.g., whether filtering is applied at the edge of the spectrum used for reception of any transmissions for a given carrier frequency, at the edge of the spectrum used for reception of transmissions associated with a particular SOM, on a per-subband or per-group basis).

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

[0075] Transmissions between different WTRUs in the same cell may be multiplexed based on, for example, FDMA and TDMA.

[0076] 5gFLEX radio access can be characterized by a very high degree of spectrum flexibility, allowing deployment in different frequency bands with different features that can include different duplex arrangements, different and / or variable sizes of available spectrum, such as contiguous and non-contiguous spectrum allocations in the same or separate bands. 5gFLEX radio access can support variable timing aspects, such as support for multiple TTI lengths and asynchronous transmission.

[0077] Multiple duplexing schemes (e.g., TDD, FDD) may be supported. For example, for FDD operation, complementary downlink operations may be supported, e.g., using spectrum aggregation. FDD operation may support full-duplex and half-duplex FDD operation. DL / UL allocation may be dynamic (e.g., not based on a fixed DL / UL frame configuration), e.g., for TDD operation. The length of the DL or UL transmission interval may be set for each transmission opportunity.

[0078] The features or capabilities of the 5G air interface may allow for separate transmission bandwidths on the uplink and downlink ranging, e.g., varying, between a nominal system bandwidth and a maximum value corresponding to the system bandwidth.

[0079] 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 transmissions (e.g., 0 to 200 KHz) can be supported within the operating bandwidth for MTC devices.

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

[0081] 2 is an example of a transmission bandwidth. FIG. 2 shows a nominal system bandwidth (cell) (e.g., 5 MHz), a UE channel bandwidth (e.g., 10 Mhz), a UE channel bandwidth (e.g., 20 MHz), and a UE channel bandwidth (5 MHz), all with separate allocations (which may or may not overlap) within the system bandwidth (e.g., 20 MHz). UE refers to a WTRU. Bandwidth flexibility can be achieved, for example, because the (e.g., all) applicable set of RF requirements for a given maximum operating bandwidth within a band can be met without introducing additional permitted channel bandwidth for that operating band, e.g., due to efficient support of baseband filtering of frequency-domain waveforms.

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

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

[0084] Cell-specific and / or WTRU-specific channel bandwidth for any spectrum block size can be increased, decreased and managed (eg, scheduling, addressing resources, broadcasted signals, measurements, etc.).

[0085] Downlink control channels and signals may support FDM operation. A WTRU may acquire a downlink carrier, for example, by receiving a transmission using (e.g., only) a nominal portion of the system bandwidth. For example, it is possible for a WTRU not to initially receive a transmission covering the entire bandwidth managed by the network for the carrier of interest.

[0086] Downlink data channels may be allocated across a bandwidth that may or may not correspond to the nominal system bandwidth, with no constraints other than being within the WTRU's configured channel bandwidth, for example. For example, a network may operate a carrier with a 12 MHz system bandwidth using a 5 MHz nominal bandwidth to allow devices supporting a maximum RF bandwidth of 5 MHz to acquire and access the system, while potentially allocating carrier frequencies from +10 to -10 MHz to other WTRUs supporting up to 20 MHz worth of channel bandwidth.

[0087] Figure 3 is an example of a flexible spectrum allocation. Figure 3 shows an example of a spectrum allocation in which different subcarriers can be allocated (e.g., at least conceptually) to different modes of operation (hereinafter, spectrum operation modes or SOMs). Different SOMs can be used to meet different requirements for different transmissions. The SOMs can be configured from subcarrier spacing, TTI length, and / or one or more reliability aspects (e.g., HARQ processing aspects, secondary control channels). The SOMs can be used to refer to (e.g., a particular) waveform or can relate to processing aspects (e.g., in supporting coexistence of different waveforms on the same carrier using FDM and / or TDM, or coexistence of FDD operation in TDD bands (e.g., with support in TDM modalities, etc.)).

[0088] A WTRU may be configured to perform transmissions according to one or more SOMs. For example, the SOM may correspond to transmissions using 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). The SOM may correspond to a QoS level and / or related aspects (e.g., maximum / target latency, maximum / target BLER, etc.). The SOM may correspond to a spectrum area and / or a specific control channel or aspect thereof (e.g., search space or DCI type). For example, a WTRU may be configured with an SOM for URC-type services, LLC-type services, and / or MBB-type services. The WTRU may have a configuration for an SOM for system access and / or for 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] Spectrum aggregation may be supported (e.g., for single carrier operation). The WTRU may, for example, support transmission and reception of multiple transport blocks across a contiguous or non-contiguous set of physical resource blocks (PRBs) within the same operating band. Mapping of a single transport block to separate sets of PRBs may be supported. Support may be provided for simultaneous transmissions associated with separate SOM requirements.

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

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

[0092] A basic time interval (BTI) may be represented by an integer number of one or more symbols, and the symbol duration may be a function of the subcarrier spacing applicable to the time-frequency resource. The subcarrier spacing (e.g., for FDD) may be determined by the spacing of the uplink carrier frequency f UL and downlink carrier frequency f DL It is possible for the value to differ between

[0093] The transmission time interval (TTI) may exclude the preamble and may include control information (e.g., DCI for the downlink or UCI for the uplink). DL) may correspond to the minimum time supported by the system between consecutive transmissions, each of which may be associated with a different transport block (TB) for the uplink (UL TRx). A TTI may be represented as an integer number of one or more BTIs. A BTI may be unique and / or associated with a given SOM.

[0094] For example, supported frame durations may include, for example, 100us, 125us (1 / 8ms), 142.85us (1 / 7ms may be 2nCP LTE OFDM symbols), and 1ms, for example, to allow alignment with the LTE timing structure.

[0095] The frame is divided into two parts by the associated carrier frequency (f for TDD). UL+DL , and f for FDD DL ) for a fixed duration t prior to a downlink data transmission (DL TRx) dci It is possible to start with the downlink control information (DCI) of

[0096] A frame may be composed of a downlink portion (DCI and DL TRx) (e.g., for TDD duplexing) and (e.g., optionally) an uplink portion (UL TRx). A switching gap (swg) may precede the uplink portion (e.g., if present) of the frame (e.g., for a frame of a given configuration).

[0097] A frame may consist of a downlink reference TTI (e.g., for TDD duplexing) and one or more TTIs (e.g., for the uplink). The start of an uplink TTI may, for example, be an offset (t offset ) can be derived using

[0098] 5gFLEX may support D2D / V2x / sidelink operation in a frame (e.g. for TDD) by including the respective downlink control and forward transmissions in the DCI+DL TRx part (e.g. if semi-static allocation of the respective resources is used) or in the DL TRx part (e.g. for dynamic allocation), and by including the respective reverse transmissions in the UL TRx part.

[0099] 5gFLEX may support D2D / V2x / sidelink operations in the UL TRx portion of the frame (e.g., for FDD), for example, by including the respective downlink control, forward transmission, and reverse transmission in the UL TRx portion. Dynamic allocation of the respective resources may be used.

[0100] Figures 4 and 5 provide example frame structures: Figure 4 is an example of timing relationships for TDD duplexing; and Figure 5 is an example of timing relationships for FDD duplexing.

[0101] Scheduling functions may be supported at the MAC layer. Support may be provided for multiple (e.g., two) scheduling modes, e.g., network-based scheduling (e.g., for tight scheduling in terms of resources, timing, and transmission parameters for downlink and / or uplink transmissions) and WTRU-based scheduling (e.g., for more flexibility in terms of timing and transmission parameters). Scheduling information for a mode may be valid for one or multiple TTIs.

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

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

[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) may be provided.

[0105] 5gFLEX may 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 may be supported, provided that the multiplexing does not negatively impact the services with the most stringent QoS requirements and does not result in unnecessary waste of system resources.

[0106] A transmission may be encoded using several different encoding methods, and the different encoding methods may have different characteristics.

[0107] For example, an encoding method may produce a sequence of information units. The (e.g., each) information unit, or block, may be self-contained. For example, an error in the transmission of a first block may not impair the receiver's ability to successfully decode the second block if the second block is error-free and / or if sufficient redundancy can be found in the second block or in another block that has been at least partially successfully decoded.

[0108] Example encoding techniques may include Raptor / Fountain codes; e.g., a transmission may consist of a sequence of N Raptor codes. One or more codes may be mapped in time to one or more transmission "symbols." A "symbol" may correspond to one or more sets of information bits, e.g., one or more octets. Encoding may be used to add FEC to the transmission; e.g., a transmission may use N+1 or N+2 Raptor codes or symbols (e.g., assuming one Raptor code symbol relationship). The transmission may be more resilient to the loss of one "symbol," e.g., due to interference or puncturing by another transmission that overlaps in time.

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

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

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

[0112] The WTRU may be configured to determine a relationship between separate data units. The relationship may be based on a matching function (e.g., based on the configuration of one or more field values ​​common to data units that are part of the same logical association). The fields may correspond to fields in a protocol header associated with the data unit. For example, the matching function may use a tuple of parameters for fields in the IP header of the data unit, 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 may share common radio bearers, processing functions, SOMs, and / or may correspond (e.g., at least conceptually) to the same LCH and / or LCG.

[0114] A logical channel group (LCG) may consist of a group of LCHs (or equivalents as defined above); for example, the grouping may be based on one or more criteria. The criteria may be, for example, that one or more LCHs may have a similar priority level applicable to all LCHs of the same LCG, or that they may be associated with the same SOM (or type thereof), the same slice (or type thereof). For example, the association may be characterized by at least one of a chain of processing functions, an applicable physical data (and / or control) channel (or instance thereof), or an instantiation of a protocol stack that may include (i) a certain centralized part (e.g., PDCP or everything other than RF), and (ii) another part closer to the edge (e.g., MAC / PHY in TRP or RF), potentially separated by a fronthauling interface. The term LCG as used herein may have a different and / or broader meaning than similar terms for LTE systems.

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

[0116] LTE may define several types of TrCHs, such as the Broadcast Channel (BCH), Paging Channel (PCH), Downlink Shared Channel (DL-SCH), Multicast Channel (MCH), Uplink Shared Channel (UL-SCH), and Random Access Channel (which may not carry user plane data). Transport channels for carrying user plane data may include the DL-SCH and UL-SCH for the downlink and uplink, respectively.

[0117] An increased set of requirements may be supported by the air interface for 5G systems. Support for multiple transport channels, e.g., for user plane data and / or control plane data, may be provided for one or more WTRU devices. The term TrCH as used herein may have a different and / or broader meaning 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) may be defined for downlink transmissions (e.g., DL-URLLCH, DL-MBBCH, and DL-MTCCH) and for uplink transmissions (e.g., UL-URLLCH, UL-MBBCH, and UL-MTCCH).

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

[0119] A WTRU may be configured with one or more parameters associated with a characterization of how data should be transmitted. The characterization may represent constraints and / or requirements that the WTRU may be expected to meet and / or enforce. The WTRU may perform different operations and / or adjust its behavior based on the state associated with the data based on the characterization. The parameters may include, for example, time-related aspects (e.g., a time-to-live (TTL) for a packet, representing the time before which the packet should be transmitted in order to meet or be recognized as meeting a latency requirement, etc.), rate-related aspects, and configuration-related aspects (e.g., absolute priority). The parameters may (e.g., also) change over time while a packet or data may be pending for transmission.

[0120] The 5G air interface may support different use cases with different QoS requirements, e.g., in terms of differentiation between applicable radio resources and transmission methods. For example, the TTI duration, reliability, diversity, and maximum latency applied to the transmission may be different in different use cases.

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

[0122] The procedures may optimize the creation and assembly of Layer 2 protocol data units (eg, MAC PDUs).

[0123] RLC segmentation, assembly, MAC layer multiplexing, and PHY layer encoding can be performed after receiving the grant. The latency of the grant for UL transmission may not be improved beyond the hardware and software latency of these operations.

[0124] Procedures for segmentation, assembly, and multiplexing may be provided. A scheduling function (e.g., in the network) may or may not have timely information and / or accurate knowledge of QoS requirements associated with data available for transmission in a WTRU buffer. The WTRU may perform actions to enable services with stringent reliability and / or latency requirements (e.g., for URLLC services).

[0125] The WTRU may use parameters to impact how and what data is transmitted and how PDUs are generated. The WTRU may be configured with one or more parameters associated with a characterization of how the data should be transmitted. The characterization may represent constraints and / or requirements that the WTRU may be expected to meet and / or enforce. The WTRU may perform different operations and / or adjust its behavior based on, for example, the state associated with the data based on the characterization.

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

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

[0128] Procedures may be provided for identifying PHY layer parameters prior to a grant. For example, a WTRU may identify or be configured with PHY layer parameters for transmission of data prior to receiving a grant for an 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 allowing the WTRU to perform an UL transmission with minimal delay from the transmission of an UL grant for a particular type of data, for example, to minimize latency associated with the UL transmission. Early identification of PHY layer parameters may (e.g., also) be employed in conjunction with other procedures described herein.

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

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

[0131] The WTRU may receive the PHY layer parameters from the network. The parameters may be received periodically or in response to one or more triggers. The triggers may include, for example, (i) a significant change 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 WTRU initiation of a service or logical channel, bearer, etc. (which may require the WTRU to have prior access to the PHY layer parameters).

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

[0133] The WTRU may (eg, further) indicate to the network if an event, such as one or more of the aforementioned events, occurs.

[0134] The MCS may be received and used for future grants. In an example implementation, the WTRU may periodically receive an MCS to be used for transmission of data over a portion of the transmission bandwidth. This may be limited, for example, to a predefined set of transport blocks (e.g., a predefined frequency range). The WTRU (e.g., upon receiving the periodic MCS transmission) may apply the signaled MCS to (e.g., all) transmissions made over the associated transmission bandwidth. The WTRU may determine (e.g., a priori or based on configuration) to associate one or more L2 protocol data units with the bandwidth range and (consequently) the originally signaled MCS. For example, the WTRU may determine that a set of logical channels may be provisioned with an MCS. The WTRU may map those logical channels to the portion of the bandwidth for which the MCS was signaled.

[0135] The periodic transmission of the MCS may be delivered to the WTRU, for example, through dedicated signaling on the PHY channel, through MAC CE or similar communications, or via RRC signaling. The WTRU may use the MCS following the transmission, for example, until it receives a new or updated MCS value for the same bandwidth area. The WTRU may receive multiple different MCS values, for example, to use for different bandwidth areas. The WTRU may receive the MCS for (e.g., only) a particular bandwidth area.

[0136] The WTRU may receive a subset of resources from which the grant may (e.g., subsequently) choose. For example, the WTRU may receive a resource range within its transmission bandwidth. The resource range may be used, for example, to indicate to the WTRU a set of resources on which the WTRU may be required to transmit from the time the grant arrives. The frequency range indicated by the PHY layer parameters may identify a set of resource blocks usable during the validity time of the PHY layer parameters, a set of subframes, TTIs, or symbols usable during the validity of the PHY layer parameters, or a combination thereof. The grant may indicate specific resources within the initial resource range to the WTRU. For example, the PHY layer parameters may select x resource blocks for each TTI that may be usable by the WTRU. The UL grant may indicate one or more of those x resource blocks to the WTRU for use by the WTRU to fulfill the grant.

[0137] An advantage of this technique may be that it reduces the latency associated with grant decoding, assuming, for example, that the portion of the resources indicated by the grant is already known a priori in PHY layer information previously received by the WTRU.

[0138] The WTRU may determine its PHY layer parameters (e.g., coding, modulation, power settings, etc.) prior to receiving the grant. The parameters may be determined using, for example, one or more of: (i) measurements of SNR, CQI, etc. performed by the WTRU on the DL, (ii) measurements of ACK / NACK frequencies of transmissions made on the frequency range of interest, and / or (iii) measurements of reference signal power, SINR, etc. associated with a reference signal on the frequency range of interest.

[0139] A WTRU may be configured by the network (e.g., dynamically or semi-statically) with frequency ranges that the WTRU may use (e.g., must use) to define its own set of PHY layer parameters.

[0140] The WTRU may periodically determine its PHY layer parameters, for example, based on measurements over a frequency range or set of frequency ranges, and may associate the PHY layer parameters to be applied with transmissions made on any resources for which it receives a grant.

[0141] The frequency ranges for WTRU-specific parameters may be dynamically configured by the network. For example, the WTRU may be configured by the network to perform the above-described measurements and calculations of MCS for (e.g., only) frequency ranges A and B, where A and B may be subsets of all frequencies. The WTRU may 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 frequency ranges over 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 changed by updated configuration. 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 ranges over which the WTRU can perform its own determination of PHY layer parameters.

[0143] The WTRU may signal PHY layer parameters. For example, the WTRU may signal PHY layer parameters that it has autonomously selected to the network. The WTRU may signal parameters during or in response to one or more of: (i) selection / determination of the parameters; (ii) during transmission of data that uses the parameters (in which case the WTRU may signal the parameters explicitly in control information and / or implicitly based on properties of the data being transmitted that imply the use of a particular selection of control parameters); (iii) upon request by the network; and / or (iv) when the network provides resources for transmission of data or control that may or may not be intended for transmission of these parameters.

[0144] The WTRU may (e.g., also) use any combination of the procedures discussed herein. For example, the WTRU may combine a first procedure that may provide a set of physical parameters with a second procedure that may provide a second set of parameters.

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

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

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

[0148] MAC PDUs / transport blocks can be created incrementally. TBs 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 receiving a grant. The latency of grants for UL transmissions may not be improved beyond the hardware and software latency of these operations.

[0149] For example, the WTRU may perform incremental creation of a transport block through the assembly of data blocks with a fixed size. The WTRU may perform data block creation immediately, or without having to wait for information in a grant from the network, by creating fixed-size data blocks as higher layer data arrives in the WTRU buffer. The WTRU may create a TB, for example, by allocating multiple data blocks to it in such a way that they occupy the size of the grant. The WTRU may (e.g., also) be given a grant that may be a multiple of a fixed data block size, for example, to minimize padding. The WTRU may (e.g., alternatively) fit as many data blocks into a transport block as allowed by the grant size. The WTRU may account for any remaining data with, for example, one or more of: (i) padding; (ii) MAC control information, e.g., information regarding needed resources, pending MAC PDUs for transmission, MAC PDU sizes, indications of packets with expired TTLs, etc.; and / or (iii) further coding, rate matching, etc., that may be inserted by the PHY layer.

[0150] A WTRU may be configured to utilize a (e.g., one) or finite set of specific data block sizes for a particular flow, bearer, logical channel, etc. The WTRU may (e.g., further) be restricted to using specific data block sizes for (e.g., 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, the WTRU may be required to utilize a specific data block size for data associated with URLLC, or flows with QoS features associated with URLLC, but may create data blocks that are not restricted in size for other flows or data.

[0151] The data block may, for example, consist of RLC PDUs or of PDUs associated with different protocol layers (MAC, PDCP, etc.).

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

[0153] The WTRU may receive one or more allowable data block size configurations to be applied for a particular (e.g., first) service type, flow, logical channel, etc., and a different set of allowable data block sizes for another set of (e.g., second) service types, flows, logical channels, etc. The WTRU may (e.g., in addition) receive a configuration change to the allowable data block sizes through (e.g., the same) signaling. The WTRU (e.g., upon receiving the change in configuration) may change corresponding sizes of created data blocks, e.g., from the time of receiving the signaling until receiving the new set of data block sizes.

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

[0155] The WTRU may select one or more data block sizes from a set of allowable sizes to be used (e.g., independently) for each created data block. The selection of a data block size may be made for one or more reasons, such as to adapt the type of traffic at higher layers based on the size of packets received over a recent timespan, the buffering capabilities of the WTRU, and / or other implementation-related aspects. The WTRU may (e.g., alternatively) select a data block size from the list of allowable sizes to be used for a particular flow, logical channel, etc. The WTRU may continue to use the selected data block size for the same flow, logical channel, etc. for a finite period of time. The WTRU may (e.g., also) perform the selection in response to the occurrence of other triggers, such as one or more of: (i) the arrival of a new type of data; (ii) the subsequent reception of a new set of data block sizes; (iii) the end of a frame / superframe or similar defined boundary; (iv) periodically or upon expiration of a timer; (v) upon detection (e.g., by the WTRU) of a change in channel quality or other similar measurement; and / or (vi) upon receipt of a new configuration from the network (e.g., a change in frequency, HARQ parameters, PHY configuration, etc.).

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

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

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

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

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

[0161] The WTRU may include information such as the size of pending TBs to be or ready to be transmitted by the WTRU (e.g., in the currently transmitted TB), which may be included in the MAC CE transmitted as part of the current TB being transmitted.

[0162] The WTRU may include (eg, in the current TB) one or more block sizes of prepared or pending blocks to be transmitted in a future TB.

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

[0164] The WTRU may (e.g., also) determine the PHY layer processing to be performed, e.g., based on received PHY layer information. For example, the WTRU may determine, e.g., based on receiving the coding scheme and coding parameters to use, that the WTRU may perform encoding prior to receiving the grant and that modulation may be provided as part of the grant.

[0165] The WTRU may (e.g., upon receipt of the grant) perform one or more of the following actions: (i) multiplexing and transport block creation; (ii) inserting padding bits into one (e.g., each) fixed-size data block or the entire transport block; (iii) creating or updating one or more data block headers to include information obtained upon 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 one (e.g., each) data block or the entire transport block.

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

[0167] MAC multiplexing may occur, for example, by TTL, eg, the WTRU may insert all data blocks in ascending TTL order.

[0168] MAC multiplexing may occur, for example, by logical channel priority and TTL. For example, the WTRU may (e.g., first) include all data blocks (where data may be associated with data blocks having data whose TTL may be below a certain threshold), and (e.g., second) perform LCP on any additional space in the grant.

[0169] MAC multiplexing may occur, for example, due to relationships between data blocks. For example, the WTRU may perform data block selection based on predefined relationships between data blocks, which may be indicated as part of the QoS. For example, several data blocks may have been formed from the same IP or PDCP packet. The WTRU may include related data blocks in the same transport block, for example, due to an indication from the QoS information that this is preferred or required.

[0170] MAC multiplexing may occur, for example, due to allowable QoS constraints in the grant. For example, the WTRU may perform data block selection by selecting data blocks (e.g., only those) that are associated with a single or limited set of flows, logical channels, or services (e.g., only those). The association may be identified in the grant or may be known a priori at the WTRU based on grant features, for example, related to PHY layer parameters or data block size, signaled to the WTRU prior to the grant.

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

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

[0173] The selection criteria may be utilized by the WTRU, for example, whether it creates a data block of a fixed size or whether the data block is sized dynamically (e.g., as 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 (e.g., each with its own CRC, referred to as a data block CRC). The transport block may carry its own CRC, which may be referred to as a TB CRC. The encoder may be configured to insert a shorter length CRC into one (e.g., each) code block, e.g., to enable power savings via early detection of decoding failures.

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

[0176] One or more example procedures described herein may be performed or applied partially or wholly on the network or the WTRU, for example, when the network transmits multiple data blocks to the WTRU. The WTRU may be configured with a certain percentage or number of data blocks in error for which it sends a HARQ-NACK.

[0177] Fast aggregated data block status reports can be provided for ultra-low latency retransmissions. For example, a base station can be configured to provide fast status report feedback for a data block to trigger a data block retransmission, which can be a new transmission from an HARQ perspective. For example, given that the number of data blocks can vary, the size of the feedback can be variable. The feedback can be aggregated over multiple TTIs.

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

[0179] In an example, the TRP may schedule the aggregated data block Ack / Nack message along with the UL grant. For example, the TRP may indicate resources for the aggregated data block Ack / Nack message that may occur at a later point in time. In an example, the WTRU may be configured to transmit the aggregated data block Ack / Nack message if (e.g., only if) scheduled by the TRP.

[0180] In an example, a similar approach as described for the uplink may be applicable to the downlink. The TRP may be configured to transmit multiple data blocks within a transport block. The WTRU may be configured to transmit an aggregated data block Ack / Nack message. The WTRU may be scheduled with resources that may be used or needed for the aggregated data block Ack / Nack message in a DCI associated with the associated transmission. The WTRU may receive an aggregated data block Ack / Nack message grant and transmit the grant on the associated resources. The WTRU may be configured not to transmit the aggregated data block Ack / Nack message, e.g., if not scheduled on the DCI. The network may configure a set of resources dedicated to (e.g., alternatively) transmission of the aggregated data block Ack / Nack.

[0181] In one (e.g., another) example, the WTRU may be configured to transmit an aggregated data block Ack / Nack message over L1, e.g., if no data is being transmitted, or (e.g., if there is data being transmitted) the WTRU may be configured to transmit the aggregated data block Ack / Nack together with the data in a control message (e.g., in a MAC header).

[0182] The size of the aggregated data block Ack / Nack message may be variable per TTI, but the size may be known to the network due to, for example, a scheduling grant. The WTRU may be configured to transmit an appropriate format for the aggregated data block Ack / Nack message, for example, following the associated DCI.

[0183] For example, flexible grant sizes may be allowed while filling the assembled PDU prior to receiving the grant. For example, a WTRU that performs MAC PDU assembly prior to grant allocation may flexibly adopt the resulting grant or grants to allow it to fit into the assembled MAC PDU. The WTRU may (e.g., autonomously) determine the number of grants or the size of each grant needed to transmit the assembled MAC PDU.

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

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

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

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

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

[0189] The WTRU may indicate the end / size of a transport block (TB) to the network. For example, the WTRU may indicate to the network, e.g., at any time during or after processing of a grant, the number of consecutive TTIs it can (e.g., will) use, and (e.g., therefore) the end of the transport block, e.g., to inform the network of the size of the transport block to be transmitted. The WTRU may indicate the end of the transport block to the network using, for example, one of the following procedures: (i) the WTRU may indicate the number of TTIs to be utilized to the network using PHY signaling (such as, but not limited to, PUCCH, SRS-like, RACH-like, or similar signaling); (ii) the WTRU may indicate the number of TTIs to be utilized to the network using a MAC CE provided as part of the transport block; (iii) the WTRU may send a special signal indicating the end of the transmission, for example, in part of the resources of the last TTI; and / or (iv) the WTRU may perform padding or subdivision of the MAC PDU into blocks at the PHY layer, whereby one or more block CRCs may have a CRC value indicating the number of TTIs to be utilized to transmit the transport block.

[0190] The WTRU may decide to combine separate grants to transmit a single TB. For example, the WTRU may select multiple UL grants to use in transmitting a single TB. For example, when the WTRU receives multiple grants in the same subframe or TTI, it may decide to combine the grants to transmit a single TB.

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

[0192] The WTRU may not need to indicate the selected transmission parameters used to perform the transmission. The WTRU may (e.g., alternatively) signal the selected transmission parameters using PHY signaling. The WTRU may indicate the selected transmission parameters, for example, by transmitting an index that may refer to the grant chosen for those transmission parameters. The association between the indicated index and the grant may be defined, for example, using a static rule. For example, a grant that refers to resources in the lowest frequency range may be associated with the lowest frequency range. The WTRU may (e.g., alternatively) provide properties associated with the grant itself in PHY layer signaling. For example, the WTRU may provide a modulation index of a grant with transmission parameters that may be used (e.g., to be used) to transmit the entire grant.

[0193] The WTRU may decide to combine resources or initial transmissions and retransmissions, for example, the WTRU may combine resources allocated to it for initial transmission and retransmissions of a TB, e.g., to transmit a single TB instead of multiple TBs.

[0194] The WTRU may be provided with resources for an eventual retransmission (e.g., in the case of a failed transmission), e.g., explicitly or implicitly. The WTRU may indicate this to the network (e.g., if the TB occupies more resources than were provided for the initial transmission), e.g., using one or more of the procedures described herein for UL indication.

[0195] The WTRU may encode the entire transport block according to the modulation and coding provided by the grant. The WTRU may transmit a portion of the transport block on the resources for the initial transmission. The WTRU may transmit the remainder of the resources of the TB block (e.g., once resources for retransmission become available). This may be repeated multiple times (e.g., the number of retransmissions allowed for the initial UL transmission) until the TB is completely transmitted.

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

[0197] The WTRU may send an indication to allocate more resources to complete the TB transmission. For example, the WTRU may transmit a portion of the TB within a grant provided by the network and provide an indication to the network that the entire transport block was not transmitted. The indication may (e.g., further) provide the remaining size of the TB. The WTRU may perform transmission of the remainder of the TB if the network provides a grant. The grant may be dedicated to (e.g., among other things) addressing the remaining data associated with the transport block.

[0198] The transport blocks may be generated early. In an example, the WTRU may be enabled to generate one or more transport blocks (or MAC PDUs) prior to receiving signaling to enable transmission of one or more transport blocks on specific resources, and the signaling may include grants received from downlink control information. Advance generation may be feasible, for example, when used with variable transmission durations.

[0199] In an example, one or more applicable transmission parameters for physical layer processing of a MAC PDU may be identified, for example, at the time of creation of the MAC PDU (e.g., prior to receiving the grant). For example, the WTRU may identify a coding scheme and / or coding rate applicable to a pre-generated MAC PDU of a given transport channel, for example, based on an indication received from the physical layer, MAC, or RRC signaling, prior to receiving the grant. One or more remaining applicable transmission 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 (e.g., explicitly) indicate the modulation scheme. The grant may (e.g., alternatively) indicate a duration and / or frequency allocation for transmission. The WTRU may implicitly derive a modulation scheme that may be applied (e.g., needs to be applied) to accommodate (e.g., all) coded bits in the indicated duration and / or frequency allocation.

[0200] The WTRU may, for example, determine the size of the MAC PDU according to one or more of: (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 an example, the sizes may be specified, e.g., from explicit indications from the physical layer, MAC, or RRC signaling, potentially for each type of service or transport channel. For example, the WTRU may be signaled a MAC PDU size of 3000 bits for a first transport channel and a MAC PDU size of 10000 bits for a second transport channel.

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

[0203] One or more of the possible sets of transmission parameters may be determined based on, for example, one or more of: (i) the most recent or most recent transmission or most recent initial HARQ transmission that occurred for the MAC PDU of the corresponding transport channel (e.g., modulation and coding); (ii) currently applicable transmission parameters for physical layer processing of the MAC PDU (e.g., coding scheme and / or rate); and / or (iii) an explicit indication from the physical layer, MAC, or RRC signaling (e.g., the frequency allocation or number of subcarriers or resource blocks that the WTRU may assume may be signaled).

[0204] The target duration for a transmission may be specified, for example, from an explicit indication from the physical layer, MAC, or RRC signaling. A target duration may be provided for each type of transport channel. The WTRU may, for example, set the size of the MAC PDU such that the duration of the transmission for the MAC PDU can (e.g., will) match or nearly match the target duration with an expected set of transmission parameters. This approach may ensure that the (e.g., required or maximum) duration for the transmission of the MAC PDU remains relatively close to the target, despite the fact that other transmission parameters that will be applicable to the transmission of the MAC PDU may differ from the expected set of transmission parameters, for example, due to changing radio conditions.

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

[0206] In an example, the second threshold may be pre-defined or obtained from physical layer, MAC, or RRC signaling. The threshold may be based on (e.g., alternatively) an amount of data that can be transmitted within a target duration for an expected set of transmission parameters. The expected set of transmission parameters may be obtained, for example, in accordance with one or more techniques described herein. In an example, the WTRU may, for example, pre-generate a new MAC PDU if the total duration required for transmission of (e.g., all) outstanding pre-generated MAC PDUs cannot exceed a threshold value such as 5 ms. The target duration may, for example, be pre-defined or obtained from physical layer, MAC, or RRC signaling.

[0207] Pre-generated MAC PDUs may be transmitted. For example, the WTRU may receive signaling (e.g., a grant) that enables transmission of one or more MAC PDUs on resources. The transmission may be conditional, for example, based on clear channel assessment conditions, e.g., when the WTRU is operating in an unlicensed band. The one or more MAC PDUs may have been pre-generated, for example, according to one or more techniques described herein.

[0208] The WTRU may receive one or more transmission parameters, such as a frequency allocation, a modulation scheme, a coding scheme and / or rate, or one or more of multiple spatial layers. The one or more parameters may have been provided in advance of signaling enabling transmission of the MAC PDU. The WTRU may determine the required duration of the transmission, e.g., such that a sufficient number of resource elements may be available to map the modulation symbols. This determination may take into account one or more parameters and / or any (e.g., required) reference signals and / or physical control information to be multiplexed with higher layer data. The WTRU may perform the transmission accordingly.

[0209] In an example, the WTRU may transmit control information to assist the receiver in determining the transmission duration. For example, the WTRU may provide an indication of the duration expressed as multiple time units (e.g., symbols or subframes) encoded in uplink or sidelink control information, such as in a scheduling allocation. In one (e.g., another) example, the WTRU may transmit an indication in a symbol of a transmission (e.g., in or after the last symbol) indicating that the transmission will not continue. In one (e.g., another) example, the WTRU may 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] The WTRU may receive the maximum transmission duration, e.g., as part of a grant or from previous signaling. If, for example, the transmission duration for a MAC PDU can (e.g., will) exceed the maximum value, the WTRU may, for example, do one or more of: (i) discard the MAC PDU; (ii) send an indication that the maximum transmission duration is too small for transmission of the MAC PDU (where the indication may, for example, be encoded as physical control information in a MAC PDU created for this purpose or as MAC signaling); and / or (iii) modify at least one transmission parameter, such as a coding scheme, a coding rate, or a modulation scheme, e.g., compared to the signaled transmission parameter, e.g., such that the total required duration cannot exceed the maximum value. In an example, the WTRU may employ a higher-order modulation (e.g., 16-QAM instead of QPSK), a higher (e.g., effective) coding rate (e.g., 3 / 4 instead of 1 / 3) (which may be implemented, for example, by puncturing multiple coded bits). The WTRU may send an indication of whether the modification has been applied and / or an indication of the modified value, for example, in uplink or sidelink control information.

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

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

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

[0214] The WTRU may assemble a MAC PDU for each configured value of minimum guaranteed TBS (TBSmin) (e.g., if there are multiple values). The WTRU may (e.g., subsequently) determine the final value of TBS (TBSfinal) for the transmission, e.g., from receiving a DCI granting uplink resources.

[0215] The TBS may be adapted over time. For example, the WTRU may determine a final set of parameters (TBSfinal) for a transmission using a minimum TBS guarantee associated with a single transport block, e.g., from receiving downlink control signaling. The received DCI may explicitly indicate a particular data unit to be provided with the transmission. The received DCI may indicate a processing time applicable to the transmission, e.g., whereby the WTRU may be instructed to perform a transmission at time n+x μsec / ms / subframe or some other unit of time for a DCI received at time n. In an example, the WTRU may determine a minimum duration of a transmission of a TB, e.g., based on a signaled MCS, set of PRBs, etc., e.g., using a minimum configured TBS value greater than the TBS resulting from information included in the DCI signaling. In an example, the WTRU may identify a shortest duration that matches a framing boundary in time (e.g., matches the end of the DL transmission portion of a subframe) that can fit a minimum configured TBS value that is larger than the TBS resulting from information included in the DCI signaling. For example, this may 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 an example, the WTRU may perform multi-TTI TB transmission (e.g., for a single MAC PDU for the applicable data unit) or TTI bundling (e.g., for multiple segments such as RLC or MAC as separate MAC PDUs for the applicable data unit) for transmission of pre-assembled MAC PDUs. The number of TTIs may be an integer that is identified based on the guaranteed / configured TBS value (e.g., TBSmin) and the TBS value resulting from information in the DCI.

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

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

[0218] The WTRU may include in its uplink transmission an indication of the desired TBS and / or an increase / decrease indication thereof, e.g., a separate value in a configured set of values. The indication may be applicable to a particular type of data unit and / or configuration. The indication may be included in the BSR or provided using a bit in the MAC PDU header that represents an index into a pre-configured set of values. The indication may be a request for an increase in processing time.

[0219] The WTRU may use information regarding the minimum guaranteed TBS for identification of an LCH (or equivalent) from which data may be provided for assembly of a MAC PDU. One or more other aspects may be taken into account, such as latency, time to live, PBR, priority, etc., for example, according to one or more procedures described herein.

[0220] Any of the above procedures may be applicable if the WTRU performs assembly of the MAC PDU when the grant is decoded and (e.g., all) information is known, such as when the WTRU is configured to provide data from a particular LCH (or equivalent) based on a minimum configured data unit size.

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

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

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

[0224] One or more parameters may correspond to a set of parameters. The WTRU may use a procedure to identify one or more of the sets of parameters. The set may be a configuration aspect of the WTRU. For example, one or more (e.g., a set) parameters may correspond to transmissions characterized by higher reliability, lower latency, best-effort type transmissions, or to another type of service, e.g., paging, reception of system information, broadcast transmissions, etc. The set may correspond to a SOM.

[0225] Decoding the control channel may correspond to blind decoding attempts. The WTRU may perform one or more decoding attempts, for example, each attempt using a different set of decoding aspects (e.g., parameters and / or procedures). The decoding aspects may include the set and / or amount of physical resources used for the channel (e.g., control channel elements), the aggregation level (AL), the size of the CRC (e.g., 8 bits, 16 bits, and / or differentiated using different polynomials), the associated search space, the identity of the corresponding control channel, or a combination thereof.

[0226] The robustness of the DCI may indicate something on the transmission. For example, the WTRU may specify that the received DCI has been successfully decoded according to one of multiple robustness / reliability levels. The WTRU may specify appropriate values ​​for one or more parameters associated with the transmission, e.g., whereby a similar reliability level may be assumed for the transmission. For example, the network may specify an explicit / implicit indication to use based on applicable link adaptation mechanisms, e.g., uplink control information and / or channel condition indications received from the WTRU.

[0227] The WTRU may, for example, identify a minimum level of robustness and / or QoS level applicable to the transmission based on the identified set of one or more parameters. For example, the WTRU may identify an applicable SOM. The WTRU may (e.g., further) identify data applicable to the UL transmission based on an associated QoS level.

[0228] The WTRU may identify a HARQ process and / or feedback. For example, the WTRU may identify a type of HARQ process to apply to a transmission (e.g., in the case of an initial transmission, uplink, or downlink) and / or a type of HARQ feedback (e.g., required) for a transmission, e.g., based on an identified set of one or more parameters. For example, the WTRU may specify (e.g., for receiving a DL transmission) that HARQ feedback can be expected at (or within) a particular time interval using a particular transmission procedure (e.g., an applicable uplink control channel) or that feedback should not be generated automatically (e.g., should be generated only upon request), e.g., based on an identified set of parameters. For example, the WTRU may identify an applicable SOM and perform the HARQ process and / or feedback accordingly.

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

[0230] For example, the WTRU may perform a similar determination regarding a DCI that schedules a downlink transmission, so that it can properly determine parameters for decoding the associated transmission.

[0231] The WTRU may determine a robustness level of a received grant, for example, based on decoding the DCI. The WTRU may determine such robustness level according to, for example, one or more of: (i) characteristics of the successful decoding attempt, such as one or more of the AL associated with the successfully decoded DCI, the size of the CRC associated with the successfully decoded DCI, the CRC polynomial associated with the successfully decoded DCI, the CCE (or the first CCE) associated with the successfully decoded DCI, the search space (or the start) associated with the successfully decoded DCI, and / or the associated control channel type, resource in time / frequency, and / or identity; (ii) the received DCI format; and / or (iii) an explicit indication in a field in the DCI format.

[0232] A WTRU may be configured for association with a set of robustness levels and / or parameters.

[0233] The robustness level may be determined from the aggregation level or the CRC. For example, the WTRU may determine the robustness level based on the aggregation level or search space that resulted in successful decoding of the DCI. For example, the robustness level may be determined as a first value if the aggregation level is determined to be 1, 2, or 4 (e.g., aggressive AL for a particular reliability operating point), and as a second value if the aggregation level is determined to be 8 or 16 (e.g., conservative AL for a higher reliability operating point).

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

[0235] The transmission parameters may be selected based on the robustness level. For example, the WTRU may select the transmission parameters to be used for the UL transmission associated with the grant depending on the signaled robustness level. The selection may, for example, be based on predefined rules or may be configured by the network (e.g., in RRC signaling). The selection may (e.g., also) be combined with other procedures, such as one or more described herein. In an example, the selection may be based on, for example, one or more of: (i) the physical resources utilized for the uplink transmission (e.g., if the identification of the set of applicable resources for the transmission may itself be independent of such identification); (ii) the type of data being transmitted (e.g., if the selection of the data may itself be independent of such identification); (iii) the current state of the WTRU (e.g., the current power headroom); and / or (iv) the current state of the data (e.g., the TTL of the data).

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

[0237] Systems, methods, and means (e.g., aspects of entities, interfaces, and procedures in the WTRU and / or network layers L1, L2, and L3) have been disclosed for low latency MAC PDU assembly in wireless systems, such as 5gFLEX. For example, latency can be reduced by the WTRU specifying and signaling network transmission parameters prior to a transmission grant. The WTRU can receive the MCS, resource range, etc., prior to the grant, e.g., for use in future grants. Data blocks can be incrementally created / encoded prior to the grant. Data units can be segmented, assembled, and multiplexed based on data block sizes, e.g., to enable MAC and RLC processing prior to the grant. 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 the MAC PDU. Transmission parameters can be selected prior to the grant, e.g., using blind decoding or DCI reception procedures.

[0238] The processes and methods described herein may be applied in any combination and to other wireless technologies and for other services.

[0239] The WTRU may refer to a physical device identity or a subscription-related identity, e.g., a user identity such as MSISDN, SIP URI, etc. The WTRU may refer to an application-based identity, e.g., a username that may be used per application.

[0240] Each of the computing systems described herein may have one or more computer processors having memory configured with executable instructions or hardware for performing the functions described herein, including determining the parameters described herein and sending and receiving messages between entities (e.g., the WTRU and the network) to achieve the described functions. The processes described above may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or processor.

[0241] The processes described above may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium 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, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as CD-ROM disks and / or digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, an RNC, and / or any host computer.

Claims

1. monitoring downlink control information (DCI) over at least resources of a downlink control channel; identifying the resources of the downlink control channel; decoding at least a first DCI on the downlink control channel that includes scheduling information for at least one data transmission corresponding to one of a downlink transmission or an uplink transmission; Identifying at least one decoding parameter used to decode the first DCI; and determining one or more transmission or reception parameters for the at least one data transmission based on the at least one decoding parameter used to decode the first DCI; and a processor configured to: A wireless transmit / receive unit (WTRU) comprising:

2. The WTRU of claim 1 , wherein the at least one decoding parameter used to decode the first DCI includes one or more of a cyclic redundancy check length or an aggregation level.

3. The WTRU of claim 1 , wherein the resources of a downlink control channel include a set of physical resource blocks.

4. 10. The WTRU of claim 1, wherein the at least one decoding parameter indicates whether the at least one data transmission is associated with one or more of high reliability data, low latency data, or best effort data.

5. 10. The WTRU of claim 1, wherein the processor is further configured to transmit HARQ-ACK feedback over a resource associated with the identified decoding parameters of the decoded downlink control channel indication.

6. 2. The WTRU of claim 1, wherein the decoding comprises blind decoding, and the decoding parameters comprise a subset of resources used to decode the first DCI when performing blind decoding.

7. 7. The WTRU of claim 6, wherein the subset of resources includes one or more control channel elements (CCEs), the identity of the one or more CCEs corresponding to the at least one decoding parameter.

8. 2. The WTRU of claim 1, wherein the at least one decoding parameter comprises a robustness level associated with the first DCI, wherein a higher robustness level for the first DCI indicates a higher robustness level for the data transmission, and a lower robustness level for the first DCI indicates a lower robustness level for the data transmission.

9. 2. The WTRU of claim 1, wherein the one or more transmission or reception parameters for the at least one data transmission include one or more of a quality of service (QoS) level associated with the at least one data transmission or a spectrum operating mode (SOM) associated with the at least one data transmission.

10. 10. The WTRU of claim 1, wherein the one or more transmission or reception parameters for the at least one data transmission comprise hybrid automatic repeat request (HARQ) feedback parameters associated with the at least one data transmission.

11. The WTRU of claim 10 , wherein the HARQ feedback parameters include timing information for transmission or reception of HARQ feedback.

12. 10. The WTRU of claim 1, wherein the processor is further configured to receive a configuration from a network entity, the configuration indicating a mapping between the one or more decoding parameters and the one or more transmit or receive parameters for the at least one data transmission.

13. The WTRU of claim 1 , wherein the at least one decoding parameter has a DCI format.

14. 2. The WTRU of claim 1, wherein the one or more transmission or reception parameters for the data transmission include one or more of a modulation and coding scheme (MCS), a set of physical resource blocks associated with the at least one data transmission, power information associated with the at least one data transmission, transmission timing information for the at least one data transmission, or a transmission timer interval (TTI) duration associated with the at least one data transmission.

15. 1. A method of using a wireless transmit / receive unit (WTRU), comprising: monitoring downlink control information (DCI) over at least resources of a downlink control channel; identifying the resources of the downlink control channel; decoding at least a first DCI on the downlink control channel, the DCI including scheduling information for at least one data transmission corresponding to one of a downlink transmission or an uplink transmission; identifying at least one decoding parameter used to decode the first DCI; and determining the one or more transmission or reception parameters for the at least one data transmission based on the at least one decoding parameter used to decode the first DCI.

16. 16. The method of claim 15, wherein the at least one decoding parameter used to decode the first DCI includes one or more of a cyclic redundancy check length or an aggregation level.

17. The method of claim 15 , wherein the resources of a downlink control channel comprise a set of physical resource blocks.

18. 16. The method of claim 15, wherein the at least one decoding parameter indicates whether the at least one data transmission is associated with one or more of high reliability data, low latency data, or best effort data.

19. 16. The method of claim 15, further comprising transmitting HARQ-ACK feedback over resources associated with the identified decoding parameters of the decoded downlink control channel indication.

20. 16. The method of claim 15, wherein the decoding step includes blind decoding, and the decoding parameters include a subset of resources used to decode the first DCI when performing blind decoding.

21. 21. The method of claim 20, wherein the subset of resources includes one or more control channel elements (CCEs), the identity of the one or more CCEs corresponding to the at least one decoding parameter.

22. 16. The method of claim 15, wherein the at least one decoding parameter includes a robustness level associated with the first DCI, a higher robustness level for the first DCI indicating a higher robustness level for the data transmission, and a lower robustness level for the first DCI indicating a lower robustness level for the data transmission.

23. 16. The method of claim 15, wherein the one or more transmission or reception parameters for the at least one data transmission include one or more of a Quality of Service (QoS) level associated with the at least one data transmission, or a Spectrum Operating Mode (SOM) associated with the at least one data transmission.

24. 16. The method of claim 15, wherein the one or more transmission or reception parameters for the at least one data transmission comprise hybrid automatic repeat request (HARQ) feedback parameters associated with the at least one data transmission.

25. 25. The method of claim 24, wherein the HARQ feedback parameters include timing information for transmission or reception of HARQ feedback.

26. 16. The method of claim 15, further comprising receiving a configuration from a network entity, the configuration indicating a mapping between the one or more decoding parameters and the one or more transmission or reception parameters for the at least one data transmission.

27. The method of claim 15 , wherein the at least one decoding parameter has a DCI format.

28. 16. The method of claim 15, wherein the one or more transmission or reception parameters for the data transmission include one or more of a modulation and coding scheme (MCS), a set of physical resource blocks associated with the at least one data transmission, power information associated with the at least one data transmission, transmission timing information for the at least one data transmission, or a transmission timer interval (TTI) duration associated with the at least one data transmission.

Images