Medium access protocol data unit assembly in wireless systems

Abstract

Systems, methods, and measures (e.g., aspects of entities, interfaces, and processes in a wireless transmit / receive unit (WTRU) and / or network layers L1, L2, L3) are disclosed for low latency medium access control (MAC) protocol data unit (PDU) assembly in wireless systems such as 5G flexible radio access technology (RAT) (5g FLEX). The latency may be reduced, for example, by a WTRU determining network transmission parameters and signaling prior to a transmission grant. The WTRU may receive a modulation and coding scheme (MCS), resource range, etc. prior to the grant for use in later grants, for example. Data blocks may be incrementally created / encoded prior to permission. Data units may be segmented, assembled, and multiplexed, for example, based on a data block size that allows MAC and radio link control (RLC) processing prior to permission. A flexible grant size may be provided for early generation of transport blocks prior to grant.

Description

[0001] This application is a divisional application of Chinese patent application No. 202110295595.8, entitled “MEDIA ACCESS PROTOCOL DATA UNIT ASSEMBLY IN A WIRELESS SYSTEM”, filed on May 10, 2017, which is a divisional application of Chinese patent application No. 201780028257.X.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to and the benefit of U.S. Provisional Application Serial No. 62 / 334,529, filed May 11, 2016, which is incorporated herein by reference. Background Art

[0004] Mobile communications continue 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

[0005] Disclosed are systems, methods, and measures (e.g., aspects of entities, interfaces, and processes in a wireless transmit / receive unit (WTRU) and / or network layers L1, L2, L3) for low-latency medium access control (MAC) protocol data unit (PDU) assembly in a wireless system (e.g., 5G flexible radio access technology (RAT) (5gFLEX)). Latency can be reduced, for example, by the WTRU determining network transmission parameters and signaling before transmitting a grant. The WTRU can receive a modulation and coding scheme (MCS), resource range, etc. before a grant, for example, for use in a subsequent grant. Data blocks can be incrementally created / encoded before a grant. Data units can be segmented, assembled, and multiplexed, for example, based on data block sizes allowed for MAC and radio link control (RLC) processing before a grant. Flexible grant sizes can be provided for a previous generation of pre-grant transmission blocks. A minimum guaranteed transport block size (TBS) can be signaled to allow a previous generation of MAC PDUs. Transmission parameters can be selected before a grant, for example, using a blind decoding or DCI reception process.

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

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

[0008] The WTRU processor may be configured to transmit HARQ-ACK feedback via resources associated with the determined decoding parameters indicated by the decoded downlink control channel.

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

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

[0011] The one or more transmission or reception parameters for 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 operation mode (SOM) associated with the at least one data transmission. The one or more transmission or reception parameters for at least one data transmission may include a hybrid automatic repeat request (HARQ) feedback parameter associated with the at least one data transmission. The HARQ feedback parameter may include timing information for transmission or reception of HARQ feedback.

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

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

[0014] A method using a WTRU may include one or more of the following: (i) monitoring downlink control information (DCI) on 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, which includes 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 for decoding the first DCI; and (v) determining one or more transmission or reception parameters for at least one data transmission based on the at least one decoding parameter for decoding the first DCI.

[0015] A method using a WTRU may include: (i) transmitting HARQ-ACK feedback via resources associated with determined decoding parameters indicated by a decoded downlink control channel, and / or (ii) receiving a configuration from a network entity, wherein the configuration indicates a mapping between one or more decoding parameters and one or more transmission or reception parameters for at least one data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1B Yes, you can Figure 1A A system diagram of an example WTRU used in a communication system shown in FIG.

[0018] Figure 1C Yes, you can Figure 1A A system diagram of an example radio access network and an example core network used in a communication system shown in FIG.

[0019] Figure 1D Yes, you can Figure 1A A system diagram of another example radio access network and another example core network used in the communication system shown in;

[0020] Figure 1E Yes, you can Figure 1A A system diagram of another example radio access network and another example core network used in the communication system shown in;

[0021] Figure 2 is an example of transmission bandwidth;

[0022] Figure 3 is an example of flexible spectrum allocation;

[0023] Figure 4 is an example of a timing relationship for TDD duplex;

[0024] Figure 5 is an example of the timing relationship for FDD duplex. DETAILED DESCRIPTION

[0025] A detailed description of exemplary embodiments is now described with reference to the accompanying drawings. Although the description provides detailed examples of possible implementations, it should be noted that these details are merely illustrative and in no way limit the scope of the present application.

[0026] Figure 1A 1 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 such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 allows multiple wireless users to access such content by sharing system resources including wireless bandwidth. As an example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), etc.

[0027] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (generally or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, but it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, and / or 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop computer, a netbook, a personal computer, a wireless sensor, a consumer electronic device, and the like.

[0028] The communication system 100 may also include a base station 114a and a base station 114b. Each base station 114a, 114b may be any type of device configured to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the network 112, by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. By way of example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, and the like. Although each base station 114a, 114b is depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0029] The base station 114a may be part of the RAN 103 / 104 / 105, and the RAN may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a specific geographic area called 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 one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, whereby multiple transceivers may be used for each sector of the cell.

[0030] The base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via an air interface 115 / 116 / 117, which may be any suitable wireless communication 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.

[0031] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) and may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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).

[0032] 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).

[0033] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio access technologies such as IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0034] As an example, Figure 1A The base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, and the like. In some embodiments, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE802.11. In another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b does not necessarily need to access the Internet 110 via the core network 106 / 107 / 109.

[0035] The RAN 103 / 104 / 105 may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although in Figure 1AAlthough not shown, it will be appreciated that the RAN 103 / 104 / 105 and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 103 / 104 / 105. For example, in addition to being connected to the RAN 103 / 104 / 105 employing E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing GSM radio technology.

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

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

[0038] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1BAs shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a numeric keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiment. The embodiments herein also contemplate that the base stations 114a and 114b, and / or the nodes represented by the base stations 114a and 114b may include Figure 1B Some or all of the elements depicted in and described herein, in particular, the nodes represented by base stations 114a and 114b can be transceiver stations (BTS), node Bs, site controllers, access points (APs), home node Bs, evolved home node Bs (eNode Bs), home evolved node Bs (HeNBs or HeNode Bs), home evolved node B gateways, and proxy nodes, but are not limited to these.

[0039] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. 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 Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it should be appreciated that the processor 118 and the transceiver 120 may be integrated into one electronic component or chip.

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

[0041] In addition, although Figure 1B 102 as a single element, but the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 115 / 116 / 117.

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

[0043] The processor 118 of the WTRU 102 may be coupled to 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), and may receive user input data from these elements. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memories that are not physically located in the WTRU 102, such as, for example, a server or a home computer (not shown).

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

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

[0046] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and 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 video game console module, an Internet browser, and the like.

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

[0048] like Figure 1CAs shown, Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can also communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each RNC 142a, 142b can be configured to control the corresponding Node B 140a, 140b, 140c connected thereto. In addition, each RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security function, data encryption, etc.

[0049] Figure 1C The illustrated core network 106 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 foregoing elements are described as being part of the core network 106, it should be appreciated that entities other than the core network operator may own and / or operate any of these elements.

[0050] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the 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 land-line communications devices.

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

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

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

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

[0055] Each eNodeB 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, and the like. Figure 1D As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0056] Figure 1D The illustrated core network 107 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 are described as being part of the core network 107, it should be understood that entities other than the core network operator may also own and / or operate any of these elements.

[0057] 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 serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function to facilitate handover between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0058] 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 anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0060] The core network 107 may facilitate communications 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 communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. As an example, the core network 107 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, which serves as an interface between the core network 107 and the PSTN 108. The core network 107 may also provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0061] Figure 1E 1 is a system diagram of the RAN 105 and the core network 109 according to one embodiment. The RAN 105 may be an access service network (ASN) that communicates with the WTRUs 102a, 102b, 102c over the air interface 117 using IEEE 802.16 radio technology. As discussed further below, communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 104, and the core network 109 may be defined as reference points.

[0062] like Figure 1EAs shown, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. Each base station 180a, 180b, 180c may be associated with a particular cell (not shown) in the RAN 105, and each base station may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c via the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to transmit wireless signals to the WTRU 102a, and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy implementation, and the like. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for implementing paging, subscriber profile caching, routing to the core network 109, and the like.

[0063] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point implementing the IEEE 802.16 specification. In addition, 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, admission, IP host configuration management, and / or mobility management.

[0064] The communication link between each base station 180a, 180b, 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and data transfer between 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. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each WTRU 102a, 102b, 180c.

[0065] like Figure 1EAs shown, 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, which, as an example, includes protocols for facilitating data transfer and mobility management capabilities. 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. Although each of the aforementioned elements are described as being part of the core network 109, it should be understood that an entity other than the core network operator may also own and / or operate any of these elements.

[0066] The MIP-HA may be responsible for implementing IP address management and may allow 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 communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for implementing 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 communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. In addition, the gateway 188 may also provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0067] Although in Figure 1E Not shown, but appreciated, 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 the 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 point, which may include protocols for facilitating interworking between a home core network and a visited core network.

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

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

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

[0071] Support for Ultra Reliable Transport (URC) may include, for example, improved transport reliability, such as 99.999% transport success and service availability. Support may be provided for mobile speeds ranging from 0-500 km / h. Sub-10e-4G may be provided, for example, for IC and V2X -6 The packet loss rate.

[0072] Support for MTC operations may include, for example, air interface support for narrowband operation (e.g., using less than 200KHz), extended battery life (e.g., up to 15 years of autonomy), and minimal communication overhead for small and infrequent data transmissions (e.g., low data rates in the range of 1-100kbps with access latency of a few seconds to a few hours).

[0073] The 5gFLEX system may be implemented with OFDM and / or other waveforms for uplink and / or downlink. The description of the examples herein is non-limiting. The examples are applicable and may be adapted to other waveforms and wireless technologies.

[0074] OFDM can be used as a signal format for data transmission, for example in LTE and IEEE 802.11. OFDM can effectively divide the spectrum into multiple parallel orthogonal subbands. (Each) subcarrier can be shaped using a rectangular window in the time domain, which may produce a sinusoidal shaped subcarrier in the frequency domain. OFDMA can rely on (e.g. perfect) frequency synchronization and tight management of uplink timing alignment within the duration of the cyclic prefix, for example to maintain orthogonality between signals and minimize inter-carrier interference. Tight synchronization may be difficult, for example, in a system where the WTRU can be connected to multiple access points simultaneously. Additional power reduction can be applied to uplink transmissions, for example to meet the spectrum emission requirements of adjacent bands. Segmented spectrum can be aggregated for WTRU transmissions.

[0075] For example, OFDM (CP-OFDM) performance can be improved by implementing stricter RF requirements (e.g., operation using large amounts of contiguous spectrum that does not require aggregation). The CP-based OFDM transmission scheme can provide a downlink physical layer for 5G similar to the 4G system, which modifies the pilot signal density and location.

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

[0077] A multi-carrier modulation waveform may divide a channel into multiple sub-channels and may modulate data symbols on sub-carriers in the sub-channels.

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

[0079] In the example of Universal Filtered Multi-Carrier (UFMC), such as UF-OFDM, filters can be applied to OFDM signals in the time domain to reduce OOB. Filtering can be applied per sub-band to use spectrum segmentation, which can reduce complexity and make UF-OFDM more practical to implement. OOB emissions in unused spectrum segments in the band can be as high as in OFDM. UF-OFDM can provide some improvement over OFDM at the edges of the filtered spectrum, and little to no improvement in the spectrum holes.

[0080] These waveforms enable frequency reuse of signals with non-orthogonal characteristics (e.g., different subcarrier spacings) and coexistence of asynchronous signals without the need for complex interference cancellation receivers. These waveforms can facilitate aggregation of segmented spectrum in baseband processing, for example as a lower cost alternative to its implementation as part of RF processing.

[0081] Coexistence of different waveforms within the same frequency band may be considered, for example to support mMTC narrowband operation (e.g. using SCMA). Different waveforms, such as CP-OFDM, OFDM-OQAM, and UF-OFDM, may be combined in the same frequency band, for example for all aspects and for downlink and uplink transmissions. Coexistence of different waveforms may include transmissions using different types of waveforms between different WTRUs or transmissions from the same WTRU (e.g. simultaneously) where there is some overlap in the time domain or are continuous.

[0082] Other coexistence aspects may include support for mixed types of waveforms, such as waveforms and / or transmissions that may support, for example, CP durations that may vary (e.g., from one transmission to another), combinations of CP and low power tails (e.g., zero tails), and / or forms of mixed guard intervals (e.g., using low power CP and adaptive low power tails), etc. The waveforms may support dynamic changes and / or control of other aspects, such as how filtering is applied (e.g., at the edge of the spectrum for reception of arbitrary transmissions on a given carrier frequency, at the edge of the spectrum for reception of transmissions associated with a particular SOM, whether filtering is applied per subband or per subband group).

[0083] The uplink transmission scheme may use the same or a different waveform used for downlink transmission.

[0084] For example, transmissions to and from different WTRUs may be multiplexed in the same cell based on FDMA and TDMA.

[0085] 5gFLEX radio access may be characterized by a very high degree of spectrum flexibility, which enables deployment in different frequency bands with different characteristics, which may include different duplex arrangements, different and / or variable sizes of available spectrum, such as contiguous and non-contiguous spectrum allocations in the same or different frequency bands. 5gFLEX radio access may support variable timing aspects, such as support for multiple TTI lengths and asynchronous transmissions.

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

[0087] 5G air interface characteristics or capabilities may enable different transmission bandwidths on uplink and downlink, ranging, for example, between a nominal system bandwidth and a maximum value corresponding to the system bandwidth.

[0088] Single carrier operation may support multiple or a range of system bandwidths, such as 5, 10, 20, 40 and 80 MHz, 160 MHz. The nominal bandwidth may have one or more fixed values. Narrowband transmission (e.g., 0 to 200 KHz) may be supported within the operating bandwidth of the MTC device.

[0089] The system bandwidth may refer to the maximum portion of the spectrum that the network can manage for a given carrier. The portion of the spectrum of a carrier that the WTRU minimally supports for cell acquisition, measurements, and initial access to the network may correspond to the nominal system bandwidth. The WTRU may be configured with a channel bandwidth that may be within the range of the entire system bandwidth. The configured channel bandwidth of the WTRU may or may not include the nominal portion of the system bandwidth, for example, Figure 2 as shown in the example.

[0090] Figure 2 is an example of transmission bandwidth. Figure 2 A nominal system bandwidth (cell) (e.g., 5 MHz), a UEx channel bandwidth (e.g., 10 MHz), a UEy channel bandwidth (e.g., 20 MHz), and a UEz channel bandwidth (5 MHz) are shown, all at different allocations, which may or may not overlap within the system bandwidth (e.g., 20 MHz). UE refers to a WTRU. Bandwidth flexibility may be achieved, for example, because (e.g., all) applicable sets of RF requirements for a given maximum operating bandwidth in a band may be satisfied without introducing additional allowed channel bandwidths for that operating band, for example, because of efficient support of baseband filtering of frequency domain waveforms.

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

[0092] The 5G air interface physical layer may be band agnostic and may support operations in licensed bands (e.g., below 5 GHz) and unlicensed bands (e.g., in the range 5-6 GHz). For example, a LBT Cat 4-based channel access framework similar to LTE LAA may be supported for operations in unlicensed bands.

[0093] Cell-specific and / or WTRU-specific channel bandwidths for arbitrary spectrum block sizes may be scaled and managed (eg, scheduling, resource addressing, broadcast signals, measurements, etc.).

[0094] Downlink control channels and signals may support FDM operation. The WTRU may acquire a downlink carrier, for example, by receiving transmissions using (eg, using only) a nominal portion of the system bandwidth. For example, the WTRU may not initially receive transmissions covering the entire bandwidth managed by the network for the carrier in question.

[0095] Downlink data channels may be allocated on a bandwidth that may or may not correspond to the nominal system bandwidth, e.g., without restriction other than within the configured channel bandwidth of the WTRU. For example, a network may operate a carrier with a 12 MHz system bandwidth using a 5 MHz nominal bandwidth, allowing devices supporting a 5 MHz maximum RF bandwidth to acquire and access the system while potentially allocating +10 to -10 MHz carrier frequencies to other WTRUs supporting channel bandwidths up to 20 MHz.

[0096] Figure 3 is an example of flexible spectrum allocation. Figure 3 An example of spectrum allocation is shown, where different subcarriers can be assigned (e.g., at least conceptually) to different operating modes (hereinafter referred to as spectrum operating modes or SOMs). Different SOMs can be used to meet different requirements for different transmissions. The SOM may include subcarrier spacing, TTI length and / or one or more reliability aspects (e.g., HARQ processing aspects, auxiliary control channels). The SOM can be used to refer to (e.g., a specific) waveform or can be related to processing aspects (e.g., supporting the coexistence of different waveforms in the same carrier using FDM and / or TDM or the coexistence of FDD operation in a TDD band (e.g., supported in a TDM manner or similar manner)).

[0097] The 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 a specific TTI duration, a specific initial power level, a specific HARQ processing type, a specific upper bound for successful HARQ reception / transmission, a specific transmission mode, a specific physical channel (uplink or downlink), a specific waveform type, or even a transmission according to a specific RAT (e.g., LTE or according to 5G transmission technology). The SOM may correspond to a QoS level and / or related aspects (e.g., maximum / target latency, maximum / target BLER, or the like). The SOM may correspond to a spectrum region and / or a specific control channel or aspect thereof (e.g., a search space or DCI type). For example, the WTRU may be configured with SOMs for URC type services, LLC type services, and / or MBB type services. The WTRU may have a configuration of a SOM for transmission / reception of system access and / or L3 control signaling (e.g., RRC), for example, in a portion of the spectrum associated with the system, for example, in the nominal system bandwidth.

[0098] Spectrum aggregation may be supported (e.g., for single carrier operation). The WTRU may support transmission and reception of multiple transport blocks on a contiguous or non-contiguous set of physical resource blocks (PRBs) (e.g., 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 different SOM requirements.

[0099] Multi-carrier operation may be supported, for example, using contiguous or non-contiguous spectrum blocks within the same operating band or across two or more operating bands. Spectrum block aggregation may be supported using different modes (e.g., FDD and TDD) and / or different channel access methods (e.g., licensed and unlicensed band operation below 6 GHz). Support may be provided for the process of configuring, reconfiguring, and / or dynamically changing the multi-carrier aggregation of a WTRU.

[0100] Downlink (DL) and uplink (UL) transmissions may be organized into radio frames, which may be characterized by a number of fixed aspects (eg, location of downlink control information) and a number of varying aspects (eg, transmission timing, supported transmission types).

[0101] A basic time interval (BTI) may be represented by an integer number of one or more symbols, the symbol duration of which may be a function of the subcarrier spacing applicable to the time-frequency resources. The subcarrier spacing (e.g., for FDD) may be a function of the subcarrier spacing (e.g., for FDD) for a given frame on the uplink carrier frequency f UL and the downlink carrier frequency f DL The rooms are different.

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

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

[0104] A frame can be from a fixed time duration t dci The downlink control information (DCI) starts at the carrier frequency considered (f for TDD). UL+DL , for FDD it is f DL ) before downlink data transmission (DL TRx).

[0105] A frame may (e.g. for TDD duplexing) include a downlink portion (DCI and DL TRx) and (e.g. optionally) an uplink portion (UL TRx). A switching gap (swg) may (e.g. for a given configured frame) precede the uplink portion (e.g. when present) of the frame.

[0106] A frame may (eg, for TDD duplexing) include a downlink reference TTI and one or more TTIs (eg, for uplink). An offset (t offset ) to get the start of the uplink TTI.

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

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

[0109] Figure 4 and Figure 5 An example of a frame structure is provided. Figure 4 is an example of the timing relationship for TDD duplex. Figure 5 is an example of the timing relationship for FDD duplex.

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

[0111] Network based scheduling may enable the network to closely manage the available radio resources assigned to different WTRUs, which may allow for optimal sharing of resources.Dynamic scheduling may be supported.

[0112] WTRU-based scheduling may enable the WTRU to access uplink resources on demand with minimal latency, for example, within a set of shared or dedicated uplink resources assigned by the network (e.g., statically or dynamically). Support may be provided for synchronous and asynchronous transmissions. Support may be provided for contention-based transmissions and contention-free transmissions.

[0113] Support for opportunistic transmissions (e.g., scheduled or unscheduled) may be provided, for example to meet the ultra-low latency requirements of 5G and the power saving requirements of mMTC.

[0114] 5gFLEX can support one or more forms of association between data available for transmission and resources available for uplink transmission. For example, it can support multiplexing of data with different QoS requirements within the same transmission block when the multiplexing does not negatively impact the service with the most stringent QoS requirements and does not cause unnecessary waste of system resources.

[0115] A variety of different encoding methods may be used to encode the transmission. Different encoding methods may have different characteristics.

[0116] For example, the encoding method may generate a sequence of information units. (E.g., each) information unit or block may be self-contained. For example, an error in the transmission of a first block does not impair the ability of a receiver to successfully decode the second block, for example, when the second block is error-free and / or when sufficient redundancy is found in the second block or in a different block for successful decoding of at least a portion thereof.

[0117] Examples of coding techniques may include raptor / base codes, for example where a transmission may include a sequence of N raptor codes. One or more codes may be mapped to one or more transmission "symbols" in time. A "symbol" may correspond to one or more sets of information bits, such as one or more octets. Coding may be used to add FEC to a transmission, for example where a transmission may use N+1 or N+2 raptor codes or symbols (e.g., assuming a raptor code-symbol relationship). A transmission may be more resilient to the loss of a "symbol", for example due to interference or puncture of another transmission that overlaps in time.

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

[0119] The WTRU may be configured with a list of one or more items. The list may be referred to as an access table. The list may be indexed, for example, where (e.g., each) item may be associated with a system signature and / or associated with a sequence thereof. The access table may provide initial access parameters for one or more areas. (e.g., each) item may provide one or more parameters necessary to perform initial access to the system. The parameters may include at least one of: a set 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 physical layer resource for receiving a response. The parameters may (e.g., also) include access restrictions (e.g., PLMN identification and / or CSG information). The parameters may (e.g., also) include routing related information, such as one or more applicable routing areas. The items may be associated with (and / or indexed by) the system signature. Such items may be common to multiple nodes (or TRPs). The WTRU may receive the access table, for example, via a transmission using dedicated resources (e.g., configured by RRC) and / or by a transmission using broadcast resources. In the latter case, the periodicity of transmission of the access table may be relatively long (eg up to 10240 ms), which may be longer than the periodicity of transmission of the signature (eg in the range of 100 ms).

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

[0121] The WTRU may be configured to determine a relationship between different data units. The relationship may be based on a matching function (e.g., based on the configuration of one or more field values ​​that are 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 parameter tuple of fields of an IP header of the data unit, such as IP source / destination address, transport protocol source / destination port and transport protocol type, IP protocol version (e.g., IPv4 or IPv6), etc.

[0122] For example, data units that are part of the same logical association may share a common radio bearer, processing functionality, SOM, and / or may (eg, at least conceptually) correspond to the same LCH and / or LCG.

[0123] A Logical Channel Group (LCG) may include a group of LCHs (or equivalents as per definition above), for example where 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 may be associated with the same SOM (or type thereof), the same slice (or type thereof). For example, the association may be characterized as at least one of: a linking of processing functions, an applicable physical data (and / or control) channel (or instance thereof), or an instantiation of a protocol stack, which may include (i) a particular portion being centralized (e.g., anything outside of PDCP or RF) and (ii) another portion being closer to the edge potentially separated by a fronthaul interface (e.g., MAC / PHY in TRP or RF). The term LCG used herein may have a different and / or broader meaning than similar terms for LTE systems.

[0124] A transport channel (TrCH) may include a specific set of processing steps and / or a specific set of functions used for data information that may affect one or more transmission characteristics over the radio interface.

[0125] LTE may define multiple types of TrCHs, such as a broadcast channel (BCH), a paging channel (PCH), a downlink shared channel (DL-SCH), a multicast channel (MCH), an uplink shared channel (UL-SCH), and a random access channel (which may not carry user plane data). Transport channels for carrying user plane data may include DL-SCH and UL-SCH for downlink and uplink, respectively.

[0126] The air interface for 5G systems may support an enhanced set of requirements. Support may be provided for multiple transport channels, for example for user and / or control plane data, for one or more WTRU devices. The term TrCH used here 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 uplink transmissions (e.g., UL-URLLCH, UL-MBBCH, and UL-MTCCH).

[0127] In one example, multiple TrCHs may be mapped to different sets of physical resources (e.g., PhCHs) belonging to the same SOM. This may, for example, be useful for supporting simultaneous transmission of traffic with different requirements on the same SOM. An example of this may be the simultaneous transmission of URLLCH and MTCCH when the WTRU is configured with a single SOM.

[0128] The 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 implement. 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., time to live (TTL) - for a packet, which represents a time before which the packet should be transmitted to meet, acknowledged, etc. to meet latency requirements), rate-related aspects, and configuration-related aspects (e.g., absolute priority). The parameters may (e.g., may also) vary with the time at which a packet or data may be pending for transmission.

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

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

[0131] The process may optimize the creation and assembly of layer 2 protocol data units (eg, MAC PDUs).

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

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

[0134] The WTRU may use parameters to influence how data is transmitted 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 data should be transmitted. The characterization may represent constraints and / or requirements that the WTRU is expected to meet and / or perform. The WTRU may perform different operations and / or adjust its behavior, for example, based on a state associated with data based on the characterization.

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

[0136] The procedures described herein may be used in whole or in part, alone or in combination with any other procedures, whether or not so described herein.One or more of the example procedures described herein may be performed or applied in part or in whole on a network or WTRU.

[0137] Procedures may be provided for determining PHY layer parameters prior to a grant. For example, a WTRU may determine or be configured with PHY layer parameters for data transmission prior to receiving a grant for an UL transmission. Determining the parameters early may allow certain PHY layer processing to be performed by the WTRU prior to an UL grant, which may be advantageous in allowing the WTRU to perform an UL transmission with minimal delay from the transmission of an UL grant for certain types of data, e.g., to minimize latency associated with the UL transmission. Determining the PHY layer parameters early may be used, e.g., also in conjunction with other procedures described herein.

[0138] The PHY layer parameters determined prior to a grant may be applied to a specific logical channel, transport channel, traffic type, or SOM. The parameters configured or provided to the WTRU prior to receipt of a grant may include, for example, one or more of the following: a modulation scheme to be applied to the data, a coding scheme and coding related parameters, HARQ related parameters (e.g., characteristics of the HARQ or type of HARQ process to be used), a transport block size, rules for associating L2 data to specific PHY resources (e.g., a PHY resource or a range of PHY resources that may be used to transmit a specific resource), a PHY resource or a superset of PHY resources associated with the final grant. The PHY layer information may be a superset of resources that may be completed by the grant itself.

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

[0140] The WTRU may receive PHY layer parameters from the network. The parameters may be received periodically or in response to one or more triggers. 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) by request from the WTRU and / or (iii) when the WTRU initiates a service or logical channel, bearer, etc., which may require the WTRU to have early access to the PHY layer parameters.

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

[0142] The WTRU may (eg, also) indicate to the network when an event such as one or more of the above events occurs.

[0143] The MCS may be received and used for subsequent grants. In an example implementation, the WTRU may periodically receive an MCS to be used to transmit data on a portion of a transmit bandwidth. This may, for example, be limited to a set of predefined transport blocks or similar (e.g., a predefined frequency range). The WTRU may (e.g., upon receiving a periodic MCS transmission) apply the signaled MCS to (e.g., all) transmissions made on 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 an initially signaled bandwidth range and the (resulting) MCS. For example, the WTRU may determine that an MCS may be provided for a set of logical channels. The WTRU may map these logical channels to the portion of the bandwidth for which the MCS has been signaled.

[0144] The periodic transmission of the MCS may be delivered to the WTRU, for example, by dedicated signaling on a PHY channel, by a MACCE or similar communication, or via RRC signaling. The WTRU may use the MCS after the transmission, for example, until it receives a new or updated MCS value for the same bandwidth region. The WTRU may receive multiple different MCS values, for example, for different bandwidth regions. The WTRU may receive an MCS for (e.g., only for) certain bandwidth regions.

[0145] The WTRU may receive a subset of resources from which a grant may (e.g., subsequently) select. For example, the WTRU may receive a range of resources within its transmission bandwidth. The resource range may be used, for example, to indicate to the WTRU a set of resources from which the WTRU is required to transmit when a grant arrives. The frequency range indicated by the PHY layer parameter may identify a set of resource blocks, a set of subframes, a TTI, or symbols available during the validity time of the PHY layer parameter, or a combination thereof. The grant may indicate to the WTRU specific resources within the initial resource range. For example, the PHY layer parameter may select x resource blocks that may be used by the WTRU for each TTI. The UL grant may indicate to the WTRU one or more of these x resource blocks to be used by the WTRU to satisfy the grant.

[0146] An advantage of this technique may be reduced latency associated with decoding of a grant, for example given that the portion of the resource indicated by the grant is known a priori in PHY layer information previously received by the WTRU.

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

[0148] The network may configure (eg, dynamically or semi-statically) a frequency range for the WTRU, which the WTRU may (eg, must) use to define its own set of PHY layer parameters.

[0149] The WTRU may periodically determine its PHY layer parameters, for example based on measurements for a frequency range or set of frequency ranges. The WTRU may associate the PHY layer parameters to be applied to a transmission on any resource for which the WTRU may receive a grant.

[0150] The frequency ranges used by the WTRU to determine parameters may be dynamically configured by the network. For example, the network may configure the WTRU to perform the above measurements and calculations of the MCS for (e.g., only) frequency ranges A and B, where A and B may be subsets of the entire frequency. The WTRU may apply MCS A to uplink transmissions performed on frequency range A, and may apply MCS B to uplink transmissions performed on frequency range B.

[0151] The network may configure, for example, through RRC signaling, a frequency range for which the WTRU may perform its own PHY layer parameter determination. The configuration may be changed to an updated configuration. For example, the network may use a frequency range with optimal channel characteristics for URLLC transmission at any given time. The network may dynamically reconfigure a frequency range for which the WTRU may perform its own PHY layer parameter determination.

[0152] The WTRU may signal PHY layer parameters. For example, the WTRU may signal to the network PHY layer parameters that the WTRU autonomously selects. The WTRU may signal the parameters, for example, during or in response to one or more of the following: (i) when selecting / determining the parameters, (ii) during transmission of data using the parameters, in which case the WTRU may signal the parameters explicitly in control information and / or implicitly based on attributes of the transmitted data that imply a particular selection of the use of the control parameters, (iii) upon network request and / or (iv) when the network provides resources for transmission of data or control that may or may not be planned for transmission of these parameters.

[0153] The WTRU may (eg, 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.

[0154] 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 may or will use for a later transmission. For example, the WTRU may prepare a collection of data blocks and prepare for transmission. The WTRU may (e.g., also) have combined data blocks into transport blocks. The WTRU may provide the data block size and / or TB size in a SR, BSR or RA transmitted to the network.

[0155] The WTRU may indicate a process size or TB size for a data block, for example to allow signaling to be sent with lower overhead. For example, the set of TB sizes that may be signaled by the WTRU may be limited to x levels. The signaling may be sent with a limited number of bits, which may allow the WTRU to signal one of the x levels. For example, the WTRU may signal the next TB size larger than x when it wishes to transmit a TB of size x.

[0156] 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 this). The WTRU may select its transport block size, for example, based on the number of available fixed-size MAC PDUs to be transmitted and the size of the resource grant. The WTRU may determine the MCS, for example, using the process described herein. The WTRU may signal its MCS to the network (e.g., explicitly), for example, based on one or more processes described herein. The transport block size used by the WTRU may be indicated (e.g., implicitly) as part of the CRC check value of one or more individual MAC PDUs within the transport block, for example. The WTRU may, for example, insert padding into (e.g., each) fixed-size MAC PDU to obtain a CRC check value that implicitly indicates (e.g., to the network) the total transport block size used or is selected from one of the allowed transport block sizes. In one example, the CRC check value may implicitly signal the WTRU's selection of a first transport block size, for example, when the CRC check value of the first coded block transmitted is divisible by a value. The CRC check value may implicitly signal the WTRU's selection of a second transport block size, etc., for example, when the CRC check value of the transmitted first coded block is divisible by another value.

[0157] MAC PDUs / transport blocks may be created incrementally. TBs may be created from fixed data block sizes. This may provide performance advantages over RLC segmentation, assembly, MAC layer multiplexing, and PHY layer encoding after receiving a grant. The latency of a grant for UL transmission may not be improved beyond the hardware and software latency of these operations.

[0158] For example, the WTRU may perform incremental creation of transport blocks by assembly of fixed-size data blocks. The WTRU may perform creation of data blocks by creating fixed-size data blocks as data arrives in the WTRU buffer as higher layer data arrives, immediately or without waiting for information in a grant from the network. The WTRU may create a TB, for example, by allocating multiple data blocks to the TB to occupy a grant of that size. The WTRU may (e.g., also) be given a grant that may be a multiple of the 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 occupy any remaining data, for example, with one or more of the following: (i) padding; (ii) MAC control information, such as information about required resources, pending MAC PDUs to be transmitted, MAC PDU size, indication of packets with an end TTL, etc., and / or (iii) additional coding, speed matching, etc. that may be inserted by the PHY layer.

[0159] The WTRU may be configured to use (e.g., one) or a limited set of specific data block sizes for specific flows, bearers, logical channels, etc. The WTRU may (e.g., also) be restricted to use 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 use a specific data block size for data associated with URLLC or flows with QoS characteristics associated with URLLC, but may create data blocks with no restrictions on the size for other flows or data.

[0160] The data blocks may include, for example, RLC PDUs or PDUs associated with different protocol layers (MAC, PDCP, etc.).

[0161] The configured data block size may be, for example, statically configured in the WTRU or signaled by the network. The WTRU may receive a set of allowed data block sizes, for example periodically or aperiodically, for example based on changes in channel conditions determined by the network. The data block size may be signaled to the WTRU, for example, via broadcast or dedicated signaling (e.g., part of RRC signaling in a MAC configuration).

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

[0163] The WTRU may derive the fixed data block size to be used, for example, based on PHY layer information that may be provided prior to grant. For example, the WTRU may calculate the allowed data block size based on one or more of the PHY layer parameters, such as the parameters described herein. For example, the WTRU may determine that the data block size is equal to the coded block size provided as part of the PHY layer parameters indicated prior to grant.

[0164] The WTRU may select one or more data block sizes from a set of allowed sizes to be used for each data block created (e.g., independently). The data block size may be selected for one or more reasons, such as to accommodate the type of traffic at a higher layer, based on the size of packets received in a recent time period, the buffering capacity of the WTRU, and / or other implementation-related aspects. The WTRU may (e.g., alternatively) select the data block size to be used for a particular flow, logical channel, etc. from a list of allowed sizes. The WTRU may continue to use the selected data block size for the same flow, logical channel, etc. for a limited time period. The WTRU may (e.g., also) perform the selection upon the occurrence of other triggers, such as one or more of the following: (i) the arrival of new types of data, (ii) the next receipt of a new set of data block sizes, (iii) the end of a frame / superframe or similarly 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, (vi) upon receipt of a new configuration from the network (e.g., a change in frequency, HARQ parameters, PHY configuration, etc.).

[0165] The WTRU may perform segmentation / reassembly of higher layer SDUs (e.g., IP packets or PDCP SDUs), for example, prior to an uplink grant for transmission of associated data. Segmentation / reassembly of one or more packets that 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) the arrival of a packet or SDU that may be tagged to a particular flow or associated with a particular logical channel, (ii) when the TTL of a particular packet or SDU becomes less than a threshold, and / or (iii) upon the arrival of one or more SDUs where the total amount of data available for segmentation / reassembly is greater than a minimum size. For example, the minimum size may correspond to an allowed data block size or a data block size selected by the WTRU.

[0166] The WTRU may perform segmentation / reassembly of the SDU upon receiving a higher layer SUD, for example, whereby the resulting segments may have fixed and selected data block sizes. The WTRU may insert padding into the data blocks (e.g., during segmentation / reassembly), for example, when (e.g., all) data in the buffer is consumed during data block creation and does not occupy an integral number of fixed-size data blocks.

[0167] The WTRU may select a data block size (e.g., from a list of allowed data block sizes), for example, which is closest in size to a higher layer SDU that may be received or to minimize inserted padding. In one example, the WTRU may select a data block size (e.g., from a list of allowed sizes) that minimizes padding, for example, when a single RLC packet associated with a particular buffer or flow may be (e.g., is) present in the WTRU when performing data block creation.

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

[0169] A data block may or may not contain a header. A single header may be contained in an entire transport block, which contains multiple data blocks. The header may contain, for example, one or more of the following: (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 stream, logical channel or service associated with (e.g., each) data block and / or (iv) the amount of control information (e.g., MAC CE) contained in the transport block.

[0170] The WTRU may include (eg, in the TB currently being transmitted) information such as the size of a pending TB to be transmitted or ready to be transmitted by the WTRU. For example, this information may be included in a MAC CE transmitted as part of the current TB being transmitted.

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

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

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

[0174] The WTRU may (e.g., upon receiving a grant) perform, for example, one or more of the following actions: (i) multiplexing and transport block creation, (ii) insertion of padding bits into (e.g., each) fixed-size data block or the entire transport block, (iii) creation or updating of one or more data block headers to include information received with the grant, such as the number of data blocks in a TB, (iv) creation of a data block header, and / or (v) additional PHY layer processing of (e.g., each) data block or the entire transport block.

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

[0176] MAC multiplexing may occur, for example, based on TTL. For example, the WTRU may insert all data blocks in increasing order of TTL.

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

[0178] MAC multiplexing may occur, for example, based on the relationship between data blocks. For example, the WTRU may perform selection of data blocks based on a predefined relationship between data blocks indicated as part of the QoS. For example, some data blocks may be formed from the same IP or PDCP packet. The WTRU may include related data blocks within the same transport block, for example due to an indication of a preference or requirement from the QoS information.

[0179] MAC multiplexing may occur, for example, according to restrictions on the allowable QoS in the grant. For example, the WTRU may perform selection of data blocks by selecting data blocks that are associated with (e.g., only) a single flow, logical channel, or service or a restricted set thereof. The association may be determined in the grant or may be known a priori in the WTRU, for example based on characteristics of the grant regarding PHY layer parameters or data block size (which is signaled to the WTRU prior to the grant).

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

[0181] The difference between the TB size and the granted size may be minimized. For example, the WTRU may select available data blocks such that the difference between the granted size and the TB size may be minimized. A combination of available data blocks for transmission that results in such a minimized difference may be used.

[0182] The WTRU may use selection criteria, such as whether it creates fixed-size data blocks or whether the size of the data blocks is dynamically adjusted (eg, as grants arrive).

[0183] 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. A transport block may carry its own CRC, which may be referred to as a TB CRC. The encoder may be configured to insert a smaller length CRC into (e.g., each) coded block, e.g., to achieve power savings by early detection of decoding failures.

[0184] A transport block (TB) NACK may occur, for example, when a preconfigured ratio or number of data blocks are erroneous. The network may receive a transport block (e.g., all associated data blocks) without error (e.g., correctly), in which case it may be configured to transmit an ACK to the WTRU on a dedicated control channel. The network may detect errors associated with a transport block (e.g., due to erroneous reception of one or more of the data blocks). The network may be configured to determine whether to transmit an ACK or a NACK (e.g., a HARQ-ACK) to the associated TB transmission, for example, depending on the number of erroneous data blocks in the transport block. For example, a base station or TRP may be configured (e.g., via another instance in the network or via OAM) to transmit a NACK when more than a certain number or ratio of data blocks are erroneous. For example, a TRP may be configured to transmit a NACK when more than 50% of the data blocks are erroneous. The motivation may be to (e.g., only) trigger HARQ retransmissions when (e.g., statistically) it is expected that there may be a HARQ combining gain. Otherwise, it may be more advantageous to retransmit (e.g., only) the erroneous data blocks, e.g., at the expense of additional feedback signaling or additional delay (e.g., letting the RLC or ARQ entity handle the error case). The WTRU may (e.g., also or alternatively) be configured (e.g., as a special case) to transmit a HARQ-NACK when (e.g., only) one data block is erroneous. The special case may represent an ACK or NACK for the entire TB.

[0185] One or more of the example procedures described herein may be performed or applied in part or in whole at the network or WTRU, for example when the network transmits a plurality of data blocks to the WTRU. The WTRU may be configured with a ratio or number of erroneous data blocks above which the WTRU transmits a HARQ-NACK.

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

[0187] The aggregate data block Ack / Nack message may include one or more Ack / Nack fields (e.g., 1-bit fields). The (e.g., each) field may correspond to a (e.g., one) data block in the associated uplink transmission. The aggregate data block ACK / NACK message may be transmitted by the TRP, for example, via predefined dedicated resources. The WTRU may determine the size of the aggregate data block Ack / Nack message, for example, based on an associated uplink grant (e.g., with an implicit time association between the UL grant and the DL feedback). In (e.g., another) example, the TRP may transmit the aggregate data block Ack / Nack message on a resource set associated with the resources of the associated UL transmission.

[0188] In one example, the TRP may schedule the aggregate data block Ack / Nack message along with the UL grant. For example, the TRP may indicate the resources of the aggregate data block Ack / Nack message that may occur at a later time. In one example, the WTRU may be configured to transmit the aggregate data block Ack / Nack message (e.g., only) when scheduled by the TRP.

[0189] In one example, a similar approach described for the uplink may be applied to the downlink. The TRP may be configured to transmit multiple data blocks in a transport block. The WTRU may be configured to transmit an aggregate data block Ack / Nack message. The WTRU may be scheduled in a DCI associated with an associated transmission for or required to be used for an aggregate data block Ack / Nack message. The WTRU may receive an aggregate data block Ack / Nack message grant and may transmit the grant on associated resources. The WTRU may be configured not to transmit an aggregate data block Ack / Nack message, for example, when the DCI is not scheduled. The network may (e.g., alternatively) configure a set of resources dedicated to aggregate data block Ack / Nack transmissions.

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

[0191] The size of the Aggregate Data Block Ack / Nack message may be variable between TTIs, although its size may be known to the network, for example due to scheduling grants.The WTRU may be configured with a suitable format to transmit the Aggregate Data Block Ack / Nack message, for example after the associated DCI.

[0192] For example, flexible grant sizes may be allowed when meeting the requirements for assembling a PDU prior to receiving a grant. For example, a WTRU that performs MAC PDU assembly prior to grant assignment may flexibly use one or more grants obtained to tailor the assembled MACK PDU. The WTRU may (e.g., autonomously) determine the number of grants or the size of each grant required to transmit the assembled MAC PDU.

[0193] A grant may last for multiple consecutive TTIs. For example, a WTRU may be assigned a grant that lasts for multiple TTIs, multiple subframes, multiple frequency blocks, or a combination thereof. A grant may be defined, for example, whereby a portion of a grant over a given TTI, subframe, frequency block, etc. may be a unit portion of the entire grant. The WTRU may use a subset or multiple units of a grant and may provide an indication to the network indicating if and when it has completed use of a grant, for example to allow the network to determine the total size of a transport block being transmitted.

[0194] In one example, a WTRU may receive a grant of x resource blocks that may be repeated 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., alternately) change from one TTI to the next, for example, to provide frequency diversity. The x resources may change from one TTI to the next, for example, according to one or more of: (i) a fixed rule known to the WTRU (e.g., [resBlock X+m] mod BW); (ii) a rule indicated in the grant itself; (iii) a rule defined prior to the grant using broadcast or dedicated signaling and / or (iv) a rule specific to the cell or TRP to which the WTRU is connected, and which may potentially be provided via an access table or similar system information specific to the system signature.

[0195] In one example, the value of y may not be defined and the grant may last indefinitely until indicated by the WTRU.

[0196] The WTRU may, for example, upon receiving a grant, perform PHY layer coding and modulation of the MAC PDU to be assembled according to the modulation and coding provided in the grant. The WTRU may receive (e.g., a single) modulation and coding to be used throughout the grant. The WTRU may (e.g., alternatively) receive different coding or modulation parameters for each TTI associated with the grant.

[0197] The WTRU may, for example, insert padding or additional redundant control information or data in the MAC PDU before starting the encoding process, for example to ensure that the resulting coded and modulated PDU (e.g., completely) occupies an integer number of granted units (e.g., resources granted in M ​​consecutive TTIs).

[0198] The WTRU may indicate the end / size of a transport block (TB) to the network. For example, the WTRU may indicate to the network, for example at any time during or after a grant process, the number of consecutive TTIs that it may (e.g., will) use and (e.g., therefore) the end of a transport block, for example to inform the network of the size of the transport block being transmitted. The WTRU may indicate the end of a transport block to the network, for example, using one of the following procedures: (i) the WTRU may indicate the number of TTIs used for 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 used for the network using a MAC CE provided as part of the transport block; (iii) the WTRU may transmit a special signal indicating the end of transmission, for example, in part of the resources of the last TTI and / or (iv) the WTRU may perform padding at the PHY layer or subdivide the MAC PDU into multiple blocks whereby one or more block CRCs may have a CRC value indicating the number of TTIs used to transmit the transport block.

[0199] The WTRU may decide to combine separate grants to transmit a single TB. For example, the WTRU may select two or more UL grants for transmitting a single TB. The WTRU may decide to combine these grants to transmit a single TB, for example, after receiving multiple grants in the same subframe or TTI.

[0200] The WTRU, for example, after being provided with separate grants with potentially different transmission parameters (e.g., MCS, coding, power, etc.), may select a parameter set associated with one of the grants, for example, to perform modulation and coding on the entire TB, for example, if it causes the TB to be transmitted over the entire set of resources. For example, the WTRU may select the grant that results in the fewest total data bits transmitted, for example, to allow it to transmit the TB to the associated grant. For example, the WTRU may include control (e.g., MAC CE, which may include buffer status), padding, and / or additional coding when the resulting coded TB after the WTRU makes the selection does not completely occupy the entire set of resources.

[0201] The WTRU may not need to indicate the selected transmission parameters for performing a 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 selected for the transmission parameters. An association between the indicated index and the grant may be defined, for example, using a static rule. For example, a licensed reference resource in the lowest frequency range may be associated with the lowest frequency range. The WTRU may (e.g., alternatively) provide attributes associated with the grant itself in PHY layer signaling. For example, the WTRU may provide a modulation index for a grant whose transmission parameters may (e.g., will) be used to transmit the entire grant.

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

[0203] For example, the WTRU may be provided with resources for an eventual retransmission (e.g., in the event of a transmission failure) either explicitly or implicitly. The WTRU may indicate this to the network (e.g., when the TB occupies more resources than provided for the initial transmission), for example, by using one or more of the procedures described herein for UL indication.

[0204] 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 used for the initial transmission. The WTRU may transmit the remaining portion of the resources of the TB block (e.g., when 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.

[0205] For example, when the transmission and retransmission of a TB on multiple resources associated with the UL fails, the WTRU may perform retransmission of the TB on a new resource or resource set scheduled by the network. For example, when the size of a single grant can fit the size of the TB, the WTRU may retransmit the entire TB on the single grant provided by the network.

[0206] The WTRU may send an indication to allocate more resources for a complete TB transmission. For example, the WTRU may transmit a portion of a TB in a grant provided by the network and may provide an indication to the network that the entire transmission was not transmitted. The indication may (e.g., also) provide the remaining size of the TB. The WTRU may perform the transmission of the remaining portion of the TB when the network provides the grant. The grant may (e.g., inter alia) be dedicated to addressing the remaining data associated with the transport block.

[0207] Early generation of transport blocks is possible. In one example, the WTRU may be allowed to generate one or more transport blocks (or MAC PDUs) prior to receiving signaling allowing transmission of one or more transport blocks in specific resources, where the signaling may include a grant received from downlink control information. Pre-generation may be possible, for example, when used in conjunction with variable transmission duration.

[0208] In one example, one or more applicable transmission parameters for physical layer processing of a MAC PDU may be determined, for example, when creating a MAC PDU (e.g., before receiving a grant). For example, the WTRU may determine a coding scheme and / or coding rate applicable to a pre-generated MAC PDU for a given transport channel, for example, based on an indication received from the physical layer, MAC, or RRC signaling before receiving a grant. For example, as part of a grant, one or more remaining applicable transmission parameters for physical layer processing may be signaled. For example, the WTRU may determine a modulation scheme (e.g., QPSK or 16-QAM) based on information received from a grant. For example, a grant may (e.g., explicitly) indicate a modulation scheme. A grant may (e.g., alternatively) indicate a duration and / or frequency allocation for transmission. The WTRU may implicitly derive a modulation scheme that may (e.g., needs to) be applied to fit (e.g., all) coded bits in the indicated duration and / or frequency allocation.

[0209] The WTRU may determine the size of the MAC PDU, for example, based on one or more of the following schemes: (i) based on an explicit indication and / or (ii) based on a target duration and / or a most recently used set of transmission parameters.

[0210] In one example, the size may be determined based on explicit indications from physical layer, MAC or RRC signaling, such as potentially for each type of service or transport block. For example, the WTRU may be signaled that the MAC PDU size for a first transport channel is 3000 bits and the MAC PDU size for a second transport channel is 10000 bits.

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

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

[0213] The target duration for transmission may be determined, for example, based on 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 set the size of the MAC PDU, for example, such that the duration for transmission of the MAC PDU may (e.g., would) match or approximately match the target duration to the adopted set of transmission parameters. This approach may ensure that the (e.g., required or maximum) duration of transmission of the MAC PDU remains relatively close to the target, even though other transmission parameters applicable to the transmission of the MAC PDU may differ from the adopted set of transmission parameters (e.g., due to changing radio conditions).

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

[0215] In one example, the second threshold may be predefined or obtained from physical layer, MAC or RRC signaling. The threshold may (e.g., alternatively) be based on the amount of data that can be transmitted within a target duration of the adopted transmission parameter set. The adopted transmission parameter set may be obtained, for example, according to one or more techniques described herein. In one example, the WTRU may pregenerate a new MAC PDU, for example, when the total duration required to transmit (e.g., all) unprocessed pre-generated MAC PDUs does not exceed a threshold (e.g., 5 ms). The target duration may, for example, be predefined or obtained from physical layer, MAC or RRC signaling.

[0216] A pre-generated MAC PDU may be transmitted. For example, the WTRU may receive signaling (e.g., a grant) allowing one or more MAC PDUs to be transmitted in a resource. For example, when the WTRU operates in an unlicensed band, the transmission may be conditional, such as based on a clear channel assessment condition. For example, one or more MAC PDUs may have been pre-generated according to one or more techniques described herein.

[0217] The WTRU may receive one or more transmission parameters, such as one or more of a frequency allocation, a modulation scheme, a coding scheme, and / or a rate or number of spatial layers. One or more parameters may have been provided prior to the signaling allowing the transmission of the MAC PDU. The WTRU may determine a required transmission duration, such as whereby a sufficient number of resource elements are available to map the modulation symbols. The 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.

[0218] In one example, the WTRU may transmit control information to assist a receiver in determining the duration of a transmission. For example, the WTRU may provide an indication of the duration expressed as a number of time units (e.g., symbols or subframes) encoded in uplink or sidelink control information (e.g., in a scheduling assignment). In (e.g., another example), the WTRU may provide an indication in a (e.g., last or after last) symbol of the transmission indicating that the transmission is not continuing. In (e.g., another) example, the WTRU may multiplex control information in a predefined resource that occurs in (e.g., every) time unit (e.g., every subframe) indicating whether the transmission is continuing in a subsequent time unit.

[0219] The WTRU may receive a maximum transmission duration, for example, as part of a grant or from previous signaling. The WTRU may, for example, when the transmission duration for a MAC PDU may (e.g., would) exceed a maximum value, perform one or more of the following, for example: (i) discard the MAC PDU; (ii) transmit an indication that the maximum transmission duration is too small for transmission of the MAC PDU, wherein the indication may, for example, be encoded as physical control information or MAC signaling in a MAC PDU created for this purpose and / or (iii) modify at least one transmission parameter, such as a coding scheme, coding rate, or modulation scheme, for example, compared to the signaled transmission parameter, for example, so that the total required duration does not exceed the maximum value. In one example, the WTRU may use 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 a number of coded bits. The WTRU may, for example, transmit an indication of whether the modification is applied and / or the value of the modification in an uplink or sidelink control information.

[0220] A minimum guaranteed TBS may be provided. For example, the WTRU may be configured with a minimum guaranteed TBS. For example, the configuration may be received via an RRC or MAC CE. The configuration may be applicable to (e.g., a specific) data unit, for example based on a data type, a logical association (e.g., associated with a data flow, an LCH, an LCG, a corresponding SOM, a corresponding service, a group of these, etc.). The WTRU may be configured to, for example, allow it to perform one or more processing steps, for example, for creating a MAC PDU prior to receiving downlink control information and / or prior to finalizing a TBS for an uplink transmission.

[0221] MAC processing may occur before TBS information. For example, the WTRU may perform multiple MAC processing steps before finalizing (e.g., all) transmission parameters such as TBS for transmission and / or for applicable data units (e.g., MAC SDUs). A MAC PDU may include fragments of a data unit (e.g., via RLC segmentation or MAC segmentation).

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

[0223] The WTRU may assemble a MAC PDU for each value (eg, when there are multiple values) of the configured minimum guaranteed TBS (TBSmin). The WTRU may determine the final value (TBSfinal) of the TBS for transmission, for example, based on the received DCI granting uplink resources.

[0224] The TBS may be adapted over time. For example, the WTRU may determine, for example based on received downlink control signaling, a final set of parameters (TBSfinal) for transmissions using a minimum TBS guarantee associated with a single transport block. The received DCI may explicitly indicate a specific data unit to be used for the transmission. The received DCI may indicate a processing time applicable to the transmission, such as whereby the WTRU may be instructed to perform a transmission at time n+xμsec / ms / subframe or some other time unit for a DCI received at time n. In one example, the WTRU may determine the minimum duration of a TB transmission, for example based on a signaled MCS, PRB set, etc., for example using a minimum configured TBS value greater than the TBS obtained from information contained in the DCI signaling. In one example, the WTRU may determine the shortest duration that matches a frame boundary in time (e.g., matches the end of the DL transmission portion of a subframe), which may fit within a minimum configured TBS value greater than the TBS obtained from information contained in the DCI signaling. For example, this is conceptually similar to bundling operations based on implicit (e.g., signaled TBS less than the minimum TBS) or explicit (e.g., indicated in the DCI) indications in time. In one example, the WTRU may perform multi-TTI TB transmission (e.g., a single MAC PDU for applicable data units) or TTI bundling (e.g., for multiple segments, such as RLC or MAC as separate MAC PDUs for applicable data units) for transmission of pre-assembled MAC PDUs. The number of TTIs may be an integer determined based on a guaranteed / configured TBS value (e.g., TBSmin) and a TBS value obtained from information in the DCI.

[0225] The WTRU may (e.g., when the size of TBSfinal is greater than TBSmin) add padding to the pre-assembled MAC PDU, e.g., such that the PDU size matches the value TBSfinal. 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 such that the PDU size matches the value TBSfinal.

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

[0227] The WTRU may include in the uplink transmission an indication of the desired TBS and / or an increase / decrease indication of the TBS, such as a discrete value within a set of configured 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 indicates an index into a pre-configured set of values. The indication may be a request for an increase in processing time.

[0228] The WTRU may use information about determining the minimum guaranteed TBS for the LCH (or its equivalent) from which data may be served for assembly of the MAC PDU. For example, one or more other aspects may be considered according to one or more of the processes described herein, such as latency, keep alive time, PBR, priority, etc.

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

[0230] The network (NW) may configure one or more minimum TBSs (e.g., using the procedures described herein). The WTRU may determine whether padding is included in a received transmission, for example to determine whether the WTRU performs pre-assembly of a MAC PDU and / or cascade. The network may change the TTI duration of a transmission, for example to ensure that a minimum TBS size is available (e.g., all the time), for example even when the radio link and / or HARQ operating point changes. In other words, the network may (also) perform an adaptation of the WTRU transmission of 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 may (e.g., needs to) guarantee a minimum TBS for a particular HARQ operating point for varying link adaptation needs and / or varying link quality. In one example, the DCI may indicate a longer processing time for the WTRU, for example, after receiving an empty MAC PDU (e.g., containing only padding) and / or receiving an indication that the current TBS is insufficient.

[0231] The transmission parameters may be selected, for example, using a blind decoding or DCI reception process.

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

[0233] The one or more parameters may correspond to a parameter set. The WTRU may use a process to determine one or more of a plurality of parameter sets. A set may be a configuration aspect of the WTRU. For example, one or more parameters (e.g., a set) may correspond to a transmission characterized by higher reliability, lower latency, best-effort transmission, or another type of service, such as paging, system information reception, broadcast transmission, etc. A set may correspond to a SOM.

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

[0235] The robustness of the DCI may indicate something about the transmission. For example, the WTRU may determine that the received DCI has been successfully decoded according to one of a plurality of robustness / reliability levels. The WTRU may determine appropriate values ​​for one or more parameters associated with the transmission, such as so that a similar reliability level may be employed for the transmission. For example, the network may determine the explicit / implicit indication to use, such as based on an applicable link adaptation mechanism (e.g., uplink control information and / or channel state indication received from the WTRU).

[0236] The WTRU may determine, for example, a minimum level of robustness and / or QoS level applicable to the transmission based on the determined one or more parameter sets. For example, the WTRU may determine an applicable SOM. The WTRU may (e.g., also) determine data applicable to the UL transmission based on the associated QoS level.

[0237] The WTRU may determine HARQ processing and / or feedback. For example, the WTRU may determine, for example, based on a determined set of one or more parameters, the type of HARQ processing to be applied to a transmission (e.g., in the case of an initial transmission, uplink, or downlink) and / or the type of HARQ feedback for a transmission (e.g., required). For example, the WTRU may determine (e.g., for reception of a DL transmission) (e.g., based on a determined set of parameters) that HARQ feedback is expected in (or within) a certain time interval using a particular transmission process (e.g., an applicable uplink control channel), or that feedback should not be automatically generated (e.g., only generated upon request). For example, the WTRU may determine an applicable SOM and may perform HARQ processing and / or feedback accordingly.

[0238] Robustness may be signaled in a grant. For example, a WTRU may receive signaling (e.g., implicitly or explicitly) in a DCI indicating that a transmission associated with a particular grant may be performed based on a different set of parameters associated with a flow, service type, SOM, etc. For example, a WTRU may receive (e.g., in a grant) an indication that a corresponding transmission may be used for transmission of URLLC data (if any) and may accordingly modify and / or select transmission parameters, for example, to allow for more robust transmissions and / or lower latency.

[0239] For example, the WTRU may perform a similar determination for a DCI scheduling a downlink transmission so that it may appropriately determine parameters for decoding the associated transmission.

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

[0241] The WTRU may be configured for association with a robustness level and / or a set of parameters.

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

[0243] In one example, the WTRU may determine the robustness level based on the size of the CRC for which the DCI is successfully decoded. For example, an 8-bit CRC may indicate the use of a normal robustness level (e.g., a first transmission parameter set) while a 16-bit or 32-bit CRC may indicate the use of a higher robustness level (e.g., a second transmission parameter set).

[0244] The transmission parameters may be selected based on a robustness level. For example, the WTRU may select transmission parameters to be used for an UL transmission associated with a grant based on a 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 processes, such as one or more of the processes described herein. In one example, the selection may, for example, be based on one or more of: (i) physical resources used for uplink transmission (e.g., when the determination of the set of applicable resources corresponding to the transmission is itself irrelevant to the determination); (ii) the type of data being transmitted (e.g., when the data selection is itself irrelevant to the determination); (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).

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

[0246] Disclosed are systems, methods and measures (e.g., aspects of entities, interfaces and processes in WTRU and / or network layers L1, L2, L3) for low-latency MAC PDU assembly in wireless systems such as 5gFLEX. For example, latency can be reduced by the WTRU determining network transmission parameters and signaling before transmitting a grant. The WTRU may receive MCS, resource range, etc. before a grant, for example, for use in a later grant. Data blocks may be incrementally created / encoded before a grant. Data units may be segmented, assembled and multiplexed, for example, based on data block sizes allowed for MAC and RLC processing before a grant. Flexible grant sizes may be provided for early generation of transport blocks before a grant. A minimum guaranteed TBS may be signaled to allow early generation of MAC PDUs. Transmission parameters may be selected before a grant, for example, using a blind decoding or DCI reception process.

[0247] The processes and measures described herein may be used in any combination, may be applied to other wireless technologies, and may be used for other services.

[0248] WTRU may refer to an identity of a physical device, or an identity of a user, such as a subscription-related identity, such as an MSISDN, SIP URI, etc. WTRU may refer to an application-based identity, such as a user name that may be used per application.

[0249] Each of the computing systems described herein may have one or more computer processors with 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., WTRU and network) to implement the functions. The above-described processes may be implemented in the form of a computer program, software, and / or firmware integrated into a computer-readable medium for execution by a computer and / or processor.

[0250] The above process may be implemented in a computer program, software or firmware incorporated into a computer-readable storage medium for execution by a computer or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media such as built-in disks and removable disks, magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, terminal, base station, RNC, and / or any host.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method include: receiving an indication regarding transmission parameters; selecting data based on the indication regarding the transmission parameter; as well as Send the selected data to the network.

2. The method according to claim 1, in, The indication of the transmission parameter is included in downlink control information (DCI).

3. The method according to claim 1, in, The selected data includes hybrid automatic repeat request (HARQ) feedback.

4. The method according to claim 1, include: A priority level associated with the selected data is determined.

5. The method according to claim 1, include: Based at least in part on the indication of the transmission parameter, one or more uplink transmission parameters are determined.

6. The method of claim 5, wherein the one or more uplink transmission parameters include one or more of the following: physical uplink control channel (PUCCH) information, hybrid automatic repeat request (HARQ) information, power control parameters, frame information, transmission timer interval (TTI) information, modulation and coding scheme (MCS), or resource block information.

7. A wireless transmit / receive unit (WTRU), the WTRU comprising a processor, the processor configured to: receiving an indication regarding transmission parameters; selecting data based on the indication of the transmission parameter; and Send the selected data to the network.

8. The WTRU of claim 7, wherein the indication of the transmission parameter is included in downlink control information (DCI).

9. The WTRU of claim 7, wherein the selected data comprises hybrid automatic repeat request (HARQ) feedback.

10. The WTRU of claim 7, wherein the processor is configured to determine a priority level associated with the selected data.

11. The WTRU of claim 7, wherein the processor is configured to determine one or more uplink transmission parameters based at least in part on the indication regarding the transmission parameters.

12. A WTRU according to claim 11, wherein the one or more uplink transmission parameters include one or more of the following: physical uplink control channel (PUCCH) information, hybrid automatic repeat request (HARQ) information, power control parameters, frame information, transmission timer interval (TTI) information, modulation and coding scheme (MCS), or resource block information.

13. A wireless transmit / receive unit (WTRU), the WTRU comprising a processor configured to: determining a first set of one or more transmission parameters and a second set of one or more transmission parameters, in, the first set of one or more transmission parameters being associated with a first type of hybrid automatic repeat request (HARQ) feedback, and the second set of one or more transmission parameters being associated with a second type of HARQ feedback; receiving downlink control information (DCI) for a downlink transmission; determining, based on the DCI, whether to apply the first set of one or more transmission parameters or the second set of one or more transmission parameters; as well as If the DCI indicates that the first set of one or more transmission parameters is applied, the first type of HARQ feedback is sent, or if the DCI indicates that the second set of one or more transmission parameters is applied, the second type of HARQ feedback is sent.

14. The WTRU of claim 13, wherein the first set of one or more transmission parameters corresponds to a first robustness level and the second set of one or more transmission parameters corresponds to a second robustness level.

15. A wireless transmit / receive unit (WTRU), the WTRU comprising a processor, the processor configured to: determining a first set of one or more transmission parameters and a second set of one or more transmission parameters, in, the first set of one or more transmission parameters being associated with a first type of hybrid automatic repeat request (HARQ) feedback, and the second set of one or more transmission parameters being associated with a second type of HARQ feedback; receiving downlink control information (DCI) for a downlink transmission; determining, based on the DCI, whether to apply the first set of one or more transmission parameters or the second set of one or more transmission parameters; as well as If the DCI indicates that the first set of one or more transmission parameters is applied, the first type of HARQ feedback is sent, or if the DCI indicates that the second set of one or more transmission parameters is applied, the second type of HARQ feedback is sent.

Images