CN113115453A

CN113115453A - Medium access protocol data unit assembly in a wireless system

Info

Publication number: CN113115453A
Application number: CN202110295595.8A
Authority: CN
Inventors: 马蒂诺·M·弗雷达; 保罗·马里内尔; 吉斯伦·佩尔蒂埃; 伯诺瓦·佩尔蒂埃
Original assignee: IDAC Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2016-05-11
Filing date: 2017-05-10
Publication date: 2021-07-13
Anticipated expiration: 2037-05-10
Also published as: KR20230015497A; KR20210036997A; KR20240058954A; WO2017196968A1; US11601224B2; US20190149274A1; TW202224466A; CN113115453B; EP3455982A1; JP2024029198A; JP2023052254A; US20230421305A1; KR20190017742A; TWI798953B; US11863302B2; US20230188269A1; TW201804835A; JP7418625B2; JP2019521552A; JP2021002878A

Abstract

Systems, methods, and measures (e.g., aspects of entities, interfaces, and procedures 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, such as a 5G flexible Radio Access Technology (RAT) (5gFLEX) are disclosed. Latency may be reduced, for example, by the WTRU determining network transmission parameters and signaling before transmission permission. The WTRU may receive a Modulation and Coding Scheme (MCS), a resource range, etc. prior to the grant, e.g., for use in a subsequent grant. The data block may be incrementally created/encoded prior to licensing. Data units may be segmented, assembled and multiplexed, for example, based on data block sizes that allow MAC and Radio Link Control (RLC) processing prior to admission. Flexible grant sizes may be provided for early generation of transport blocks prior to grant.

Description

Medium access protocol data unit assembly in a wireless system

The application is a divisional application of a chinese patent application 201780028257.X entitled "medium access protocol data unit assembly in wireless system" filed on 5, month and 10 of 2017.

Cross Reference to Related Applications

This application claims priority and benefit of U.S. provisional application serial No. 62/334,529, filed 2016, 5, 11, which is hereby incorporated by reference.

Background

Mobile communications continue to evolve. The fifth generation may be referred to as 5G. The previous (legacy) generation mobile communication may be, for example, a fourth generation (4G) Long Term Evolution (LTE).

Disclosure of Invention

Systems, methods, and measures (e.g., aspects of entities, interfaces, and procedures 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)) are disclosed. Latency may be reduced, for example, by the WTRU determining network transmission parameters and signaling prior to transmission permission. The WTRU may receive a Modulation and Coding Scheme (MCS), a resource range, etc. prior to the grant, e.g., for a subsequent grant. The data block may be incrementally created/encoded prior to licensing. The data units may be segmented, assembled and multiplexed, for example, based on data block sizes that allow MAC and Radio Link Control (RLC) processing prior to admission. The flexible grant size may be provided for pre-grant transport blocks of a previous generation. A minimum guaranteed Transport Block Size (TBS) may be signaled to allow previous generation MAC PDUs. The transmission parameters may be selected prior to the grant, for example using a blind decoding or DCI reception process.

A wireless transmit/receive unit (WTRU) may include a processor configured (e.g., using executable instructions stored in a memory) to perform 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 a downlink control channel; (iii) decoding at least a first DCI on a 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 used to decode the first DCI.

The 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 comprise a set of physical resource blocks. The at least one decoding parameter may indicate whether the at least one data transmission is associated with one or more of high reliability data, low latency data, or best effort data.

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

The decoding may include blind decoding. The decoding parameters may include a subset of resources that were used to decode the first DCI when performing blind decoding. The subset of resources may include one or more Control Channel Elements (CCEs) and an identification of the one or more CCEs may correspond to at least one decoding parameter.

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.

The one or more transmission or reception parameters for the at least one data transmission may include one or more of a quality of service (QoS) level associated with the at least one data transmission or a Spectrum Operation Mode (SOM) associated with the at least one data transmission. The one or more transmission or reception parameters for the at least one data transmission may include a hybrid automatic repeat request (HARQ) feedback parameter associated with the at least one data transmission. The HARQ feedback parameters may include timing information for transmission or reception of HARQ feedback.

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.

The one or more transmission or reception parameters for the data transmission may include one or more of: a Modulation and Coding Scheme (MCS), a set of physical resource blocks associated with the at least one data transmission, power information associated with the at least one data transmission, transmission timing information for the at least one data transmission, or a Transmission Timer Interval (TTI) duration associated with the at least one data transmission.

The method of using the WTRU may include one or more of: (i) monitoring Downlink Control Information (DCI) on at least resources of a downlink control channel; (ii) identifying resources of a downlink control channel; (iii) decoding at least a first DCI on a downlink control channel, 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 used to decode the first DCI.

The method of using the WTRU may include: (i) transmit HARQ-ACK feedback over resources associated with the determined decoding parameters of the decoded downlink control channel indication, and/or (ii) receive 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.

Drawings

FIG. 1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;

figure 1B is a system diagram of an exemplary WTRU that may be used in the communication system shown in figure 1A;

fig. 1C is a system diagram of an example radio access network and an example core network that may be used in the communication system shown in fig. 1A;

fig. 1D is a system diagram of another example radio access network and another example core network that may be used in the communication system shown in fig. 1A;

fig. 1E is a system diagram of another example radio access network and another example core network that may be used in the communication system shown in fig. 1A;

FIG. 2 is an example of transmission bandwidth;

fig. 3 is an example of flexible spectrum allocation;

fig. 4 is an example of timing relationships for TDD duplexing;

fig. 5 is an example of timing relationships for FDD duplexing.

Detailed Description

A detailed description of exemplary embodiments will now be described with reference to the accompanying drawings. While this 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 application.

Fig. 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. The communication system 100 allows multiple wireless users to access such content by sharing system resources, including wireless bandwidth. By way of example, 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), and so forth.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which may be generally or collectively referred to as WTRUs 102), a Radio Access Network (RAN)103/104/105, a core network 106/107/109, a Public Switched Telephone Network (PSTN)108, the internet 110, and other networks 112, although it is understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments. 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 telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a consumer electronics device, and the like.

Communication system 100 may also include base station 114a and base station 114 b. Each

base station

114a, 114b may be any type of device configured to facilitate access to one or more communication networks, which may be 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, 102 d. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node B, e node bs, home enodebs, site controllers, Access Points (APs), wireless routers, and so forth. 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.

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 Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area known as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with 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 a 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.

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.

More specifically, as described above, 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, and the like. For example, the base station 114a and

WTRUs

102a, 102b, 102c in the RAN 103/104/105 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), and the technology may establish the air interface 115/116/117 using wideband cdma (wcdma). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may then include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

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) that may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a).

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, CDMA 20001X, CDMA2000 EV-DO, temporary Standard 2000(IS-2000), temporary Standard 95(IS-95), temporary Standard 856(IS-856), Global System for Mobile communications (GSM), for enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and so forth.

By way of example, the base station 114B in fig. 1A may be a wireless router, home nodeb, home enodeb, or access point, and may facilitate wireless connectivity in a local area using any suitable RAT, such as a business, residence, vehicle, campus, and so forth. 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 IEEE 802.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 the pico cell or the femto cell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-a, etc.). As shown in fig. 1A, 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.

The RAN 103/104/105 may communicate 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, 102 d. 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 not shown in fig. 1A, it should be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to interfacing with the RAN 103/104/105 using E-UTRA radio technology, the core network 106/107/109 may also communicate with another RAN (not shown) using GSM radio technology.

The core network 106/107/109 may also serve as a gateway for the

WTRUs

102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a system of globally interconnected computer network devices using 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 network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

Some or all of the

WTRUs

102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, i.e., the

WTRUs

102a, 102b, 102c, 102d may include multiple transceivers that communicate with different wireless networks over different wireless links. For example, the WTRU 102c shown in fig. 1A may be configured to communicate with a base station 114a that uses a cellular-based radio technology and with a base station 114b that may use an IEEE 802 radio technology.

Figure 1B is a system diagram illustrating a WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touch pad 128, non-removable memory 130, 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 subcombination of the foregoing elements while maintaining a consistent implementation. Embodiments herein also contemplate that base stations 114a and 114B, and/or the nodes represented by base stations 114a and 114B, may include some or all of the elements depicted in fig. 1B and described herein, and in particular, the nodes represented by base stations 114a and 114B may be, but are not limited to, transceivers (BTSs), node bs, site controllers, Access Points (APs), home node bs, evolved home node bs (enodebs), home evolved node bs (henbs or He nodebs), home evolved node B gateways, and proxy nodes.

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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or 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 a transceiver 120 and the transceiver 120 may be coupled to a transmit/receive element 122. Although fig. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may be integrated into one electronic component or chip.

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 the 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, the transmit/receive element 122 may be, for example, an emitter/detector configured to emit 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 optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Furthermore, although transmit/receive element 122 is depicted in fig. 1B as a single element, WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) that transmit and receive radio signals via the air interface 115/116/117.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and to demodulate signals received by 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.

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keyboard 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from, and store information in, any suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and so forth. In other embodiments, the processor 118 may access information from and store data in memory not physically located in the WTRU 102, such as in a server or a home computer (not shown).

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power for 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, and the like.

The processor 118 may also be coupled with a 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 base stations (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 maintaining consistent embodiments.

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 peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, bluetooth modules, Frequency Modulation (FM) radio units, digital music players, video game player modules, internet browsers, and so forth.

Fig. 1C is a system diagram of RAN 103 and core network 106 according to one embodiment. As described above, the RAN 103 may communicate with the

WTRUs

102a, 102b, 102c using E-UTRA radio technology and via the air interface 115. And RAN 103 may also communicate with core network 106. As shown in fig. 1C, the RAN 103 may include node bs 140a, 140B, 140C, each of which may include one or more transceivers to communicate 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, 142 b. It should be appreciated that RAN 103 may include any number of node bs and RNCs while remaining consistent with an embodiment.

As shown in fig. 1C, node bs 140a, 140B may communicate with RNC 142 a. Node B140 c may also communicate with RNC 142B. The

node bs

140a, 140B, 140c may communicate with the respective RNCs 142a, 142B via an Iub interface. The

RNCs

142a, 142b may then communicate with each other via the Iur interface. Each RNC 142a, 142B may be configured to control the respective node B140 a, 140B, 140c to which it is connected. In addition, each

RNC

142a, 142b may 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 functions, data encryption, and so forth.

The core network 106 shown in fig. 1C may include a Media Gateway (MGW)144, a Mobile Switching Center (MSC)146, a Serving GPRS Support Node (SGSN)148, and/or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing elements are described as being part of the core network 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the core network operator.

RNC 142a in RAN 103 may be connected to MSC 146 in core network 106 via an IuCS interface. The MSC 146 may then be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the

WTRUs

102a, 102b, 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communications between the

WTRUs

102a, 102b, 102c and conventional landline communication devices.

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 be coupled to a GGSN 150. The SGSN 148 and GGSN 150 may provide the

WTRUs

102a, 102b, 102c with access to packet-switched networks, such as the internet 110, to facilitate communications between the

WTRUs

102a, 102b, 102c and IP-enabled devices.

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

Fig. 1D is a system diagram of RAN 104 and core network 107 according to one embodiment. As described above, the RAN 104 may communicate with the

WTRUs

102a, 102b, 102c using E-UTRA radio technology and via the air interface 116. RAN 104 may also communicate with core network 107.

RAN 104 may include enodebs 160a, 160B, 160c, but it should be appreciated that RAN 104 may include any number of enodebs while remaining consistent with an embodiment. Each enode B160a, 160B, 160c may include one or more transceivers to communicate with the

WTRUs

102a, 102B, 102c via the air interface 116. In one embodiment, the enode bs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enodeb 160a may use multiple antennas to transmit wireless signals to the WTRU 102a and to receive wireless signals from the WTRU 102 a.

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 so on. As shown in fig. 1D, the enode bs 160a, 160B, 160c may communicate with each other over an X2 interface.

The core network 107 shown in fig. 1D may include a mobility management gateway (MME)162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. Although each of the above elements are described as being part of the core network 107, it should be understood that any of these elements may be owned and/or operated by an entity other than the core network operator.

The MME 162 may be connected to each enodeb 160a, 160B, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the

WTRUs

102a, 102b, 102c, activating/deactivating bearers, selecting a particular serving gateway during initial attach of the

WTRUs

102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function to perform handovers between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

The serving gateway 164 may be connected to each enodeb 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, 102 c. The serving gateway 164 may perform other functions such as anchoring the user plane during inter-enodeb 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, etc.

The serving gateway 164 may also be connected to a PDN gateway 166 that may provide the

WTRUs

102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the

WTRUs

102a, 102b, 102c and IP-enabled devices.

The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the

WTRUs

102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the

WTRUs

102a, 102b, 102c and conventional landline communication devices. By way of example, the core network 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. The core network 107 may also provide the

WTRUs

102a, 102b, 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 1E is a system diagram of RAN 105 and 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, the 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.

As shown in fig. 1E, the RAN 105 may include

base stations

180a, 180b, 180c and an ASN gateway 182, although 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 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 to receive wireless signals from the WTRU 102 a. 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 enforcement, 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 so forth.

The air interface 117 between the

WTRUs

102a, 102b, 102c and the RAN 105 may be defined as the R1 reference point for implementing the IEEE 802.16 specification. In addition, each

WTRU

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 that may be used for authentication, admission, IP host configuration management, and/or mobility management.

The communication link between each

base station

180a, 180b, 180c may be defined as an R8 reference point that contains protocols for facilitating WTRU handover 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 a reference point for facilitating mobility management based on mobility events associated with each

WTRU

102a, 102b, 180 c.

As shown in fig. 1E, RAN 105 may be connected to core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point that contains protocols for facilitating data transfer and mobility management capabilities, as an example. The core network 109 may include a mobile IP home agent (MIP-HA)184, an Authentication Authorization Accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements are described as being part of the core network 109, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

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 and IP-enabled devices. The AAA server 186 may be responsible for performing 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 and conventional landline communication devices. In addition, the gateway 188 may also provide the

WTRUs

Although not shown in fig. 1E, it should be appreciated that RAN 105 may be connected to other ASNs and 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 that 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 the home core network and the visited core network.

Air interfaces such as used for New Radio (NR) access technologies in 5G systems may support various use cases such as improved broadband performance (IBB), Industrial Control and Communications (ICC) and vehicle applications (V2X), and large machine type communications (mtc). Use cases may have associated support in an air interface (e.g., a 5G air interface).

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

Support for ultra-low transmission delay (LLC) may include, for example, air interface delay, e.g., 1ms RTT and TTIs between 100us and 250 us. Support may be provided for ultra-low access latency (e.g., time from initial system access until completion of transmission of the first user plane data unit). End-to-end (e2e) delays below 10ms may be supported, for example, for IC and V2X.

Support for ultra-reliable transport (URC) may include, for example, improved transport reliability, such as 99.999% transmission success and service availability. Support may be provided for mobile speeds in the range of 0-500 km/h. Less than 10e may be provided, for example, for IC and V2X^-6The packet loss rate of.

Support for MTC operation 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).

The 5g flex system may be implemented with OFDM and/or other waveforms for uplink and/or downlink. The description of the examples herein is non-limiting. Examples may be applicable and adaptable to other waveforms and wireless technologies.

OFDM may 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. The (e.g. each) subcarrier may be shaped using a rectangular window in the time domain, which may result in sinusoidally shaped subcarriers in the frequency domain. OFDMA may rely on close management of uplink timing alignment for the duration of the (e.g., perfect) frequency synchronization and cyclic prefix, e.g., to maintain orthogonality between signals and minimize inter-carrier interference. Tight synchronization may be difficult, for example, in a system where a WTRU may be connected to multiple access points simultaneously. Additional power reduction may be applied to uplink transmissions, for example to comply with spectral emission requirements of adjacent frequency bands. The segmented spectrum may be aggregated for WTRU transmission.

OFDM (CP-OFDM) performance may be improved, for example, by implementing more stringent RF requirements (e.g., operation using a large amount of contiguous spectrum that does not require aggregation). The CP-based OFDM transmission scheme may provide a downlink physical layer for 5G similar to 4G systems, which modifies pilot signal density and location.

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

The multicarrier modulation waveform may divide a channel into a plurality of subchannels and may modulate data symbols on the subcarriers in the subchannels.

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

In an example of a general filtering multi-carrier (UFMC), such as UF-OFDM, a filter may be applied to the OFDM signal in the time domain to reduce OOB. Filtering may be applied per sub-band to use spectral segmentation, which may reduce complexity and make UF-OFDM more practical to implement. OOB emissions in unused spectral segments in the band may be as high as in OFDM. UF-OFDM may provide some improvement over OFDM at the edges of the filtered spectrum, with little to no improvement in spectral holes.

These waveforms enable frequency multiplexing 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 may facilitate aggregation of fragmented spectrum of the spectrum in baseband processing, for example, as a lower cost alternative to its implementation as part of RF processing.

Coexistence of different waveforms within the same frequency band may be considered, for example, to support mtc narrowband operation (e.g., using SCMA). Different waveforms, e.g. CP-OFDM, OFDM-OQAM and UF-OFDM, may be combined in the same frequency band, e.g. for all aspects and for downlink and uplink transmission. 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 or continuity in the time domain.

Other coexistence aspects may include support for mixed types of waveforms, e.g., may support waveforms and/or transmissions such as: possibly varying CP durations (e.g., from one transmission to another), combinations of CPs and low power tails (e.g., zero tails), and/or forms of hybrid guard intervals (e.g., using low power CPs and adaptive low power tails), etc. The waveform may support dynamic and/or other controls such as how filtering is applied (e.g., whether filtering is applied per subband or per group of subbands at the received spectral edge for any transmission at a given carrier frequency, at the received spectral edge for a transmission associated with a particular SOM).

The uplink transmission scheme may use the same or different waveforms for downlink transmission.

Transmissions to and from different WTRUs may be multiplexed in the same cell based on FDMA and TDMA, for example.

A very high degree of spectrum flexibility may be characterized by a 5g flex radio access, which enables deployment in different frequency bands of different characteristics, which may include different duplexing arrangements, different and/or variable sizes of available spectrum, e.g., continuous and discontinuous spectrum allocations in the same or different frequency bands. The 5gFLEX radio access may support variable timing aspects such as support for multiple TTI lengths and asynchronous transmissions.

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, the DL/UL allocation may be dynamic for TDD operation (e.g., may not be based on a fixed DL/UL frame configuration). The length of the DL or UL transmission interval may be set at each transmission opportunity.

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

Single carrier operation may support multiple or a range of system bandwidths, e.g., 5,10,20,40 and 80MHz,160 MHz. The nominal bandwidth may have one or more fixed values. Narrow-band transmissions (e.g., 0 to 200KHz) may be supported within the operating bandwidth of MTC devices.

System bandwidth may refer to the largest portion of the spectrum that a network may manage for a given carrier. The portion of the spectrum of the carrier that the WTRU minimally supports for cell acquisition, measurement, and initial access to the network may correspond to a nominal system bandwidth. The WTRU may be configured with a channel bandwidth that may be within the entire system bandwidth. The configured channel bandwidth of the WTRU may or may not include a nominal portion of the system bandwidth, for example as shown in the example of fig. 2.

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

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

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

The cell-specific and/or WTRU-specific channel bandwidth for any spectrum block size may be scaled and managed (e.g., scheduled, resource addressed, broadcast signals, measurements, etc.).

The downlink control channels and signals may support FDM operation. The WTRU may acquire the downlink carrier, for example, by receiving transmissions using (e.g., using only) a nominal portion of the system bandwidth. For example, the WTRU may not initially receive a transmission covering the entire bandwidth managed by the network for the carrier.

The downlink data channel may be allocated on a bandwidth that may or may not correspond to the nominal system bandwidth, e.g., without restrictions other than within the WTRU's configured channel bandwidth. For example, the network may operate with a carrier of 12MHz system bandwidth using a 5MHz nominal bandwidth, allowing devices to support a 5MHz maximum RF bandwidth to acquire and access the system while potentially allocating a carrier frequency of +10 to-10 MHz to other WTRUs supporting a channel bandwidth of up to a value of 20 MHz.

Fig. 3 is an example of flexible spectrum allocation. Fig. 3 shows an example of spectrum allocation, where different subcarriers may be (e.g., at least conceptually) assigned to different modes of operation (hereinafter referred to as spectrum modes of operation or SOMs). Different SOMs may be used to meet different requirements for different transmissions. The SOM may include a subcarrier spacing, a TTI length, and/or one or more reliability aspects (e.g., HARQ processing aspects, secondary control channels). SOM may be used to refer to (e.g., specific) waveforms or may be related to processing aspects (e.g., support for coexistence of different waveforms in the same carrier using FDM and/or TDM or coexistence of FDD operation in a TDD band (e.g., supported in a TDM fashion or the like)).

The WTRU may be configured to perform transmissions in accordance with one or more SOMs. For example, the SOM may correspond to a transmission using at least one of: a specific TTI duration, a specific initial power level, a specific HARQ process 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 transmission according to a specific RAT (e.g. LTE or according to a 5G transmission technology). The SOM may correspond to a QoS level and/or a related aspect (e.g., maximum/target delay, maximum/target BLER, or the like). The SOM may correspond to a spectral region and/or a particular control channel or aspect thereof (e.g., search space or DCI type). For example, the WTRU may be configured with SOM for URC type services, LLC type services, and/or MBB type services. The WTRU may have a configuration of SOMs for system access and/or transmission/reception of 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.

Spectrum aggregation (e.g., for single carrier operation) may be supported. A WTRU may support transmission and reception of multiple transport blocks over a contiguous or non-contiguous set of Physical Resource Blocks (PRBs) (e.g., within the same operating frequency 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.

Multicarrier operation may be supported, for example, using contiguous or non-contiguous blocks of spectrum within the same operating frequency band or over two or more operating frequency bands. Different modes (e.g., FDD and TDD) and/or different channel access methods (e.g., licensed and unlicensed band operation below 6 GHz) may be used to provide support for spectrum block aggregation. Support may be provided for procedures to configure, reconfigure, and/or dynamically change the WTRU's multi-carrier aggregation.

Downlink (DL) and Uplink (UL) transmissions may be organized as radio frames characterized by a number of fixed aspects (e.g., location of downlink control information) and a number of varying aspects (e.g., transmission timing, supported transmission types).

A Base 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. Subcarrier spacing (e.g., for FDD) may be at uplink carrier frequency f for a given frame_ULAnd downlink carrier frequency f_DLThe cells are different.

The Transmission Time Interval (TTI) may correspond to the minimum time supported by the system between successive transmissions, and each transmission may be associated with a downlink (TTI)_DL) Different Transport Blocks (TBs) of the uplink (UL TRx) are associated, which may not contain 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. The BTI may be specific and/or associated with a given SOM.

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, e.g., to enable calibration with the LTE timing structure.

The frames may be from a fixed time duration t_dciStarts at the considered carrier frequency (f for TDD)_UL+DLF for FDD_DL) Before downlink data transmission (DL TRx).

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

A frame may include a downlink reference TTI (e.g., for TDD duplexing) and one or more TTIs (e.g., for uplink). An offset (t) applied from the beginning of a downlink reference frame that may overlap with the beginning of an uplink frame may be used, for example_offset) To obtain the start of the uplink TTI.

The 5g flex may support D2D/V2 x/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 using semi-static allocation of respective resources) or DL TRx portion (e.g., for dynamic allocation) and respective reverse transmissions in the UL TRx portion.

The 5g flex may support (e.g., for FDD) D2D/V2 x/sidelink operation in the UL TRx portion of the frame, e.g., by including respective downlink control, forward and reverse transmissions in the UL TRx portion. Dynamic allocation of the respective resources may be used.

Fig. 4 and 5 provide examples of frame structures. Fig. 4 is an example of timing relationships for TDD duplexing. Fig. 5 is an example of timing relationships for FDD duplexing.

The scheduling function 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 terms of timing and transmission parameters). The scheduling information of the pattern may be valid for one or more TTIs.

Network-based scheduling may enable the network to tightly manage the available radio resources assigned to different WTRUs, which may allow optimal sharing of resources. Dynamic scheduling may be supported.

WTRU-based scheduling may enable a WTRU to opportunistically access uplink resources, such as within a set of shared or dedicated uplink resources assigned by the network (e.g., statically or dynamically), with minimal delay, as needed. Support may be provided for synchronous and asynchronous opportunistic transmission. Support may be provided for contention-based and contention-free transmissions.

Support for opportunistic transmission (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 mtc.

The 5g flex may support one or more forms of association between data available for transmission and resources available for uplink transmission. Multiplexing of data for different QoS requirements within the same transport block may be supported, for example, when multiplexing does not negatively impact the services for the most stringent QoS requirements and does not cause unnecessary waste of system resources.

The transmission may be encoded using a number of different encoding methods. Different encoding methods may have different characteristics.

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

An example of an encoding technique may include a bird prey (raptor)/base code, for example where the transmission may include a sequence of N bird prey codes. One or more codes may be mapped in time to one or more transmission "symbols". A "symbol" may correspond to one or more sets of information bits, e.g., one or more octets. Encoding may be used to add FEC to the transmission, for example, where the transmission may use N +1 or N +2 birds or symbols (e.g., assuming a bird symbol relationship). A transmission may be more resilient to the loss of one "symbol", for example due to interference or puncturing (puncturing) of another transmission that overlaps in time.

The WTRU may be configured to receive and/or detect one or more system signatures. The system signature may include a signal structure using the sequence. The signals may be similar to synchronization signals, e.g., similar to 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 associated with the WTRU. The WTRU may determine and/or detect the 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 obtain the associated parameters, e.g., in a table (such as an access table). For example, when the WTRU determines that it may 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 may 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 the transmission (e.g., the preamble on the PRACH resource).

The WTRU may be configured with a list of one or more entries. The list may be referred to as an access table. The list may be indexed, for example, where (e.g., each) item may be associated with a system signature and/or to a sequence thereof. The access table may provide initial access parameters for one or more regions. The (e.g., each) entry 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 physical layer resources for reception of a response. The parameters may, for example, 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 item may be associated with (and/or indexed by) a system signature. Such an item may be common to multiple nodes (or TRPs). The WTRU may receive the access table, for example, via transmission using dedicated resources (e.g., through RRC configuration) and/or by transmission using broadcast resources. In the latter case, the period of transmission of the access table may be relatively long (e.g. up to 10240ms), which may be longer than the period of transmission of the signature (e.g. in the range of 100 ms).

Logical Channels (LCHs) may represent logical associations between data packets and/or PDUs. The association may be based on the data units being associated with the same bearer (similar to legacy), and/or with the same SOM and/or Slice (Slice) (e.g., processing path using a set of physical resources). For example, the association may be characterized as at least one of: linking of processing functions, instantiation of applicable physical data (and/or control) channels (or instances thereof), or protocol stacks, with (i) a particular portion being concentrated (e.g., PDCP or anything other than the portion of physical layer processing, such as the Radio Front (RF) side) and (ii) another portion being closer to the edge (e.g., MAC/PHY in TRP or RF) potentially separated by the fronthaul interface. The term LCH as used herein may have a different and/or broader meaning than similar terms of the LTE system.

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 a configuration of one or more field values common to data units that are part of the same logical association). The fields may correspond to fields in a protocol header associated with the data unit. For example, the matching function may use parameter tuples of fields of an IP header of a data unit, such as IP source/destination addresses, transport protocol source/destination ports and transport protocol types, IP protocol versions (e.g., IPv4 or IPv6), and so on.

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

A Logical Channel Group (LCG) may include a group of LCHs (or equivalents as each defined 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 can be characterized as at least one of: linking of processing functions, instantiations of applicable physical data (and/or control) channels (or instances thereof), or protocol stacks, which may include (i) a particular portion being centralized (e.g., anything other than PDCP or RF) and (ii) another portion being closer to edges potentially separated by a fronthaul interface (e.g., MAC/PHY in TRP or RF). The term LCG as used herein may have a different and/or broader meaning than similar terms of the LTE system.

A transport channel (TrCH) may comprise 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.

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). The transport channels used to carry user plane data may include a DL-SCH and an UL-SCH for the downlink and uplink, respectively.

The air interface for a 5G system may support the set of enhancement requirements. Support may be provided for multiple transport channels, e.g., for user and/or control plane data, for one or more WTRU devices. The term TrCH as used herein may have a different and/or broader meaning than similar terms of the LTE system. For example, a transport channel (e.g., URLLCH) for URLLC, a transport channel (MBBCH) for mobile broadband and/or a transport channel (MTCCH) for machine type communication can 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).

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 advantageous to support simultaneous transmission of traffic with different requirements on the same SOM. One example of this may be to transmit the URLLCH and MTCCH simultaneously when the WTRU is configured with a single SOM.

The WTRU may be configured with one or more parameters associated with the 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 characterization-based data. The parameters may include, for example, time-related aspects (e.g., time-to-live (TTL) -for a packet, which represents the time before which the packet should be delivered to meet, acknowledged, etc. to meet latency requirements), rate-related aspects, and configuration-related aspects (e.g., absolute priority). The parameters may (for example also) change with the time that a packet or data may be pending for transmission.

The 5G air interface may support multiple use cases with different QoS requirements, e.g. in terms of differences between applicable radio resources and transmission methods. For example, TTI duration, reliability, diversity applied to transmissions, and maximum delay may be different in various use cases.

The WTRU may face additional challenges in terms of processing bottlenecks, for example, due to increased throughput and decreased latency (e.g., shorter TTI durations and decreased number of processes).

The process may optimize the creation and assembly of layer 2 protocol data units (e.g., MAC PDUs).

RLC segmentation, assembly, MAC layer multiplexing, and PHY layer coding may be performed after receiving the grant. The latency of the grant for UL transmissions may not be improved beyond the hardware and software latency of these operations.

A process may be provided for segmentation, assembly and reuse. The 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).

The WTRU may use parameters to affect 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 the 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 the characterization-based data.

The behavior may be related to PDU assembly and limitations, e.g., in terms of processing time. The WTRU may determine that one or more procedures such as those described herein may be applicable.

The processes described herein may be used in whole or in part, alone or in combination with any other process, whether or not so described herein. One or more of the example procedures described herein may be partially or fully executed or applied on a network or WTRU.

A procedure may be provided for determining PHY layer parameters prior to admission. For example, the WTRU may determine or be configured with PHY layer parameters for data transmission prior to receiving a grant for an UL transmission. Early determination of the parameters may allow certain PHY layer processing to be performed by the WTRU before the UL grant, which may be advantageous to allow the WTRU to perform UL transmissions with minimal delay from transmission of the UL grant for certain types of data, e.g., to minimize latency associated with UL transmissions. Determining PHY layer parameters early may be used, for example, also in conjunction with other processes described herein.

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

The parameters may be signaled from the network. For example, the WTRU may receive the PHY layer parameters in advance, e.g., through signaling by the network. The WTRU may receive parameters for a certain type 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.

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

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

The WTRU may (e.g., also) indicate to the network when an event, such as one or more of the events described above, occurs.

The MCS may be received and used for subsequent grants. In an example implementation, a WTRU may periodically receive an MCS to be used for transmitting data over a portion of a transmission 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 apply the signaled MCS to (e.g., all) transmissions on the associated transmission bandwidth (e.g., upon receiving a periodic MCS transmission). The WTRU may determine (e.g., a priori or based on configuration) to associate one or more L2 protocol data units with the initially signaled bandwidth range and (as a result) MCS. For example, the WTRU may determine that the MCS may be provided for the set of logical channels. The WTRU may map the logical channels to a portion of the bandwidth for which an MCS has been signaled.

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

The WTRU may receive a subset of resources from which the grant may be selected (e.g., subsequently). For example, a WTRU may receive a range of resources within its transmission bandwidth. The resource range may be used, for example, to indicate to the WTRU the set of resources that the WTRU is required to transmit from when the 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, or a combination thereof, available during the validity time of the PHY layer parameter. The grant may indicate to the WTRU the specific resources within the initial range of resources. For example, the PHY layer parameters may select x resource blocks per TTI that may be used by the WTRU. 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.

An advantage of this technique may be to reduce the latency associated with grant decoding, e.g., the portion of resources indicated for a given grant is known a priori in the PHY layer information received prior to the WTRU.

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 the following: (i) SNR, CQI or similar measurements performed by the WTRU on the DL; (ii) a measurement of ACK/NACK frequency for transmissions made over a frequency range of interest; and/or (iii) a measurement of reference signal power, SINR, etc., related to reference signals over the frequency range of interest.

The network may configure the WTRU with a (e.g., dynamic or semi-static) frequency range that the WTRU may (e.g., must) use to define its own set of PHY layer parameters.

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 transmissions on any resource for which the WTRU may receive a grant.

The frequency range for the WTRU to determine the parameters may be dynamically configured by the network. For example, the network may configure the WTRU to perform the above measurements and calculation of MCS for (e.g., only) frequency ranges a and B, where a and B may be a subset 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.

The network may configure the configuration of the frequency range that the WTRU may perform its own PHY layer parameter determination, e.g., through RRC signaling. The configuration may be changed to an updated configuration. For example, the network may use the frequency range with the best channel characteristics for URLLC transmissions at any given time. The network may dynamically reconfigure the frequency range for which the WTRU may perform its own PHY layer parameter determination.

The WTRU may signal the PHY layer parameters. For example, the WTRU may signal to the network the 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) in selecting/determining parameters, (ii) during transmission of data using parameters, in which case the WTRU may signal parameters explicitly in the control information and/or implicitly based on the attributes of the transmitted data implying a particular selection using control parameters, (iii) at a network request and/or (iv) at a network providing resources for transmission of data or control that may or may not be planned for transmission of these parameters.

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

The WTRU may signal the data block size or TB size in SR, BSR, RA, or similar uplink transmissions. The WTRU may signal the data block size or TB size that it may or will use for subsequent transmissions. For example, the WTRU may prepare a set of data blocks and prepare for transmission. The WTRU may (e.g., also) have combined the data blocks into a transport block. The WTRU may provide the data block size and/or TB size in the SR, BSR, or RA that is transmitted to the network.

The WTRU may indicate a process size or TB size for the data block, e.g., 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. Signaling may be sent with a limited number of bits, which may allow the WTRU to signal one of 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.

The transport block size may be implicitly provided in the CRC check value. The WTRU may select its Modulation and Coding (MCS) (e.g., not provide this by the network). The WTRU may select its transport block size, for example, based on the number of available fixed-size MAC PDUs to transmit and the size of the resource grant. The WTRU may determine the MCS, for example, using the procedures described herein. The WTRU may signal its MCS (e.g., explicit) to the network, e.g., based on one or more procedures described herein. The transport block size used by the WTRU may be indicated (e.g., implicitly) as part of the CRC check value of, for example, one or more individual MAC PDUs within the transport block. The WTRU may, for example, insert padding into (e.g., each) fixed-size MAC PDU to obtain a CRC check value that implicitly (e.g., to the network) indicates 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 the first transport block size, e.g., when the CRC check value of the first coded block transmitted is divisible by one value. The CRC check value may implicitly signal the WTRU's selection of the second transport block size, etc., e.g., when the CRC check value of the first coded block transmitted may be divided by another value.

The MAC PDU/transport block may be created incrementally. The TB may be created from a fixed data block size. This may provide advantages over the performance of RLC segmentation, assembly, MAC layer multiplexing and PHY layer coding after receiving a grant. The latency of the grant for UL transmissions may not be improved beyond the hardware and software latency of these operations.

For example, the WTRU may perform incremental creation of transport blocks through the assembly of data blocks of fixed size. The WTRU may perform the creation of the data block by creating a fixed size data block immediately upon arrival of the data, with or without waiting for information in the grant from the network as higher layer data arrives in the WTRU buffer. The WTRU may create the TB, for example, by allocating a number of data blocks to the TB to occupy the grant of the size. The WTRU may (e.g., also) be given permission to be a multiple of the fixed data block size, e.g., to minimize padding. The WTRU may (e.g., alternatively) fit as many data blocks to the allowed transport blocks of the grant size. The WTRU may occupy any remaining data, e.g., with one or more of the following: (i) filling; (ii) MAC control information, e.g., information about required resources, pending MAC PDUs to be transmitted, MAC PDU size, indication of packets with terminated TTL, etc., and/or (iii) additional coding that the PHY layer may insert, speed matching, etc.

The WTRU may be configured to use (e.g., one) or a limited set of specific data block sizes for a particular flow, bearer, logical channel, etc. The WTRU may (e.g., also) be limited to using a particular data block size for (e.g., only) one or more particular flows, logical channels, bearers, etc., and may not need to be limited 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 particular data block size for data associated with the URLLC or a flow having QoS characteristics associated with the URLLC, but may create data blocks without restrictions on the size of other flows or data.

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

The configured data block size may be statically configured in the WTRU or signaled by the network, for example. The WTRU may receive the set of allowed data block sizes, e.g., periodically or non-periodically, e.g., based on a change 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).

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

The WTRU may derive a fixed data block size to be used, for example, based on PHY layer information that may be provided prior to admission. For example, the WTRU may calculate the allowed data block size based on one or more of the PHY layer parameters (e.g., the parameters described herein). For example, the WTRU may determine that the data block size is equal to the coding block size provided as part of the PHY layer parameters indicated prior to the grant.

The WTRU may select one or more data block sizes from a set of allowed sizes to be used (e.g., independently used) for each data block created. The data block size may be selected for one or more reasons, such as to accommodate the type of traffic at higher layers, based on the size of packets received in the most recent time period, the buffering capabilities of the WTRU, and/or other implementation-related aspects. The WTRU may (e.g., alternatively) select a data block size to be used for a particular stream, 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 period of time. The WTRU may (e.g., also) perform selection when other triggers occur, such as one or more of the following: (i) new type of data arrival, (ii) next reception of a new set of data block sizes, (iii) end of frame/superframe or similar defined boundary, (iv) periodically or upon expiration of a timer, (v) upon detection (e.g., by the WTRU) of a change to channel quality or other similar measurement, (vi) upon reception of a new configuration from the network (e.g., a change in frequency, HARQ parameters, PHY configuration, etc.).

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 under any one or more triggers, such as (i) arrival of a packet or SDU, which may be scaled 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) when one or more SDUs arrive, 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 WTRU-selected data block size.

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

The WTRU may select a data block size (e.g., from a list of allowed data block sizes), such as its closest in size to a higher layer SDU that may be received or padding to minimize insertion. In one example, the WTRU may choose to minimize the padding data block size (e.g., from a list of allowed sizes), such as when a single RLC packet associated with a particular buffer or flow may be (e.g., is) present in the WTRU when data block creation is performed.

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 set 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, flow 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 transmit at a given time. The WTRU may provide one or more headers to the lower layers for encoding, e.g., with the data block.

The 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 head may include, for example, one or more of the following; (i) the number of data blocks in a transport block, (ii) one or more sizes of the data blocks in the transport block, (iii) a flow, logical channel, or service associated with (e.g., each) data block, and/or (iv) an amount of control information (e.g., MAC CE) contained in the transport block.

The WTRU may include (e.g., in the TB currently being transmitted) information such as the size of the pending TB to be transmitted or ready to be transmitted by the WTRU. For example, this information may be included in the MAC CE that is transmitted as part of the current TB being transmitted.

The WTRU may include (e.g., in the current TB) one or more block sizes of prepared or pending blocks to be transmitted in the following TBs.

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

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

The WTRU may perform (e.g., upon receiving the permission) one or more of the following actions, for example: (i) multiplexing and transport block creation, (ii) inserting padding bits into (e.g., each) fixed-size data blocks or entire transport blocks, (iii) creating or updating one or more data block headers to include information derived with grant arrival, e.g., 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 entire transport block.

MAC multiplexing and transport block creation may be provided. The WTRU may determine, for example at the time of grant reception, 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) before the grant is ready to be transmitted. The WTRU may select a subset of the data blocks to be transmitted in the grant. The selection criteria may be, for example, based on one or more of the following: (i) the selected data block may contain data from the stream, logical channel, or service indicated in the grant, the data block being allowable based on the grant (e.g., where the grant allows multiple streams) or the data block being a fixed-size data block created based on prior knowledge of the data block size; (ii) the WTRU may service the grant, for example, by including the data block on a first-come-first-served basis, whether on a single flow, logical channel, service, or on one or more (e.g., all) flows, logical channels, or services; and/or (iii) the WTRU may service grants based on some QoS related parameters.

MAC multiplexing may occur, for example, according to TTL. For example, the WTRU may insert all data blocks in increasing order of TTL.

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

MAC multiplexing may occur, for example, according to the relationship between data blocks. For example, the WTRU may perform the 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 packets. The WTRU may include the relevant data blocks within the same transport block, e.g., due to an indication of a preference or requirement from the QoS information.

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

The WTRU may determine the URLLC grant (e.g., autonomously). For example, the WTRU may autonomously determine that permission may be granted (e.g., should or must be granted) for transmission data for one or more particular flows, logical channels, services. The WTRU may restrict (e.g., only) the data blocks associated with these flows/logical channels/services to be selected and included in the transport block.

The difference between TB size and the grant size can be minimized. For example, the WTRU may select an available data block, whereby the difference between the grant size and the TB size may be minimized. A combination of available data blocks for transmission that yields such a minimization of differences may be used.

The WTRU may use a selection criterion, for example, whether it creates a fixed-size data block or whether the size of the data block is dynamically adjusted (e.g., as permissions arrive).

A data block ACK/NACK may be provided. A WTRU may be configured to transmit a transport block containing one or more data blocks, e.g., each with its own CRC, referred to as a data block CRC. The transport block may carry its own CRC, which may be referred to as a TB CRC. The encoder may be configured to insert a CRC of smaller length into (e.g., each) encoded block, e.g., to achieve power savings by early detection of decoding failure.

A Transport Block (TB) NACK may occur, for example, when a preconfigured ratio or number of data blocks is erroneous. The network may (e.g., correctly) receive the transport block (e.g., all associated data blocks) without error, in which case it may be configured to transmit an ACK to the WTRU on the dedicated control channel. The network may detect errors associated with the transport blocks (e.g., due to receiving one or more of the data blocks in error). The network may be configured to determine whether to transmit an ACK or NACK (e.g., HARQ-ACK) to the associated TB transmission, e.g., 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, the TRP may be configured to transmit a NACK when more than 50% of the data blocks are erroneous. The motivation may be (e.g. only) to trigger HARQ retransmissions when (e.g. statistically) it is expected that there may be HARQ combining gain. Otherwise, erroneous data blocks may be retransmitted (e.g. only) more advantageously, e.g. at the cost of additional feedback signaling or additional delay (e.g. for the RLC or ARQ entity to 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. This special case may represent an ACK or NACK for the entire TB.

One or more of the example procedures described herein may be partially or fully performed or applied at the network or the WTRU, for example, when the network transmits multiple data blocks to the WTRU. The WTRU may be configured with a ratio or number of erroneous data blocks above which the WTRU transmits HARQ-NACKs.

A fast aggregate data block status report may be provided for ultra-low latency retransmissions. For example, the base station may be configured to provide fast status report feedback of the data block to trigger data block retransmission, which may be a new transmission from the 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.

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 (e.g., one) data block in an associated uplink transmission. The aggregate data block ACK/NACK message may be transmitted by the TRP, e.g. over 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 another example (e.g., another), the TRP may transmit an aggregate data block Ack/Nack message on a set of resources associated with resources of an associated UL transmission.

In one example, the TRP may schedule an aggregate data block Ack/Nack message 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, a WTRU may be configured to transmit an aggregate data block Ack/Nack message (e.g., only) when scheduled by a TRP.

In one example, a similar approach described for the uplink may be applied to the downlink. The TRP may be configured to transmit a plurality of 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 for or needed for an aggregate data block Ack/Nack message in DCI associated with an associated transmission. The WTRU may receive an aggregate data block Ack/Nack message grant and may transmit the grant on an associated resource. The WTRU may be configured to not transmit the aggregate data block Ack/Nack message, for example, when DCI is not scheduled. The network may (e.g., alternatively) configure a set of resources dedicated to aggregate data block Ack/Nack transmission.

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

The size of the aggregate data block Ack/Nack message may be variable between TTIs, although its size may be known to the network, e.g. due to scheduling grants. The WTRU may be configured to transmit the appropriate format of the aggregate data block Ack/Nack message, e.g., after the associated DCI.

Flexible grant sizes may be allowed, for example, when satisfying PDUs assembled prior to receiving a grant. For example, a WTRU performing MAC PDU assembly before grant assignment may flexibly use the resulting one or more grants to fit (tailor) the assembled MAC k 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.

The grant may last for a number of 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, e.g., whereby a portion of the grant over a given TTI, subframe, frequency block, etc., may be a unit (unit) portion of the total grant. The WTRU may use a subset or multiple units of the grant and may provide an indication to the network whether and when it has completed the use of the grant, e.g., to allow the network to determine the total size of the transport blocks transmitted.

In one example, a WTRU may receive a grant of x resource blocks that may occur repeatedly over y consecutive TTIs. The x resource blocks may be the same in each of the y consecutive TTIs. The x resource blocks may (e.g., alternatively) vary from one TTI to the next, e.g., to provide 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) rules indicated in the license itself; (iii) (iii) a WTRU connects to a cell or TRP prior to admission using rules defined by broadcast or dedicated signaling and/or (iv) cell or TRP specific rules that may potentially be provided through an access table or similar system information specific to the system signature.

In one example, the y value may not be defined and the grant may continue indefinitely until the WTRU indicates.

The WTRU may perform PHY layer coding and modulation of the MAC PDU to be assembled, e.g., upon receiving the grant, according to the modulation and coding provided in the grant. The WTRU may receive a (e.g., 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.

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

The WTRU may indicate the termination/size of the Transport Block (TB) to the network. For example, the WTRU may indicate to the network, e.g., at any time during or after the grant process, the number of consecutive TTIs that it may (e.g., would) use and (e.g., therefore) the termination of the transport block, e.g., to inform the network of the size of the transport block transmitted. The WTRU may indicate the termination of the transport block to the network, for example, using one of the following procedures: (i) the WTRU may indicate the number of TTIs 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 for the network using the 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 a portion 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.

The WTRU may decide to combine the 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 use a combination of these grants to transmit a single TB, for example, after receiving multiple grants in the same subframe or TTI.

The WTRU, for example, after being provided with separate grants with potentially different transmission parameters (e.g., MCS, coding, power, etc.), may select a set of parameters associated with one of the grants, e.g., to perform modulation and coding on the entire TB, e.g., if it causes the TB to be transmitted on the entire set of resources. For example, the WTRU may select the grant that results in the fewest total data bits transmitted, e.g., to allow it to transmit TBs 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 coded TB resulting after the WTRU makes the selection does not fully occupy the entire combination of resources.

The WTRU may not need to indicate the selected transmission parameters for performing the transmission. The WTRU may (e.g., alternatively) signal the selected transmission parameters using PHY signaling. The WTRU may indicate the selected transmission parameters, for example, by transmitting an index that may be indicative of the permissions selected for the transmission parameters. The association between the indicated index and the permissions may be defined, for example, using static rules. 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 the attributes associated with the grant itself in PHY layer signaling. For example, the WTRU may provide a modulation index of the grant whose transmission parameters may be (e.g., will be) used to transmit the entire grant.

The WTRU may decide to combine resources or initial transmission and retransmission. For example, the WTRU may combine the resources allocated to the WTRU for initial transmission and retransmission of a TB, e.g., to transmit a single TB instead of multiple TBs.

The WTRU may be provided with resources for final retransmission (e.g., in case of transmission failure), for example, explicitly or implicitly. The WTRU may indicate this to the network (e.g., when the TB occupies more resources than provided for initial transmission), for example, by using one or more procedures described herein for UL indication.

The WTRU may encode the entire transport block according to the modulation and coding that is allowed. The WTRU may transmit a portion of a transport block on resources used for 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 fully transmitted.

The WTRU may perform retransmission of TBs on a new resource or set of resources scheduled by the network, e.g., when transmission and retransmission of TBs on multiple resources associated with the UL fail. For example, when the size of a single grant may fit the TB size, the WTRU may retransmit the entire TB on the single grant provided by the network.

The WTRU may send an indication to allocate more resources to the full TB transmission. For example, the WTRU may transmit a portion of the TB in a network-provided grant 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 part of the TB when the network provides permission. The grant may be dedicated, for example, to resolving remaining data associated with the transport block, among other things.

The transport block can be generated early. In one example, a 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 a particular resource, where the signaling may include a grant received from downlink control information. Pre-generation is possible, for example when used in conjunction with variable transmission durations.

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

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

In one example, the size may be determined from an explicit indication from the physical layer, MAC, or RRC signaling, e.g., potentially for each type of service or transport block. For example, a WTRU may be signaled a MAC PDU size of 3000 bits for a first transport channel and 10000 bits for a second transport channel.

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

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

The target duration of the transmission may be determined, for example, from an explicit indication from the physical layer, MAC, or RRC signaling. A target duration may be provided for each type of transport channel. The WTRU may set the size of the MAC PDU, e.g., so that the duration for transmission of the MAC PDU may (e.g., may) match or approximately match the target duration to the set of transmission parameters employed. This approach may ensure that the (e.g., required or maximum) duration of transmission of the MAC PDU remains relatively close to the target, although other transmission parameters applicable to transmission of the MAC PDU may differ from the set of employed transmission parameters (e.g., due to radio condition changes).

Conditions may be provided or otherwise known to pre-generate additional MAC PDUs. For example, the WTRU may pre-generate (e.g., only) 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, predefined or derived from physical layer, MAC, or RRC signaling; (ii) the amount of data in the unprocessed pre-generated MAC PDU (which may include one or more new MAC PDUs to be pre-generated) does not exceed the second threshold.

In one example, the second threshold may be predefined or derived from physical layer, MAC, or RRC signaling. The threshold may (e.g., alternatively) be based on an amount of data that may be transmitted within a target duration of the employed set of transmission parameters. The employed set of transmission parameters may be derived, for example, according to one or more of the techniques described herein. In one example, the WTRU may pre-generate 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 be, for example, predefined or derived from physical layer, MAC, or RRC signaling.

A pre-generated MAC PDU may be transmitted. For example, the WTRU may receive signaling (e.g., a grant) that allows transmission of one or more MAC PDUs in the resource. For example, when the WTRU is operating in an unlicensed band, the transmission may be conditional, e.g., based on a clear channel assessment condition. One or more MAC PDUs may have been previously generated, for example, in accordance with one or more techniques described herein.

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 already be provided before the signaling allowing the transmission of the MAC PDU. The WTRU may determine a required transmission duration, e.g., so that a sufficient number of resource elements are available for mapping modulation symbols. The determination may take into account one or more parameters and/or any (e.g., desired) reference signals and/or physical control information to be multiplexed with the higher layer data. The WTRU may perform the transmission accordingly.

In one example, the WTRU may transmit control information to assist the receiver in determining the transmission duration. For example, the WTRU may provide an indication of a 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 another example, the WTRU may provide an indication in a symbol (e.g., last or following last) of the transmission indicating that the transmission is not to continue. In another example, the WTRU may multiplex control information in predefined resources that occur in (e.g., each) time unit (e.g., in each subframe), indicating whether the transmission continues in subsequent time units.

The WTRU may receive the maximum transmission duration, for example, as part of the grant or from previous signaling. The WTRU may, for example, perform one or more of, for example, the following when the transmission duration for the MAC PDU may (e.g., may) exceed a maximum value: (i) discarding the MAC PDU; (ii) (ii) convey 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 that 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, e.g. whereby the total required duration does not exceed a 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 transmit an indication whether to apply the modification and/or the modified value, for example, in uplink or sidelink control information.

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

MAC processing may occur prior to TBS information. For example, the WTRU may perform multiple MAC processing steps before finally determining (e.g., all) transmission parameters (e.g., TBS for transmission and/or for applicable data units (e.g., MAC SDUs)). A MAC PDU may comprise a fragment of a data unit (e.g., by RLC segmentation or MAC segmentation).

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

The WTRU may assemble MAC PDUs for each value (e.g., when there are multiple values) of the configured minimum guaranteed tbs (tbsmin). The WTRU may determine a final value of TBS (TBSfinal) for transmission, for example, based on receiving DCI granting uplink resources.

The TBS may be adapted over time. For example, the WTRU may determine a final set of parameters (TBSfinal) for transmissions guaranteed using a minimum TBS associated with a single transport block, e.g., based on receiving downlink control signaling. The received DCI may explicitly indicate a particular data unit to be used for transmission. The received DCI may indicate a processing time applicable for the transmission, e.g., whereby the WTRU may be instructed to perform a transmission at time n + x μ sec/ms/subframe or some other time unit for DCI received at time n. In one example, the WTRU may determine the minimum duration of TB transmission, e.g., based on the signaled MCS, PRB set, etc., e.g., using a minimum configured TBS value that is greater than the TBS derived from the information contained in the DCI signaling. In one example, the WTRU may determine a minimum duration in time that matches a frame boundary (e.g., matches the end of the DL transmission portion of the subframe), which may fit a minimum configured TBS value that is greater than the TBS derived from the information contained in the DCI signaling. For example, this is conceptually similar to bundling operations over time based on implicit (e.g., a signaled TBS less than the minimum TBS) or explicit (e.g., indicated in DCI) indications. 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., RLC or MAC for multiple segments, e.g., 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 the guaranteed/configured TBS value (e.g., TBSmin) and the TBS value derived from information in the DCI.

The WTRU may add padding to the pre-assembled MAC PDU (e.g., when the size of TBSfinal is greater than TBSmin), e.g., so that the PDU size matches the value TBSfinal. Padding may include one or more MAC CEs, such as BSRs or padding BSRs. 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.

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 TBS of the transmission, or the WTRU may perform only the padded transmission.

The WTRU may include an indication of a desired TBS and/or an increase/decrease indication of the TBS, such as a discrete value within a set of configured values, in the uplink transmission. The indication may be applicable to a particular type of data unit and/or configuration. The indication may be contained in the BSR or provided using a bit in the MAC PDU header that represents an index to a preconfigured set of values. The indication may be a request for an increase in processing time.

The WTRU may use information regarding the minimum guaranteed TBS for determining the LCH (or its equivalent) from which data may be provided (service) for the assembly of MAC PDUs. One or more other aspects, such as latency, keep-alive time, PBR, priority, etc., can be considered, e.g., in accordance with one or more procedures described herein.

Any of the above procedures may be applicable, for example, even when the WTRU performs the assembly of MAC PDUs 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).

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 the received transmission, for example, to determine whether the WTRU performs pre-assembly of MAC PDUs and/or concatenation. The network may change the TTI duration of the transmission, e.g., to ensure that the minimum TBS size may be (e.g., always) available, e.g., even when the radio link and/or HARQ operating point changes. In other words, the network (in addition to MCS and/or frequency based adaptation, for example) may (also) perform WTRU transmission adaptation of data units and/or MAC SDUs over time. For example, the adaptation may be useful when the network may (e.g., need 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, e.g., after receiving a null MAC PDU (e.g., including padding only) and/or receiving an indication that the current TBS is not sufficient.

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

In one example, the WTRU may determine one or more parameters associated with the transmission, for example, based on decoding of the control channel. The WTRU may perform the determination, for example, based on parameters for decoding attempts that are deemed successful in its results. The WTRU may determine success, for example, based on a successful CRC validation of the received DCI. The DCI may indicate uplink and/or downlink transmission.

The one or more parameters may correspond to a set of parameters. The WTRU may use a procedure to determine one or more of a plurality of sets of parameters. The set may be a configuration aspect of the WTRU. For example, one or more parameters (e.g., sets) may correspond to transmissions characterized by higher reliability, lower latency, best effort type transmissions, or another type of service, such as paging, system information reception, broadcast transmissions, and so forth. The set may correspond to a SOM.

Decoding the control channel may correspond to a blind decoding attempt. The WTRU may perform one or more decoding attempts, e.g., each attempt using a different set of decoding aspects (e.g., parameters and/or procedures). The decoding aspects may include a set and/or amount of physical resources for the channel (e.g., control channel elements), an Aggregation Level (AL), a size of the 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.

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

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

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

Robustness can be signaled in the grant. For example, the WTRU may receive signaling (e.g., implicit or explicit reception) in the DCI indicating that transmissions associated with a particular grant may be performed based on different sets of parameters associated with the flow, type of service, SOM, etc. For example, the WTRU may receive (e.g., in the grant) an indication of: a corresponding transmission may be used for the transmission of URLLC data (if any) and the transmission parameters may be adapted and/or selected accordingly, e.g. to allow for a more robust transmission and/or a lower latency.

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

The WTRU may determine a robustness level of the received grant, for example, based on the decoded DCI. The WTRU may determine such a level of robustness, for example, based on one or more of the following: (i) characteristics that result in a successful decoding attempt, such as one or more of: an AL associated with the successfully decoded DCI, a size of a CRC associated with the successfully decoded DCI, a CRC polynomial associated with the successfully decoded DCI, a CCE (or initial CCE) associated with the successfully decoded DCI, a search space (or beginning thereof) and/or an associated control channel type, time/frequency resources and/or identification associated with the successfully decoded DCI; (ii) (ii) a received DCI format and/or (iii) an explicit indication in a field in a DCI format.

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

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

In one example, the WTRU may determine the robustness level based on the size of the CRC (successfully decode this DCI). For example, an 8-bit CRC may indicate that a normal robustness level (e.g., a first set of transmission parameters) is used and a 16-bit or 32-bit CRC may indicate that a higher robustness level (e.g., a second set of transmission parameters) is used.

The transmission parameters may be selected based on the robustness level. For example, the WTRU may select transmission parameters to use for UL transmissions associated with the grant depending on the signaled robustness level. The selection may be based on, for example, predefined rules or may be configured by the network (e.g., in RRC signaling). The selection may be (e.g., also) combined with other processes, such as one or more of the processes described herein. In one example, the selection may be based on, for example, one or more of the following: (i) physical resources are used for uplink transmissions (e.g., when the determination of the set of applicable resources corresponding to the transmission is not itself relevant to the determination); (ii) the type of data being transmitted (e.g., when the data selection itself is not relevant 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., TTL of the data).

In one example, the WTRU may determine different parameter values based on whether the robustness level indicates normal or reliable transmission, for example. 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 the determined set of applicable PRBs; (iv) a HARQ process type; (v) applicable processes for generating and/or transmitting (e.g., when the DCI schedules DL transmission) or receiving (e.g., when the DCI schedules UL transmission) HARQ feedback; (vi) power boosting and/or prioritization of power (e.g., when DCI schedules UL transmissions) and/or (vii) framing and/or frame structure (e.g., TTI duration) may be applied. The WTRU may perform reception/transmission of data according to the determined set of parameters.

Systems, methods, and measures (e.g., aspects of entities, interfaces, and procedures in the WTRU and/or network layers L1, L2, L3) for low latency MAC PDU assembly in wireless systems, such as 5gFLEX are disclosed. Latency may be reduced, for example, by the WTRU determining network transmission parameters and signaling before transmission permission. The WTRU may receive the MCS, resource ranges, etc. prior to the grant, e.g., for use in a subsequent grant. The data block may be incrementally created/encoded prior to licensing. Data units may be segmented, assembled and multiplexed, for example, based on the data block size that allows MAC and RLC processing prior to admission. Flexible grant sizes may be provided for early generation of transport blocks prior to grant. A minimum guaranteed TBS may be signaled to allow early generation of MAC PDUs. The transmission parameters may be selected prior to the grant, for example using a blind decoding or DCI reception process.

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

A WTRU may refer to an identity of a physical device, or an identity of a user, such as a subscription-related identity, e.g., an MSISDN, a SIP URI, or the like. The WTRU may refer to an application-based identity, such as a username that may be used per application.

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., a WTRU and a network) to implement the functions. The processes described above may be implemented in a computer program, software, and/or firmware integrated into a computer-readable medium for execution by a computer and/or processor.

The processes described above 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 over a wired or wireless connection) and computer readable storage media. Examples of the computer readable storage medium include, but are not limited to, Read Only Memory (ROM), Random Access Memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal magnetic disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, an RNC, and/or any host.

Claims

1. A wireless transmit/receive unit (WTRU), comprising:

a processor configured to:

determining a robustness level of an uplink transmission using Downlink Control Information (DCI) associated with the downlink grant;

determining configuration information associated with the robustness level;

determining one or more uplink transmission parameters for the uplink transmission based at least in part on the configuration information; and

a transceiver configured to:

receiving the DCI associated with the downlink grant; and

transmitting one or more uplink transmission parameters determined based on the configuration information associated with the determined robustness level.

2. The WTRU of claim 1, wherein the processor is further configured to receive the DCI indicating the downlink grant.

3. The WTRU of claim 1, wherein the robustness level indicates one or more of: a reliability level of the uplink transmission and a quality of service (QoS) of the uplink transmission.

4. The WTRU of claim 1, wherein the processor is configured to determine the robustness level using the DCI by:

determining a DCI format for the DCI; and

determining the robustness level using the DCI format.

5. The WTRU of claim 1, wherein the processor is configured to determine the robustness level using the DCI by determining the robustness level using an explicit indication in the DCI.

6. The WTRU of claim 1, wherein the one or more uplink transmission parameters include one or more of: physical Uplink Control Channel (PUCCH) information indicating PUCCH resources for transmitting hybrid automatic repeat request (HARQ) feedback; HARQ information indicating a type of HARQ feedback; HARQ feedback information indicating a method for generating the HARQ feedback; a power control parameter for the uplink transmission; frame information indicating a frame structure; and Transmission Timer Interval (TTI) information indicating a TTI duration.

7. The WTRU of claim 1, wherein the one or more uplink transmission parameters include one or more of: MCS information indicating a Modulation and Coding Scheme (MCS), resource information indicating a set of physical resource blocks associated with the uplink transmission, power information associated with the uplink transmission, transmission timing information for the uplink transmission, and transmission Timer Time Interval (TTI) information indicating a TTI duration associated with the uplink transmission.

8. The WTRU of claim 1, wherein the processor is further configured to determine that a maximum transmission power exceeds a threshold.

9. The WTRU of claim 8, wherein the processor is further configured to determine a prioritization of power for the uplink transmission using the robustness level.

10. The WTRU of claim 9, wherein the processor is configured to send the uplink transmission using the one or more uplink transmission parameters by sending the uplink transmission using the one or more uplink transmission parameters and the prioritized ordering of power for the uplink transmission.

11. A method performed by a wireless transmit/receive unit (WTRU), the method comprising:

determining configuration information associated with the robustness level;

determining one or more uplink transmission parameters for the uplink transmission based at least in part on the configuration information;

receiving the DCI associated with the downlink grant; and

transmitting the one or more uplink transmission parameters determined based on the configuration information associated with the determined robustness level.

12. The method of claim 11, wherein the method further comprises receiving the DCI indicating the downlink grant.

13. The method of claim 11, wherein the robustness level indicates one or more of: a reliability level of the uplink transmission, and a quality of service (QoS) of the uplink transmission.

14. The method of claim 11, wherein determining the robustness level using the DCI comprises:

determining a DCI format for the DCI; and

determining the robustness level using the DCI format.

15. The method of claim 11, wherein the method comprises: determining the robustness level using the DCI by determining the robustness level using an explicit indication in the DCI.

16. The method of claim 11, wherein the one or more uplink transmission parameters comprise one or more of: physical Uplink Control Channel (PUCCH) information indicating PUCCH resources for transmitting hybrid automatic repeat request (HARQ) feedback; HARQ information indicating a type of HARQ feedback; HARQ feedback information indicating a method for generating the HARQ feedback; a power control parameter for the uplink transmission; frame information indicating a frame structure; and Transmission Timer Interval (TTI) information indicating a TTI duration.

17. The method of claim 11, wherein the one or more uplink transmission parameters comprise one or more of: MCS information indicating a Modulation and Coding Scheme (MCS), resource information indicating a set of physical resource blocks associated with the uplink transmission, power information associated with the uplink transmission, transmission timing information for the uplink transmission, and transmission Timer Time Interval (TTI) information indicating a TTI duration associated with the uplink transmission.

18. The method of claim 11, wherein the method further comprises: it is determined that the maximum transmit power exceeds a threshold.

19. The method of claim 18, wherein the method further comprises: determining a prioritization of power for the uplink transmission using the robustness level.

20. The method of claim 19, wherein sending the uplink transmission using the one or more uplink transmission parameters comprises: transmitting the uplink transmission using the one or more uplink transmission parameters and the prioritized ordering of power of the uplink transmission.

21. A wireless transmit/receive unit (WTRU) for generating a Medium Access Control (MAC) Protocol Data Unit (PDU) for an unlicensed frequency band, the WTRU comprising:

a processor configured to:

determining a size of the MAC PDU using a transmission duration and a set of transmission parameters for a previous transmission in an unlicensed frequency band;

generating the MAC PDU using the determined size of the MAC PDU;

receiving transmission information indicating that the generated MAC PDU should be transmitted; and

transmitting a transmission in the unlicensed frequency band, wherein the transmission includes the generated MAC PDU.