Wireless transmit / receive unit and method performed by a wireless transmit / receive unit in a wireless communication network

Abstract

A wireless transmit / receive unit (WTRU) and corresponding method are disclosed.SOLUTION: The WTRU is in communication with a wireless communication network and comprises a memory, a receiver configured at least to receive a configuration including one or more characteristics for one or more transmission modes (TMs) of the WTRU, a processor configured at least to dynamically select at least one TM of the one or more TMs for a transmission of an uplink data unit based on one or more data transfer requirements and the one or more TM characteristics, identify at least one transport channel associated with the at least one TM, and map the uplink data unit to the at least one transport channel, and a transmitter configured at least to send the transmission of the uplink data unit to one or more devices of the wireless communication network.SELECTED DRAWING: Figure 16

Description

[Technical Field]

[0001] The present invention relates to a wireless transmit / receive unit and a method performed by the wireless transmit / receive unit in a wireless communication network. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 315,165, filed March 30, 2016, the entire contents of which are incorporated herein by reference for all purposes as if fully set forth herein.

[0003] Mobile communications is continuously evolving and is already on the threshold of the fifth generation, or 5G. As with previous generations, new use cases are heavily contributing to setting the requirements for new systems. It is expected that the 5G air interface may enable improved broadband performance (IBB), industrial control and communications (ICC), vehicular applications (V2X, V2V), and / or massive machine-type communications (mMTC).

[0004] The deployment of 5G networks can include standalone systems and / or a phased approach, for example, in combination with existing deployments and / or existing technologies (e.g., LTE and / or its evolutions). The combination with existing technologies can include radio access network components and / or core network components. In initial deployments using a phased approach, it is expected that 5G systems can be deployed under the umbrella of existing LTE systems. In this LTE-assisted deployment scenario, the LTE network can provide basic cellular functions, such as mobility to / from LTE, and core network functions. As more commercial 5G deployments become available, it can be expected that deployments can evolve to become independent of 5G systems, perhaps without relying on LTE. This second phase of 5G can be expected to target new (e.g., previously undefined) use cases, possibly with stringent reliability and / or latency requirements. Summary of the Invention

[0005] 5G protocol stack functionality may be provided. The protocol stack functionality may include one or more of header compression, security, integrity protection, encryption, segmentation, concatenation, (de)multiplexing, automatic repeat request (ARQ), mapping to spectrum operating modes (SOMs), modulation and / or coding, hybrid ARQ (HARQ), and / or mapping to antennas / physical channels. A wireless transmitting and receiving device (WTRU) may be configured with a (e.g., single) HARQ entity and / or one, multiple, or multiple SOMs. The WTRU may have a (e.g., single) HARQ buffer for managing HARQ signals received across the SOMs. The WTRU may be configured to transmit / receive various types of traffic across the SOMs. The WTRU may be configured with at least one HARQ entity for one, multiple, or each configured SOM. A logical channel (LCH) may be assigned to any of the SOMs.

[0006] Logical channels may be multiplexed together based on latency requirements. Mapping of LCHs to SOMs may be based on SOM capabilities and / or LCH requirements. The WTRU may determine the mapping based on predefined rules. The mapping may be based on various types of traffic and / or SOM capability requirements. Radio bearers may be mapped to one or more SOMs. A WTRU may be configured with a set of SOMs it may use, perhaps for one or more or each radio bearer. The WTRU may dynamically determine which SOM to use, perhaps based on radio conditions, buffer status, and / or other parameters, for example. Incompatible multiplexing of LCHs may be reduced and / or avoided based on using a (e.g., single) transport block (TB) (e.g., limited by data ratios) and / or one or more or multiple TBs mapped to the same physical layer (PHY). Traffic may be prioritized, perhaps based on latency requirements, for example.

[0007] A wireless transmit / receive unit (WTRU) may be in communication with a wireless communication network. The WTRU may comprise a memory. The WTRU may comprise a receiver. The receiver may be configured to receive a configuration. The configuration may include one or more characteristics for one or more transmission modes (TMs) of the WTRU. The WTRU may comprise a processor. The processor may be configured to dynamically select at least one TM of the one or more TMs for transmission of an uplink data unit. The dynamic selection may be based on one or more data transfer requirements and / or one or more TM characteristics. The processor may be configured to identify at least one transport channel associated with the at least one TM. The processor may be configured to map the uplink data unit to the at least one transport channel. The WTRU may comprise a transmitter. The transmitter may be configured to at least send a transmission of the uplink data unit to one or more devices of the wireless communication network. [Brief explanation of the drawings]

[0008] [Figure 1A] FIG. 1 is a system diagram of an exemplary communication system. [Figure 1B] 1B is a system diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A. [Figure 1C] 1B is a system diagram of an example radio access network and an example core network that may be used within the communication system shown in FIG. 1A. [Figure 1D] 1B is a system diagram of another example radio access network and an example core network that may be used within the communication system shown in FIG. 1A. [Figure 1E] 1B is a system diagram of another example radio access network and an example core network that may be used within the communication system shown in FIG. 1A. [Figure 2]FIG. 1 illustrates an exemplary LTE user plane protocol stack. [Figure 3] FIG. 1 illustrates an exemplary LTE medium access control (MAC) architecture. [Figure 4] FIG. 2 illustrates an exemplary system bandwidth. [Figure 5] 1 illustrates an exemplary spectrum allocation in which different subcarriers may be at least conceptually assigned to different modes of operation ("SOM"). [Figure 6] FIG. 1 illustrates exemplary timing relationships for time division duplexing (TDD). [Figure 7] FIG. 1 illustrates exemplary timing relationships for frequency division duplexing (FDD). [Figure 8] FIG. 1 illustrates an exemplary deployment with and / or without LTE support. [Figure 9] FIG. 1 illustrates exemplary functionality of a 5G protocol stack at a high level. [Figure 10] FIG. 1 illustrates an exemplary high-level mapping between logical channels (LCHs) and SOMs. [Figure 11] 1 illustrates an exemplary (eg, single) HARQ entity per WTRU technique in the context of a complete protocol stack and / or in the context of all functionality of the protocol stack. [Figure 12] FIG. 1 illustrates an exemplary high-level mapping between an LCH and a SOM. [Figure 13] A diagram illustrating an exemplary (e.g., single) HARQ entity per SOM technique in the context of a complete protocol stack and / or in the context of all functionality of the protocol stack. [Figure 14] FIG. 1 illustrates an exemplary high-level mapping between an LCH and a SOM. [Figure 15] A diagram showing an exemplary (e.g., single) HARQ entity per SOM technique in the context of a complete protocol stack, e.g., in the context of all functionality of the protocol stack. [Figure 16] 1 illustrates an example of a WTRU controller dynamically matching a data unit to a TrCH that can meet the QoS requirements of the data unit. DETAILED DESCRIPTION OF THE INVENTION

[0009] A detailed description of exemplary embodiments will now be described with reference to various figures. While this description provides detailed examples of possible implementations, it should be noted that these details are intended as examples and do not limit the scope of the present application in any way.

[0010] 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 multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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), and / or single-carrier FDMA (SC-FDMA).

[0011] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (which may be collectively or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, and / or consumer electronics devices, etc.

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

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

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

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

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

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

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

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

[0020] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and 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 that may utilize the same RAT as the RANs 103 / 104 / 105 or a different RAT.

[0021] One or more of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating 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 can employ cellular-based radio technology and a base station 114b that can employ IEEE 802 radio technology.

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

[0023] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0025] 1, the transmit / receive element 122 is shown as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

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

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

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

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

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

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

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

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

[0034] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to an MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and land-line communication devices.

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

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

[0037] 1D is a system diagram of the RAN 104 and core network 107 according to an embodiment. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 103 may also communicate with the core network 106.

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

[0039] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and / or scheduling of users on the uplink and / or downlink, etc. As shown in FIG. 1D, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

[0041] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and / or selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

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

[0043] The serving gateway 164 may also be connected to a PDN gateway 166 that 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.

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

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

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

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

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

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

[0050] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for supporting user authentication and user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and / or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and land-line communication devices. Additionally, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

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

[0052] In view of Figures 1A-1E and the corresponding descriptions thereof, one or more or all of the functions described herein with respect to one or more of WTRUs 102a-d, base stations 114a-b, Node Bs 140a-c, RNCs 142a-b, MSC 146, SGSN 148, MGW 144, GGSN 150, eNode-Bs 160a-c, MME 162, serving gateway 164, PDN gateway 166, base stations 180a-c, ASN gateway 182, AAA 186, MIP-HA 184, and / or gateway 188, etc., may be performed by one or more emulation devices (not shown) (e.g., one or more devices configured to emulate one or more or all of the functions described herein).

[0053] One or more emulation devices may be configured to perform one or more, or all, functions in one or more modalities. For example, one or more emulation devices may perform one or more, or all, functions while fully or partially implemented / deployed as part of a wired and / or wireless communications network. One or more emulation devices may perform one or more, or all, functions while temporarily implemented / deployed as part of a wired and / or wireless communications network. One or more emulation devices may perform one or more, or all, functions without being implemented / deployed as part of a wired and / or wireless communications network (e.g., in test scenarios in a test lab and / or tests performed on a non-deployed (e.g., test) wired and / or wireless communications network and / or one or more deployed components of a wired and / or wireless communications network, etc.). One or more emulation devices may be test equipment.

[0054] By way of example, and not limitation, one or more of the following acronyms may be referenced herein: Δf subcarrier spacing 5gFlex 5G Flexible Radio Access Technology 5gNB 5GFlex NodeB ACK Acknowledgment BLER Block Error Rate BTI Basic TI (one or more integer multiples of the symbol period) CB Contention-based (e.g., access, channel, resource) CoMP Coordinated Multipoint Transmission / Reception CP cyclic prefix CP-OFDM (relies on a cyclic prefix) Traditional OFDM CQI Channel Quality Indicator CN Core Network (e.g., LTE Packet Core) CRC Cyclic Redundancy Check CSI Channel State Information CSG Limited Subscriber Group DC Dual Connectivity D2D Device-to-Device transmission (e.g., LTE sidelink) DCI Downlink Control Information DL Downlink DM-RS demodulation reference signal DRB Data Radio Bearer EPC Evolved Packet Core FBMC Filtered Band Multi-Carrier

[0055] By way of example, and not limitation, one or more of the following acronyms may be referenced herein: FBMC / OQAM: FBMC technique using offset quadrature amplitude modulation FDD Frequency Division Duplex FDM frequency division multiplexing HARQ Hybrid Automatic Repeat Request (ARQ) ICC Industrial Control and Communications ICIC Inter-cell interference cancellation IP Internet Protocol LAA License Assisted Access LBT Listen-Before-Talk LCH Logical Channel LCP Logical Channel Prioritization LLC Low Latency Communications LTE (e.g., 3GPP LTE R8 and above) Long Term Evolution MAC Media Access Control NACK Negative Acknowledgment MBB Massive Broadband Communications MC Multi-Carrier MCS Modulation and Coding Scheme MIMO Multiple Input Multiple Output MTC Machine Type Communication NAS non-access layer OFDM Orthogonal Frequency Division Multiplexing

[0056] By way of example, and not limitation, one or more of the following acronyms may be referenced herein: OOB Out of Band (radiated) P cmax Total available WTRU power at a given TI PHY physical layer PRACH Physical Random Access Channel PDU Protocol Data Unit PER Packet Error Rate PL Path Loss (Estimated) PLMN Public Land Mobile Network PLR Packet Loss Rate PSS primary synchronization signal QoS Quality of Service (from a physical layer perspective) QCI QoS Class Identifier RAB Radio Access Bearer RACH Random Access Channel (or Procedure) RF Radio Front End RNTI Radio Network Identifier RRC Radio Resource Control RRM Radio Resource Management RS reference signal RTT Round Trip Time

[0057] By way of example, and not limitation, one or more of the following acronyms may be referenced herein: SCMA Single Carrier Multiple Access SDU Service Data Unit SOM Spectral Operation Mode SS Sync Signal SSS secondary synchronization signal SRB Signaling Radio Bearer SWG Switching Gap (in self-contained subframes) TB Transport Block TBS Transport Block Size TDD Time Division Duplex TDM time division multiplexing TI time interval (one or more integer multiples of BTI) TTI Transmission Time Interval (one or more integer multiples of TI) TrCH Transport Channel TRP Sending / Receiving Point TRx Transceiver UCI Uplink control information (e.g., HARQ feedback, CSI) UFMC Universal Filtered MultiCarrier UF-OFDM Universal Filtered OFDM UL Uplink URC Ultra-Reliable Communications URLLC Ultra-reliable and low latency communication V2V vehicle-to-vehicle communication V2X vehicle communications WLAN Wireless Local Area Network and related technologies (IEEE802.xx domain)

[0058] 2 shows an example LTE user plane protocol stack. The radio protocol architecture for the LTE user plane shown in FIG. 2 may include PDCP, RLC MAC, and / or physical layer (PHY) sublayers. One or more, or each, sublayer may be responsible for a subset of the functionality used to transfer data from the WTRU to the eNB (and, e.g., vice versa) over the wireless medium.

[0059] The MAC sublayer provides several services and / or functions, including, but not limited to, multiplexing / demultiplexing of MAC service data units (SDUs) belonging to one or more or different logical channels into / from transport blocks (TBs) delivered to / from the physical layer on transport channels, scheduling information reporting, error correction via HARQ, prioritized handling between logical channels for at least one WTRU, prioritized handling between WTRUs by dynamic scheduling, MBMS service identification, transport format selection, and / or padding.

[0060] Figure 3 shows an exemplary LTE MAC architecture. As shown, various functions interact with each other. Logical channel prioritization (specified for the uplink) and / or multiplexing may be used to determine and / or select the set of data (MAC protocol data units (PDUs)) to be transmitted in a particular TTI.

[0061] Hybrid ARQ (HARQ) functionality can control fast retransmissions over the air. HARQ can rely on fast acknowledgment / negative acknowledgment (ACK / NACK) feedback provided by the physical layer to determine whether a retransmission is useful. Due to the inherent delay in LTE associated with providing feedback (e.g., the receiver may decode and / or transmit the feedback), one or more or multiple parallel HARQ processes (e.g., up to eight in LTE) can be used. One or more or each HARQ process can carry different MAC PDUs and / or can operate independently with respect to transmission and / or retransmission.

[0062] HARQ retransmissions on the LTE uplink can be synchronous. For example, there may be a fixed time relationship between transmission and retransmission of a given MAC PDU. On the LTE downlink, HARQ operation may be asynchronous, and / or the HARQ process ID may be explicitly signaled in the downlink signaling grant. HARQ ACK / NACKs may be sent by the WTRU at fixed timing (e.g., after 4 TT) relative to the associated transmission.

[0063] The 5G Flexible Air Interface may be provided to enable improved broadband performance (IBB), industrial control and communications (ICC), vehicular applications (V2X), and / or massive machine-type communications (mMTC). The 5G Flexible Air Interface may provide support for ultra-low transmission latency (LLC). Air interface latency may be as short as 1 ms round-trip time (RTT) and / or may provide support for any TTI between 100 μs and 250 μs (perhaps less than 250 μs, for example). The 5G Flexible Air Interface may provide support for targeted but low-priority ultra-low access latency (e.g., the time from initial system access to the completion of transmission of the first user plane data unit). The 5G Flexible Air Interface may provide support for end-to-end (e2e) latency of less than 10 ms. The 5G Flexible Air Interface may provide support for ultra-reliable transmission (URC). The goal may be 99.999% delivery success and / or service availability.

[0064] The 5G flexible air interface may provide support for mobility at speeds ranging from 0 to 500 km / h. At least IC and / or V2X may have a packet loss rate of less than 10e-6. Support for machine-type communication (MTC) operation (including narrowband operation) may be provided. The air interface may support narrowband operation (e.g., using less than 200 kHz), extended battery life (e.g., up to 15 years of autonomy), and / or minimal communication overhead for small and / or infrequent low-data-rate data transmissions, e.g., in the range of 1 to 100 kbps, with access latencies of a few seconds to a few hours.

[0065] A flexible wireless access system may be provided. OFDM is used as the basic signal format for data transmission in LTE and / or IEEE 802.11. OFDM can divide the spectrum into one or more or many parallel orthogonal subbands. One or more or each subcarrier is shaped using a rectangular window in the time domain, resulting in a sinc-shaped subcarrier in the frequency domain. OFDMA may be associated with perfect frequency synchronization and / or strict control of uplink timing alignment within the period of a cyclic prefix to maintain orthogonality between signals and / or minimize inter-carrier interference. Such strict synchronization may not be compatible in a system in which a WTRU is connected to multiple access points (e.g., simultaneously). Power reduction may be applied to uplink transmissions to comply with spectral emission requirements for adjacent bands, especially in the presence of aggregation of fragmented spectrum for WTRU transmissions.

[0066] Some of the shortcomings of conventional OFDM (CP-OFDM) may be addressed by more stringent RF requirements for implementation and / or when operating using large amounts of contiguous spectrum without the need for aggregation. CP-based OFDM transmission schemes may result in a downlink physical layer for 5G that is similar to that of legacy systems, e.g., modifications primarily to pilot signal density and / or location.

[0067] A number of principles applicable to the design of flexible radio access for 5G are described herein, and the description herein is not intended to limit in any way the applicability of the methods further described herein to other wireless technologies and / or to wireless technologies using different principles where applicable.

[0068] 5G Flexible Radio Access Technology (5gFLEX) downlink transmission schemes can be based on multicarrier waveforms characterized by high spectral containment (e.g., lower sidelobes and / or lower out-of-band (OOB) emissions). Multicarrier (MC) waveform candidates for 5G may include, but are not limited to, OFDM-OQAM (Offset Quadrature Amplitude Modulation) and / or Universal Filtered Multicarrier (UFMC) (UF-OFDM).

[0069] A multicarrier modulation waveform can divide the channel into subchannels and / or modulate data symbols on subcarriers in these subchannels. In OFDM-OQAM, filters can be applied to the OFDM signal in the time domain on a per-subcarrier basis to reduce OOB.

[0070] In UFMC (UF-OFDM), filters can be adapted to the OFDM signal in the time domain to reduce OOB. Filtering is applied per subband to use spectral fractions, which can reduce complexity and / or make UF-OFDM somewhat more practical to implement.

[0071] However, the methods described herein are not limited to the waveforms described herein and / or may be applicable to other waveforms. The waveforms described herein are further used for illustrative purposes.

[0072] Such waveforms can enable multiplexing in frequency of signals with non-orthogonal properties (e.g., different subcarrier spacings) and / or coexistence of asynchronous signals without the need for complex interference-rejection receivers. It can facilitate aggregation of fragmented portions of spectrum in baseband processing as a lower-cost alternative to implementing it as part of RF processing.

[0073] Different waveforms may coexist within the same band. mMTC narrowband operation may be supported, for example, using single-carrier multiple access (SCMA). Different waveforms within the same band, for example, combinations of CP-OFDM, OFDM-OQAM, and / or UF-OFDM, may be supported for all aspects and / or downlink and / or uplink transmissions. Such coexistence may include, for example, transmissions using different types of waveforms simultaneously, with some overlap, and / or consecutively in the time domain, between different WTRUs and / or between transmissions from the same WTRU.

[0074] Hybrid-type waveforms may be supported. For example, the waveform and / or transmission may support at least one of a cyclic prefix (CP) duration that varies from case to case (e.g., from transmission to transmission), a combination of a CP and a low-power tail (e.g., a zero tail), and / or a form of hybrid guide interval (e.g., using a low-power CP and an adaptive low-power tail). Such waveforms may support dynamic variation and / or control of additional aspects, such as how filtering is applied (e.g., whether filtering is applied at the edge of the spectrum used to receive any transmission for a given carrier frequency, and / or at the edge of the spectrum used to receive transmissions associated with a particular SOM, and / or on a per-subband and / or per-group thereof basis).

[0075] The uplink transmission may have the same or a different waveform as the downlink transmission. The multiplexing of transmissions to and from different WTRUs within the same cell may be based on FDMA and / or TDMA.

[0076] The 5gFLEX radio access system may be characterized by a very high degree of spectrum flexibility, allowing deployment in different frequency bands with different characteristics, including different duplex configurations, different and / or variable sizes of available spectrum, including contiguous and / or non-contiguous spectrum allocations in the same or different bands, it may support variable timing aspects, including support for one or more TTI lengths, and / or support for asynchronous transmission.

[0077] The 5gFLEX radio access system can provide flexibility in duplexing arrangements. TDD and / or FDD duplexing schemes can be supported. For FDD operation, supplemental downlink operation can be supported using spectrum aggregation. FDD operation can support full-duplex FDD and / or half-duplex FDD operation. For TDD operation, downlink (DL) / uplink (UL) allocation can be dynamic. DL / UL allocation may not be based on a fixed DL / UL frame configuration. The length of the DL and / or UL transmission interval can be configured for each transmission opportunity.

[0078] The 5gFLEX radio access system may provide bandwidth flexibility, for example enabling the possibility of different transmission bandwidths on the uplink and / or downlink ranging anywhere from the nominal system bandwidth up to a maximum value corresponding to that system bandwidth.

[0079] For single-carrier operation, the supported system bandwidth may include, for example, 5, 10, 20, 40, and / or 80 MHz. In some cases, the supported system bandwidth may be any bandwidth within a given range, for example, from a few MHz to 160 MHz. The nominal bandwidth may in some cases be one or more fixed possible values. Narrowband transmissions up to 200 kHz may be supported within the operating bandwidth for MTC devices.

[0080] As used herein, system bandwidth may include the maximum portion of spectrum that may be managed by the network for a given carrier. For such a carrier, the portion that minimally supports a WTRU for cell acquisition, measurements, and / or initial access to the network may correspond to the nominal system bandwidth. A WTRU may be configured with a channel bandwidth within the entire system bandwidth. Figure 4 shows an example system bandwidth. The WTRU's configured channel bandwidth may or may not include the nominal portion of the system bandwidth as shown in Figure 4.

[0081] Bandwidth flexibility is achieved because the set of applicable RF requirements for a given maximum operating bandwidth within a band can be met without introducing additional allowed channel bandwidth for that operating band to efficiently support baseband filtering of frequency domain waveforms.

[0082] Methods for configuring, reconfiguring, and / or dynamically changing the channel bandwidth of a WTRU for single carrier operation, as well as methods for allocating spectrum for narrowband transmissions within a nominal system, system, and / or configured channel bandwidth, are contemplated.

[0083] The physical layer of the 5G air interface may be band agnostic and / or may support operation in licensed bands below 5 GHz and unlicensed bands in the 5-6 GHz range. For operation in unlicensed bands, a Listen-Before-Talk (LBT) Cat4-based channel access framework similar to LTE License-Assisted Access (LAA) may be supported.

[0084] Methods for scaling and / or managing (eg, scheduling, addressing resources, broadcasted signals, measurements) cell-specific and / or WTRU-specific channel bandwidth for any spectrum block size are contemplated.

[0085] The 5gFLEX radio access system may provide flexible spectrum allocation. Downlink control channels and / or signals support FDM operation. A WTRU may acquire a downlink carrier by receiving a transmission using a nominal portion of the system bandwidth. For example, a WTRU may not initially be required to receive a transmission covering the entire bandwidth managed by the network for that carrier.

[0086] The downlink data channels may be allocated over a bandwidth that may or may not correspond to the nominal system bandwidth, with no other restrictions than being within the WTRU's configured channel bandwidth. For example, a network may operate a carrier having a 12 MHz system bandwidth that uses a 5 MHz nominal bandwidth to allow devices supporting up to 5 MHz of maximum RF bandwidth to acquire and / or access the system, and potentially allocate +10 to -10 MHz of the carrier frequency to other WTRUs supporting up to 20 MHz worth of channel bandwidth.

[0087] FIG. 5 shows an example spectrum allocation in which different subcarriers may be at least conceptually assigned to different operating modes (Spectrum Operating Modes (SOMs)). Different SOMs may be used to meet different requirements for different operations. The SOM may include at least one of subcarrier spacing, TTI length, one or more reliability aspects, e.g., HARQ processing aspects, and / or secondary control channels. The SOM may include a specific waveform and / or processing aspects supporting coexistence of different waveforms within the same carrier using, e.g., FDM and / or TDM. Coexistence of FDD operation within a TDD band may be supported, e.g., in a TDM and / or similar manner.

[0088] The WTRU may be configured to perform transmissions according to one or more SOMs. For example, the SOM may correspond to a transmission that can use at least one of a specific TTI duration, a specific initial power level, a specific HARQ processing type, a specific upper limit on HARQ reception / transmission, a specific configuration of a set of resources for WTRU operation (e.g., a managed network), a specific physical channel (uplink and / or downlink), a specific operating frequency, band and / or carrier, a specific waveform type, and / or a transmission according to a specific RAT (e.g., according to legacy LTE and / or 5G transmission methodology). The SOM may correspond to one or more of a QoS level and / or associated aspects, such as a maximum / target latency and / or a maximum / target block error rate (BLER), etc.

[0089] The SOM may correspond to a spectrum region and / or a particular control channel and / or aspect thereof (e.g., search space and / or downlink control channel (DCI) type, etc.). For example, a WTRU may be configured with one or more or each of URC-type services, LLC-type services, and / or MBB-type services. The WTRU may have a configuration for an SOM for system access and / or for transmission / reception of L3 control signaling (e.g., radio resource control (RRC) signaling) in a portion of the spectrum associated with the system, e.g., in a nominal system bandwidth as described herein.

[0090] As described herein, a SOM may be a characterization of a block of physical resources in time, space, and / or frequency. The SOM may include an applicable set of operations. A transmission mode (TM) may correspond to an instance (e.g., a specific instance) of a SOM characterization, perhaps in terms of, for example, a specific configuration. For example, a specific configuration may include one or more of an applicable TTI duration, a set of physical resource blocks, a type of waveform, etc. A transmission mode (TM) may also correspond to control signaling. For example, a TM may be referenced by downlink control signaling on a control channel. A transmission mode (TM) may correspond to a configuration of a WTRU, thereby enabling the WTRU to determine one or more parameters applicable for processing a transmission (UL or DL), perhaps, for example, when the WTRU receives an allocation of one or more resources. The configuration of a TM (e.g., an applicable TM) may indicate to the WTRU how to receive a WTRU-specific reference signal, how to interpret downlink control signaling received on the PDCCH, how to interpret precoding bits, etc.

[0091] Spectrum aggregation may be supported for single-carrier operation, enabling a WTRU to support transmission and / or reception of one or more or multiple transport blocks across contiguous and / or non-contiguous sets of physical resource blocks (PRBs) within the same operating band. A (single) transport block may be mapped to separate PRB sets. Support may be provided for simultaneous transmissions associated with different SOM requirements.

[0092] Multi-carrier operation may be supported using contiguous and / or non-contiguous spectrum blocks within the same operating band and / or across two or more operating bands. Aggregation of spectrum blocks using different modes, e.g., FDD and / or TDD, and / or using different channel access methods (e.g., licensed and / or unlicensed sub-6 GHz band operation), may be supported. Support may be provided for methods to configure, reconfigure, and / or dynamically change a WTRU's multi-carrier aggregation.

[0093] Flexible framing, timing, and / or synchronization may be supported: Downlink and / or uplink transmissions may be organized into radio frames characterized by some fixed aspects (e.g., location of downlink control information) and / or some variable aspects (e.g., transmission timing, supported transmission types).

[0094] The basic time interval (BTI) may be expressed in terms of one or more integer numbers of symbols and / or symbol periods, which may be a function of the subcarrier spacing applicable to the time / frequency resource. For FDD, the subcarrier spacing is the number of subcarrier periods for a given frame relative to the uplink carrier frequency f UL and downlink carrier frequency f DL may differ depending on the

[0095] A transmission time interval (TTI) may be the minimum time supported by the system between successive transmissions. Successive transmissions may be, for example, a downlink (TTI) for an uplink transceiver (UL TRx), possibly excluding any preamble (e.g., if applicable) and / or possibly including any control information (e.g., DCI for the downlink and / or uplink control information (UCI) for the uplink). DL) may be associated with different transport blocks (TBs) for a given SOM. A TTI may be expressed as an integer number of one or more BTIs. A BTI may be unique and / or associated with a given SOM.

[0096] Supported frame durations may include, but are not limited to, 100 μs, 125 μs (1 / 8 ms), 142.85 μs (1 / 7 ms is 2 nCP LTE OFDM symbols), and 1 ms to allow alignment with conventional LTE timing structures.

[0097] The frame is divided into two parts by the associated carrier frequency (f for TDD). UL +f for DL ​​and FDD DL ) for a fixed time period t preceding any downlink data transmission (DL TRx). dci The frame may start with downlink control information (DCI). For TDD duplexing (e.g., TDD duplexing only), the frame may include a downlink portion (DCI and / or DL ​​TRx) and / or an uplink portion (UL TRx). A switching gap (swg), if present, may precede the uplink portion of the frame.

[0098] For FDD duplexing (e.g., FDD duplexing only), a frame can include a downlink reference TTI and / or one or more TTIs for the uplink. The start of the uplink TTI is an offset (t) applied from the start of the downlink reference frame, which may overlap with the start of the uplink frame. offset ) can be derived using

[0099] For TDD, 5gFLEX may support device-to-device transmission (D2D) / vehicle communication (V2X) / sidelink operation in a frame by including respective downlink control and / or forward transmissions in the DCI+DL TRx portion (e.g., if semi-static allocation of the respective resources is used) and / or in the DL TRx portion (e.g., only in that portion) (e.g., in the case of dynamic allocation), and / or by including respective reverse transmissions in the UL TRx portion.

[0100] With respect to FDD, 5gFLEX may support D2D / V2X / sidelink operations in the UL TRx portion of the frame by including respective downlink control, forward, and / or reverse transmissions in the UL TRx portion (e.g., dynamic allocation of respective resources may be used).

[0101] Figure 6 illustrates an example frame structure and / or frame timing relationship for TDD duplexing. Figure 7 illustrates an example frame structure and / or frame timing relationship for FDD duplexing.

[0102] The WTRU may receive downlink control information (DCI) from at least one device of one or more devices of a wireless communications network. The WTRU may identify a resource allocation indicated by the DCI for transmission of an uplink data unit. The WTRU may determine a quality of service (QoS) requirement for the transmission of the uplink data unit. The WTRU may determine whether the resource allocation indicated by the DCI for transmission of the uplink data unit at least meets or does not meet the QoS requirement. The WTRU may, perhaps, for example, determine not to utilize the resource allocation indicated by the DCI for transmission of the uplink data unit when the resource allocation indicated by the DCI does not meet (e.g., is determined not to meet) the QoS requirement.

[0103] The WTRU may identify a resource allocation corresponding to at least one TM of the one or more TMs for transmission of the uplink data unit. The WTRU may determine to utilize a resource allocation corresponding to at least one TM of the one or more TMs for transmission of the uplink data unit (e.g., instead of the resource allocation indicated by the DCI for transmission of the uplink data unit), perhaps when, for example, the resource allocation indicated by the DCI cannot (e.g., is determined to not) meet the QoS requirements.

[0104] Scheduling functionality may be supported at the MAC layer. A scheduling mode may be selected. Available scheduling modes may include network-based scheduling for strict scheduling with respect to resources, WTRU-based scheduling that is more flexible with respect to timing and / or transmission parameters of downlink and / or uplink transmissions, and / or timing and / or transmission parameters. Scheduling information may be valid for a single and / or one or more or multiple TTIs.

[0105] Network-based scheduling may allow the network to tightly manage the available radio resources allocated to different WTRUs, e.g., to optimize the sharing of such resources. Dynamic scheduling may be supported.

[0106] WTRU-based scheduling may enable a WTRU to opportunistically access uplink resources as needed with minimal latency within a set of shared and / or dedicated uplink resources allocated by the network (e.g., dynamically and / or non-dynamically). Synchronized and / or unsynchronized opportunistic transmissions may be supported. Contention-based and / or contention-free transmissions may be supported.

[0107] Logical channel prioritization may be performed based on data available for transmission and / or resources available for uplink transmission. Multiplexing of data with different QoS requirements within the same transport block may be provided.

[0108] Forward error correction (FEC) and / or block coding may be performed. Transmissions may be encoded using several different encoding methods. Different encoding methods may have different characteristics. For example, an encoding method may generate a sequence of information units. One or more or each information unit and / or block may be self-contained. For example, an error in the transmission of a first block may not impair the receiver's ability to successfully decode the second block, particularly if the second block is error-free and / or if sufficient redundancy is found in the second block and / or another block that has been at least partially successfully decoded.

[0109] An example of an encoding method may include raptor / fountain coding, in which a transmitter may include a sequence of N raptor codes. One or more such codes may be mapped in time to one or more transmit "symbols." A "symbol" may correspond to one or more sets of information bits, e.g., one or more octets. Such encoding may be used to add FEC to a transmission, thereby allowing the transmission to use N+1 and / or N+2 raptor codes (and / or symbols, perhaps assuming, e.g., one raptor code-symbol relationship). This may make the transmission more resilient to the loss of one "symbol," e.g., due to interference from another transmission that overlaps in time and / or puncturing.

[0110] A WTRU may receive and / or detect one or more system signatures. The system signature may include a signal structure using a sequence. Such signals may be similar to synchronization signals, e.g., an LTE primary synchronization signal (PSS) and / or secondary synchronization signal (SSS). Such a signature may be unique to a particular node (and / or transmit / receive point (TRP)) within a given area, or it may be common to multiple such nodes (and / or TRPs) within the area. Such aspects may be unknown and / or irrelevant to the WTRU. The WTRU may determine and / or detect the system signature sequence and / or further determine one or more parameters associated with the system. For example, the WTRU may derive an index therefrom and / or use such index to look up the associated parameters, e.g., in a table such as the access table described below. For example, the WTRU may use the received power associated with the signature for open-loop power control, e.g., to set an initial transmit power, if the WTRU determines that it can access (and / or transmit) using applicable resources of the system. For example, the WTRU may use the timing of a received signature sequence (e.g., a preamble on a physical random access channel (PRACH) resource) for purposes of timing a transmission, for example, if the WTRU determines that it can access (and / or transmit) using the applicable ones of the system.

[0111] A WTRU may be configured with a list of one or more entries. Such a list may be referred to as an access table. Such a list may be indexed. One or more or each entry may be associated with a system signature and / or its sequence. Such an access table may provide initial access parameters for one or more areas. One or more or each such entry may provide one or more parameters that may be useful for performing initial access to the system. Such parameters may include at least one of a set of one or more random access parameters (e.g., including applicable physical layer resources (e.g., PRACH resources) in time and / or frequency), an initial power level, and / or physical layer resources for receiving a response). Such parameters may include access restrictions, including, for example, public land mobile network (PLMN) identity and / or closed subscriber group (CSG) information. Such parameters may include information related to routing, such as applicable routing areas. One or more or each such entry may be associated with and / or indexed by a system signature. In other words, one such entry may possibly be common to multiple nodes (and / or TRPs). The WTRU may receive such an access table by transmission using dedicated resources, e.g., by RRC configuration, and / or by transmission using broadcasted resources. In the latter case, the periodicity of the transmission of the access table may be relatively long (e.g., up to 10240 ms), e.g., it may be longer than the periodicity of the transmission of the signature (e.g., in the range of 100 ms).

[0112] Figure 8 shows an example deployment with and / or without LTE support. In an initial deployment using a phased approach, a 5G system may be deployed under the umbrella of an existing LTE system. In this LTE-supported deployment scenario, the LTE network can provide basic cellular functions, such as mobility to / from LTE, and core network functions. The deployment can evolve so that the 5G system is independent and independent of LTE, e.g., can become unsupported.

[0113] A protocol architecture and / or associated functionality for a 5gFLEX system may be implemented. Although described in the context of a 5G RAT, the described solutions may also be applicable to other RAT evolutions, such as LTE and / or Wi-Fi.

[0114] A standalone 5gFLEX radio access network may be provided. For example, the standalone 5gFLEX radio access network may not be supported by an LTE network. Although a solution based on a standalone 5G deployment architecture is described herein, the solution provided herein may also be applicable to an LTE-supported architecture.

[0115] The 5G protocol stack can provide transport services for IP packets from a source node to a destination node over a wireless medium. Figure 9 illustrates example functionality of a 5G protocol stack at a high level. Depending on the implementation and / or configuration, the functionality of the protocol stack can include one or more of header compression, security, integrity protection, encryption, segmentation, concatenation, multiplexing, ARQ, mapping to a spectrum operating mode (SOM), modulation and / or coding, HARQ, and / or mapping to antennas / physical channels.

[0116] A logical channel (LCH) can represent a logical association between data packets and / or PDUs. LCH may have a different and / or broader meaning than similar terms in previous generations, such as LTE systems. For example, the logical association may be based on data units associated with the same bearer and / or the same SOM and / or slice (e.g., a processing path using a set of physical resources). For example, the association may be characterized by one or more of a chain of processing functions, applicable physical data (and / or control) channels (and / or instances thereof), and / or instantiations of a protocol stack, which may include one or more of a centralized portion, such as PDCP (e.g., PDCP only) and / or some portion beyond the physical layer processing portion (e.g., radio front (RF) end), and / or another portion closer to the edge (e.g., MAC / PHY and / or RF only in the TRP), which may be separated by a front hauling interface.

[0117] A logical channel group (LCG) may include a group of LCHs and / or equivalents (e.g., as described above). LCG may have a different and / or broader meaning than similar terms in prior generations, such as LTE systems. The grouping may be based on one or more criteria. For example, the criteria may be that one or more LCHs have similar priority levels applicable to (and / or associated with) one or more of one or more or all LCHs of the same LCG (as in legacy), the same SOM (and / or its type), and / or the same slice (and / or its type). For example, the association may be characterized by one or more of a chain of processing functions, an applicable physical data (and / or control) channel (and / or its instance), and / or an instantiation of a protocol stack, which may include a centralized portion (e.g., PDCP only and / or some portion other than RF) and / or another portion closer to the edge (e.g., MAC / PHY and / or RF only in the TRP) that may be separated by a fronthauling interface.

[0118] A transport channel (TrCH) may include a (e.g., specific) set of processing steps and / or functions applied to data information that may affect one or more transmission characteristics over the air interface.

[0119] A TrCH may be defined (e.g., for LTE) with one or more or 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 / or a Random Access Channel, which may or may not carry user plane data. The primary transport channel for carrying user plane data may be, for example, the DL-SCH and / or the UL-SCH for the downlink and / or uplink, respectively.

[0120] A TrCH may include an expanded set of requirements supported by the interface and / or support for one or more or multiple transport channels (e.g., for user and / or control plane data) for one or more WTRU devices. TrCH may have a different and / or broader meaning than similar terms in prior generations, such as LTE systems. For example, transport channels for URLLC (e.g., URLLCH), mobile wideband (MBBCH), and / or machine type communications (MTCCH) may be defined for downlink transmissions (e.g., DL-URLLCH, DL-MBBCH, and / or DL-MTCCH) and / or uplink transmissions (e.g., UL-URLLCH, UL-MBBCH, and / or UL-MTCCH).

[0121] For example, one or more or multiple TrCHs may be mapped to different sets of physical resources (e.g., PhCHs) belonging to the same SOM. This mapping may be advantageous, for example, to support simultaneous transmission of traffic with different requirements over the same SOM. For example, the URLLCH may be transmitted along with the MTCCH at the same time, for example, when a WTRU may be configured with a SOM (e.g., a single SOM).

[0122] The WTRU may be configured with one or more parameters associated with a characterization of how data may be transmitted. The characterization may represent constraints and / or requirements that the WTRU may be expected to conform to and / or enforce. The WTRU may perform different actions and / or adjust its behavior depending on conditions associated with the data based on the characterization. The parameters may include, for example, time-related aspects (e.g., a packet's (e.g., per-packet) time-to-live (TTL), which represents the time before which the packet may be transmitted to meet, and / or an acknowledgment of meeting latency requirements, etc.), rate-related aspects, and / or configuration-related aspects (e.g., absolute priority). The parameters may change over time, for example, while packets and / or data may be pending for transmission.

[0123] Some protocol architectures may support the listed features. For example, HARQ retransmissions may be handled. One or more SOMs may be selected to perform retransmissions. The SOMs may include different carriers in the same and / or different bands, different RATs, and / or different modes of 5G PHY. Furthermore, the term logical channel (LCH) in the following may not be associated with a conventional logical channel.

[0124] A WTRU may be configured with (e.g., a single) HARQ entity. The WTRU may have (e.g., a single) HARQ buffer for managing HARQ signals received across SOMs. A WTRU may be configured to transmit / receive any type of traffic across any SOM. Figure 10 shows, at a high level, an example mapping between an LCH and one or more SOMs. For example, in Figure 10, there may be one (e.g., at least one) HARQ entity per WTRU. Retransmissions may occur on any SOM.

[0125] FIG. 11 illustrates an exemplary (e.g., single) HARQ entity per WTRU technique in the context of a complete protocol stack and / or full functionality of the protocol stack. The exemplary protocol stack here (this example assumes M IP packet flows (and / or radio bearers) and N SOMs) may include header compression and / or security mechanisms, security, segmentation / concatenation / ARQ, (de)multiplexing / prioritization, HARQ / SOM / carrier mapping, and / or modulation, physical channel (PhCH) / SOM mapping. The header compression and / or security mechanisms take IP packets as input and / or, depending on configuration, perform header compression and / or apply security (e.g., integrity protection, encryption). There may be as many blocks as there are radio bearers, which in this example is M. Security may reside in a separate network node, e.g., far from the 5G cell / TRP.

[0126] The segmentation / concatenation / ARQ may be responsible for segmenting and / or concatenating PDUs according to available radio resources. The ARQ functionality may ensure delivery. The demultiplexing / prioritization on the transmitting side (e.g., uplink to WTRU) may be responsible for multiplexing one or more radio bearer PDUs together and / or prioritizing transmission according to rules. The multiplexing and / or prioritization rules may be configured by higher layers. The output of the demultiplexing / prioritization may be mapped to a SOM for transmission. Re-segmentation may be performed when needed. On the receiving side (e.g., downlink to WTRU), the demultiplexing / prioritization demultiplexes the SDUs and / or pushes them to the appropriate segmentation / concatenation / ARQ entity. The HARQ / SOM / carrier mapping controls the HARQ protocol and / or routing to the appropriate SOM. The HARQ entity may perform physical layer retransmissions and / or route PDUs to one, multiple, or any SOM. For modulation, the mapping to PhCH / SOM is determined by the selected SOM. (1···N) The coded bits may be mapped to appropriate symbols that are mapped to appropriate resources on at least one physical channel of the plurality of physical channels.

[0127] The WTRU may be configured with a HARQ entity for one, more, or each configured SOM. Logical channels may be assigned / mapped to any SOM. Retransmissions may occur on one, more, or none of the SOMs. FIG. 12 shows an example high-level mapping between LCHs and one or more SOMs. One, more, or each logical channel may be mapped to a SOM. A SOM may be associated with at least one (e.g., dedicated) HARQ entity. The WTRU may be configured to perform HARQ retransmissions in the same SOM of the original transmission. ARQ retransmissions may occur on different SOMs. The WTRU may select (e.g., the best) SOM for one, more, or each given PDU instant (perhaps according to predefined criteria, for example). FIG. 13 shows an example of a (e.g., single) HARQ entity per SOM technique in the context of the complete protocol stack and / or in the context of all functionality of the protocol stack. This example protocol stack (this example assumes M IP packet flows (and / or radio bearers) and N SOMs) may include one or more of the following: header compression and / or security mechanisms, security, segmentation / concatenation / ARQ, (de)multiplexing / prioritization, HARQ / to SOM / carrier mapping, and / or modulation, PhCH / to SOM mapping. Similar functions may be performed as described herein in connection with FIG. 11. The SOM / carrier mapping may occur before the HARQ entity. There may be N HARQ entities, e.g., one or more or at least one for each SOM. One or more HARQ retransmissions may occur in the same SOM.

[0128] The LCH may be mapped to a SOM using predefined rules. The mapping may be based on various types of traffic and / or one or more SOM capability requirements. For example, a 10 ms TTI SOM may not be able to reach the 1 ms latency requirement and / or may not be assigned to a channel carrying that traffic. Figure 14 shows an example high-level mapping between the LCH and the SOM. For example, at least one HARQ entity may be assigned per SOM. The LCH may be mapped to one, multiple, or a single SOM.

[0129] FIG. 15 illustrates an example of a (e.g., single) HARQ entity per SOM technique in the context of a complete protocol stack and / or full functionality of the protocol stack. As illustrated, the example protocol stack (this example assumes M IP packet flows (and / or radio bearers) and N SOMs) can include header compression and / or security mechanisms, security, segmentation / concatenation / ARQ, (de)multiplexing / prioritization, HARQ / SOM / mapping to carrier, and / or modulation, and PhCH / SOM mapping. Similar functionality can be performed as described herein in connection with FIG. 11. Although located below segmentation / concatenation / ARQ, the SOM / carrier mapping block may be located higher in the stack, even before header compression / security. After SOM / carrier mapping, the WTRU may be configured with at least one set of one or more or each block for one or more or each SOM. The WTRU may perform prioritization on a per-SOM basis. The WTRU may independently determine traffic priority for (e.g., one or more or each) SOM. ARQ retransmissions may occur in the same SOM. The WTRU may be configured by higher layers (e.g., RRC signaling and / or other) with the SOM for (e.g., one or more or each) radio bearer.

[0130] A radio bearer may be mapped to one or more SOMs. A WTRU may be configured with a set of SOMs it may use for one or more or each radio bearer. The WTRU may dynamically decide which SOM to use based on radio conditions, buffer status, and / or other parameters.

[0131] Temporary upgrades and / or downgrades of LCHs may be performed. LCHs and / or radio bearers may maintain their general characteristics (e.g., priority and / or bandwidth requirements, etc.) but may be upgraded, for example, for a temporary period of time, to a SOM with higher priority and / or lower latency. Specifically, a service may generally have certain characteristics, but the service may be "temporarily upgraded." A logical channel may be moved to a different SOM for the time period in which it is temporarily upgraded. The underlying PHY treatment of the same radio bearer / logical channel may be changed.

[0132] Multiplexing, prioritization, and / or mapping of data from different logical channels to SOM / TrCH may be performed. The MAC PDU creation and / or prioritization process may be initiated based on one or more triggers.

[0133] The WTRU may perform autonomous transmission under certain circumstances, such as when time-critical data arrives at the WTRU that takes priority over other ongoing (cell-scheduled) transmissions. The WTRU may not be provided with the size and / or transport block parameters used by the cell. In response to a trigger from within the MAC layer and / or higher layers, the WTRU may multiplex one or more higher layer SDUs that may require immediate transmission into one or more MAC PDUs that are sent to the PHY layer for transmission. The autonomous creation of a transport block may be triggered by one or more of the following: arrival of a time-critical packet at the MAC layer and / or upper layers; QoS-based parameters associated with one or more packets and / or data below a threshold; periodic (e.g., upon expiration of a timer); creation and / or (re)configuration of latency-critical and / or other services and / or creation and / or (re)configuration of a SOM; based on an indication from the MAC layer and / or upper layers that one of its buffers is no longer empty; and / or based on buffer occupancy information from the MAC layer and / or upper layers; and / or a HARQ entity indicating that a retransmission of a MAC PDU may be useful.

[0134] The WTRU may receive a trigger at one or more or each time that a low latency SDU currently in its buffer has its time to live (TTL) shorter than a certain threshold. At the time of MAC PDU creation, the WTRU may select SDUs whose TTL is less than the threshold and / or multiplex them into the same MAC PDU. If there are restrictions associated with mapping logical channels to transport channels, separate MAC PDUs may be created for sending to the PHY layer while adhering to those restrictions. The WTRU may select SDUs whose TTL is less than the threshold (e.g., periodically, possibly based on a timer) and / or perform multiplexing of these SDUs onto one or more MAC PDUs.

[0135] Mapping and / or multiplexing of LCHs to TrCHs / SOMs may be performed. The WTRU may be configured to transmit data from different logical channels on different SOMs in the uplink. One or more or multiple logical channels may be transmitted together on a (e.g., single) transport channel (TrCH). The WTRU may be configured to receive scheduling information from the network indicating which logical channels to map to one or more or each TrCH and / or SOM. The WTRU may dynamically (e.g., autonomously) determine transmission parameters (including SOM and / or multiplexing).

[0136] Multiplexing and / or prioritization of one, more, or multiple LCHs to one, more, or each TrCH / SOM may be performed. At least one LCH is associated with at least one SOM. The terms SOM and TrCH may be used interchangeably herein. TrCHs may be associated with the same SOM. Although some techniques are described in the context of associating or mapping LCHs to SOMs, similar techniques may also be applicable for multiplexing one, more, or multiple LCHs.

[0137] The WTRU may determine transmission parameters based on predetermined transport and / or service types. The MAC layer of the WTRU may multiplex a particular set of logical channels and / or service types onto a set of different transport channels such that a set of logical channels and / or services can be mapped to (e.g., only) a particular transport channel. The WTRU may then create transport blocks and / or data blocks that are forwarded to the PHY layer such that a given transport channel can receive (e.g., only receive) data associated with that transport channel and / or logical channels that can be mapped to that transport channel and / or its SOM.

[0138] The mapping between logical channels and associated transport channels may be statically defined based on a standardized mapping. For example, a set of transport channels T1, T2, ... TN may correspond to different service levels, service qualities, and / or service guarantees provided by the PHY layer. A set of logical channels L1, L2, ... LM may be defined. The WTRU MAC layer may receive one or more packets from higher layers that may be identified as part of a particular service type S1, S2, ... SM. The WTRU may multiplex several particular logical channels onto particular transport channels based on the standardized mapping. For example, L1, L2 may be multiplexed onto T1, and L3 may be multiplexed onto T3. Packets with service types S1, S2 may be sent onto T1, packets with service type S3 may be sent onto T2, etc.

[0139] The WTRU may determine transmission parameters based on the service type, e.g., ultra-reliable and / or low latency communication (URLLC), MTC, eMBB, etc. One or more specific transport channels may be associated with logical channels / flows / services associated with ultra-reliable communication. A specific transport channel may be associated with low-latency communication. A specific transport channel may be associated with machine-type communication (MTC). A specific transport channel may be associated with mobile broadband communication (MBB). A specific transport channel may be associated with WTRU control information, and / or the last set of specific transport channels may be associated with one or more or all other communications. The mapping between logical channels / flows / services and transport channels may follow association rules.

[0140] The WTRU may determine transmission parameters based on a mapping configuration for each SOM. The mapping of logical channels and / or service types to transport channels may be configurable by the network, e.g., through broadcast or dedicated signaling and / or use of an access table by the WTRU.

[0141] Mapping of multiplexing lists may be performed per SOM. For example, a multiplexing list may be mapped to a SOM. A multiplexing list configuration may be generated for one or more or each LCH in one or more or each SOM. A WTRU may be configured (e.g., via higher layers and / or RRC signaling) with a set of multiplexing rules. For one or more or each LCH, the WTRU may be configured with a set of (e.g., enabled) SOMs to which it may be mapped. For one or more or each SOM and / or one or more or each LCH, the WTRU may be configured with a set of (e.g., other) one or more LCHs with which it may be multiplexed in a TrCH. The network may allow one or more (e.g., specific) LCHs to be multiplexed in a SOM but perhaps not in a different SOM, for example, in some scenarios.

[0142] The WTRU may determine transmission / data forwarding parameters, perhaps based on satisfying LCH requirements, among other scenarios. The WTRU may be configured with a set of requirements for one or more or each LCH. These requirements may include, for example, one or more of latency and / or maximum delay, reliability, average bit rate, guaranteed bit rate, traffic and / or service type (e.g., ultra-low latency / ultra-reliable, MTC, eMBB, voice, video streaming, control information, etc.), and / or QCI, etc.

[0143] The WTRU may be configured and / or itself determine a set of characteristics / capabilities of the configured SOM. These characteristics may include, for example, one or more of: TTI duration, bandwidth, symbol rate, coding characteristics (e.g., rate and / or reliability, etc.), a set of supported modulation and coding schemes (MCSs), HARQ parameters (e.g., maximum number of retransmissions, incremental redundancy vs. Chase combining, etc.), subcarrier spacing, waveforms and / or associated parameters (e.g., cyclic prefix length, guard, preamble, etc.), spectrum licensing mode (e.g., licensed, unlicensed, lightly licensed), type of connectivity (e.g., device-to-device (D2D) and / or wide area network (WAN)), relayed or direct, destination and / or TRP receiver point, set of supported traffic types, and / or set of supported QCIs, etc.

[0144] The WTRU may determine a set of LCHs that can be multiplexed together in a given transport block in a given SOM. For example, the WTRU may determine a mapping of one or more or each LCH to an SOM, possibly based on LCH requirements and / or SOM characteristics. For an LCH, the WTRU may determine whether the characteristics of a particular SOM meet the LCH requirements. The WTRU may determine a (e.g., single) SOM for (e.g., one or more or each) LCH. The WTRU may determine a set of SOMs that can meet one or more LCH requirements for one or more or each LCH.

[0145] For example, the WTRU may compare the latency requirements of the LCH with the minimum latency of the SOM, e.g., based on the TTI length, HARQ feedback delay, and / or other parameters, and / or determine whether the SOM meets the latency requirements. In such a scenario, in particular, the WTRU may determine that the LCH may be mapped to that particular SOM. For example, the WTRU may compare the bit rate requirements of a particular LCH (e.g., with the maximum MCS and / or available and / or configured bandwidth) with the maximum bit rate achievable by the SOM, and / or map the LCH to the SOM, perhaps, e.g., if it meets the requirements.

[0146] The WTRU can determine the mapping of LCHs to SOMs based on matching attributes of the LCHs, SOMs. The WTRU can determine the mapping of LCHs to SOMs based on matching LCH requirements and / or one or more SOM characteristics, e.g., using one or more of the requirements / characteristics described herein. The WTRU can multiplex LCHs into the same SOM based on the destination.

[0147] The WTRU may determine the mapping of LCHs to SOMs based on destinations associated with one or more or each logical channel. For example, some logical channels may be associated with D2D transmissions to a particular device (e.g., L2 address). For example, an LCH may be associated with a particular TRP. The WTRU may configure LCHs associated with the same destination (e.g., D2D, TRP, and / or others) to the associated SOM.

[0148] The WTRU may determine the mapping of LCHs to SOMs based on a set of supported QoS class identifiers (QCIs). The WTRU may be configured with a set of supported QCIs (e.g., for one or more or each SOM). The WTRU may determine a set of SOMs for one or more or each LCH, perhaps based on, for example, the configured LCH QCI. The WTRU may determine that an LCH may be mapped to a SOM when (e.g., only when) there is an exact QCI match. The WTRU may be configured to determine a set of SOMs that at least satisfy the QCI of the LCH.

[0149] The WTRU may determine the mapping of the LCHs to the SOM based on the supported traffic types. The WTRU may be configured with a set of supported traffic types for one or more or each SOM. The WTRU may determine the mapping of one or more or each LCH to the SOM, perhaps based on, for example, the LCH traffic type. For example, a SOM may be configured to support best-effort traffic (e.g., 60 GHz, unlicensed). The WTRU may map the best-effort LCH to that SOM and / or map other types of traffic (e.g., traditional voice, ultra-reliable, and / or other) to a different SOM (e.g., in the 2 GHz band).

[0150] The mapping of LCHs to SOM / TrCHs may be performed dynamically. The transport channel may be selected based on transport layer state / attribute information. The WTRU may select from one or more (e.g., available) transport channels (e.g., T1 and / or T2) to which a particular logical channel may be mapped and / or a particular upper layer packet may be transmitted. The WTRU may make such a decision based on the dynamic state of the transport channels (e.g., at a given time) and / or MAC entity information. The information may include one or more of the current occupancy of the logical channel under consideration (and / or queues associated with one or more or each logical channel), QoS-based parameters associated with data in a given logical channel, such as the TTL of a packet, the TTL of a set of packets, and / or the TTL relative to a threshold, and / or the size of a packet and / or a group of packets.

[0151] 16 shows an example of a WTRU (e.g., a WTRU processor and / or controller) dynamically matching a data unit to a TrCH that can satisfy the QoS requirements of the data unit. One or more or each data unit may have its own QoS requirement (QoS_1, QoS_2, etc.). In some scenarios, one or more data units may have the same QoS requirement. The data unit requirements may include one or more of latency, reliability, data rate and / or transport block size, and / or QCI, etc. The WTRU may be configured with one or more or multiple transport channels, each with their own characteristics with respect to one or more of numerology (e.g., which may include subcarrier spacing and / or associated symbol duration), MCS, coding rate, TTI duration, reliability, HARQ retransmission, and / or delay.

[0152] The WTRU can determine a target TrCH for one or more or each data unit by matching the requirements with the TrCH capabilities. This ensures that the requirements of the data unit are met, perhaps at least to a satisfactory extent. In FIG. 16, the LCH M Data units from the TrCH N For example, if a (particular) data unit of LCH1 with QoS 2 is mapped to TrCH1, its QoS requirement (e.g., QoS 2) may not be met by TrCH1 in this scenario. N May be routed to LCH1 and LCH M Data units (e.g., TrCH N ) may be multiplexed together, perhaps, for example, if the data units have QoS requirements that sufficiently match (e.g., within determined and / or preconfigured tolerances and / or thresholds).

[0153] The WTRU may send one or more or multiple uplink data unit transmissions. For example, the WTRU may send a first uplink data unit and a second uplink data unit transmission. The WTRU may identify a first quality of service for the first uplink data unit transmission. The WTRU may identify a second QoS for the first uplink data unit transmission. The WTRU may determine that a difference between the first QoS and the second QoS is within or outside a preconfigured threshold. The WTRU may multiplex the first uplink data unit and the second uplink data unit in a transmission, perhaps, for example, when the difference between the first QoS and the second QoS is within a preconfigured threshold. The second uplink data unit may be multiplexed with the first uplink data unit in a transmission, perhaps up to a preconfigured multiplexing ratio (as described herein), for example.

[0154] The WTRU may receive such dynamic transport layer state information from the PHY layer. For example, the MAC layer may make its mapping decision based on information dynamically provided by the PHY layer and / or statically associated with a particular transport channel and / or transport channel type. Such information may include one or more of the following: the amount of PHY resources available for a particular transport channel; the type of PHY resources available for the transport channel (e.g., contention-based vs. dedicated, and / or TTI used by the transport channel); HARQ information such as the HARQ process type, number, or processes; occupancy of one or more or each process; the status of the available HARQ processes of the associated transport channel (e.g., pending transmission or retransmission); the SOM to which the transport channel is mapped; and / or the maximum transport block size supported for and / or currently allowed for the transport channel.

[0155] One or more transmission channels may be reserved for retransmission. One or more special transport channels may be reserved specifically for the purpose of retransmission by the WTRU. The WTRU may retransmit a PDU using at least one of the reserved transport channels when the transmission of the PDU fails at a layer (e.g., MAC / RLC / other). These transport channels may have specific PHY / MAC attributes, including a shorter TTI and / or an HARQ process type that allows more HARQ transmissions within a shorter time period, a higher coding rate, a lower modulation scheme, and / or a higher transmit power.

[0156] Incompatible multiplexing of LCHs may be avoided or reduced. The WTRU may dynamically determine which set of enabled LCHs may be multiplexed together in the actual transport channel. As used herein, the term "multiplexing" may be equated with the term "segmentation / assembly" and may be used interchangeably.

[0157] The transmission characteristics of large amounts of data may be determined based on the latency requirements associated with small amounts of data. For example, a logical channel with low latency requirements may be multiplexed with a logical channel with much larger latency requirements. LCHs associated with very different reliability requirements may also be multiplexed.

[0158] Multiplexing constraints may be imposed based on logical channels. For example, the WTRU may perform MAC segmentation / assembly over (e.g., only over) MAC SDUs associated with specific logical channels / service types / priorities. For example, the MAC layer may perform separate segmentation / assembly operations for SDUs coming from logical channels and / or upper layer services associated with ultra-low latency, and different segmentation / assembly operations for SDUs associated with high-reliability transmissions.

[0159] A SOM / transport channel for transmission of control information may be selected and / or multiplexed. The MAC layer may transmit different types of control information across different underlying transport channels and / or PHY resource types. For example, MAC CEs may be of different types. Perhaps depending on the MAC CE type, the WTRU may decide whether to transmit such a MAC CE on a given transport channel and / or multiplex the MAC CE with a particular set of MAC SDUs and / or SDU segments.

[0160] For example, a WTRU may have a different MAC CE for transmission of a buffer status report (BSR) associated with its low latency logical channel. The WTRU may transmit a CE such as "ULL MAC CE" over (e.g., only over) a dedicated ULL transport channel (e.g., by piggybacking the MAC CE on a transport block containing a ULL MAC PDU). However, such a restriction may allow non-ULL MAC CEs to be sent with ULL resources and / or require them to be sent using (e.g., only using) non-ULL transport block resources.

[0161] For example, a high priority MAC CE may be associated (e.g., exclusively) with a transport channel dedicated to the transmission of such information, which may be associated with, for example, dedicated PHY resources.

[0162] The WTRU can multiplex LCHs on demand up to a certain percentage of the primary LCH. For example, the WTRU can be configured with a set of parameters that control the amount of data of varying requirements that can be multiplexed together.

[0163] The WTRU may determine a primary LCH and an associated primary LCH set. The primary LCH may be selected by the WTRU based on priority (e.g., using the techniques described herein). The WTRU may determine an associated primary LCH set, which may include LCHs having the same or similar requirements as the primary LCH and / or may be multiplexed with it according to the WTRU configuration. The primary LCH set may be configured by the network (e.g., similar to a multiplexing list) and / or may be determined by the WTRU based on requirements for the LCH. The primary LCH may belong to the primary LCH set. The WTRU may determine a non-primary LCH set, which may include a set of LCHs that may not be part of the primary LCH and / or may be multiplexed with the primary LCH.

[0164] The WTRU may be configured with a ratio ρ that indicates the maximum amount of data from the non-primary LCH set that may be allowed to be multiplexed with the selected primary LCH set in a given transport block. For example, if the WTRU determines that N bits from the primary LCH set are to be transmitted in a particular transport block, then the WTRU may multiplex up to N<ρ×N bits from the non-primary LCHs in the same transport block. In an embodiment, the non-primary LCHs and / or the primary LCH may include (e.g., include only) LCHs for which data is available in the associated buffer.

[0165] The WTRU may multiplex the multiplexed LCHs based on their associated data types. The WTRU may multiplex the LCHs such that differences in data types can be minimized. The WTRU may select MAC SDUs for assembly such that the MAC PDU has a minimum proportion of data of a particular type (e.g., logical channel type, service type, latency requirement, etc.) so that the MAC PDU can be associated with that type. For example, the WTRU may ensure that the maximum possible number of low-latency SDUs and / or SDU segments are assembled together and / or minimize the number of non-low-latency segments assembled with low-latency segments.

[0166] The WTRU may associate logical channels, MAC SDUs, and / or SDU segments with specific multiplexing categories and / or classes. The categories and / or classes may be associated with any combination of logical channels, types of data (time-critical vs. high-reliability vs. high-efficiency), stringency of latency requirements for the associated data, and / or QoS-based parameters associated with the data. The WTRU may create MAC PDUs such that a certain minimum percentage of data in the PDU is associated with that category and / or class (e.g., 60% of the data may be associated with time-critical data, where the TTL may be below a certain threshold). Low-latency MAC SDU segments may be mostly placed within PDUs composed primarily of low-latency data. The underlying PHY layer may treat such MAC PDUs with high priority. The categories and / or classes may be defined in a dynamic manner. For example, based on the current data being transmitted, the WTRU may create certain conditions that may define classes.

[0167] The WTRU may multiplex LCHs and / or SDUs based on latency characteristics (e.g., TTL ranges). The WTRU may perform MAC SDU multiplexing by taking into account latency characteristics associated with the SDUs and / or by associating together MAC SDUs that can meet certain QoS-based characteristics.

[0168] For example, the WTRU may assemble MAC SDUs and / or MAC SDU segments that may have the same TTL, possibly when creating a MAC PDU. The WTRU may assemble MAC SDUs and / or MAC SDU segments that may have TTLs that may differ by less than a threshold between each other, possibly when creating a MAC PDU. The resulting MAC PDUs (and / or effectively transport blocks) may be ordered in terms of TTLs and / or TTL ranges.

[0169] The WTRU can multiplex LCHs using differences in latency requirements. For example, the WTRU can multiplex and / or transmit data packets with latency requirements that are separated by ΔLatency or more in the same transport block. The parameter / variable ΔLatency may be a fixed value configured by the network and / or may be fixed in a specification. The parameter / variable ΔLatency may be dynamically and / or semi-dynamically signaled to the WTRU.

[0170] The WTRU may multiplex based on the multiplexed LCH and / or SDU based on the TTI duration to be utilized at the PHY layer. The WTRU may segment / assemble the MAC SDU based on the TTI duration to be utilized for transmission on the PHY layer. The WTRU may associate the MAC SDU and / or logical channel / flow / service with (e.g., a particular) TTI. The SDU may be assembled / segmented such that (e.g., one, more, or all) SDU segments used in creating the MAC PDU can utilize the same TTI value. The SDU segment may effectively be the TTI duration at which the PHY layer transmits the PDU. The TTI associated with a particular MAC SDU may be determined by the WTRU. For example, the TTI may be statically and / or dynamically associated with the logical channel / service type data in the MAC SDU via signaling by the cell and / or based on some internal state of the WTRU. For example, a particular logical channel and / or any logical channel may be configured to utilize a particular TTI value. For example, the TTI utilized may be defined by PHY layer information (e.g., potentially in combination with other methods). For example, the PHY layer may indicate that at a given point in time and / or during a time period, a TTI of 0.5 ms is available and / or may be used for a logical channel group having index x and / or larger. For example, the TTI may be defined by a QoS-based parameter associated with the logical channel. For example, if the TTL for an SDU is less than threshold x, the WTRU may utilize a 2-symbol TTI. If the TTL is greater than threshold x but less than threshold y, the WTRU may utilize a TTI of 0.5 ms, etc. Once a pending SDU with the current TTI value is included, the WTRU may include SDUs associated with a different TTI in the associated grant.

[0171] A WTRU may send one, multiple, or multiple transport blocks (TBs) of an LCH with different requirements using one, multiple, or multiple TrCHs. Data with widely varying requirements may be transmitted simultaneously. A WTRU may transmit one, multiple, or multiple transport blocks, each on its own TrCH (e.g., simultaneously).

[0172] Based on the particular scheduling decision made by the WTRU (e.g., the TTL of such rules, logical channel prioritization (LCP), and / or buffer occupancy), the WTRU may schedule two or more sets of data with very different characteristics and / or with very different service types and / or requirements, etc. The WTRU may transmit MAC PDUs associated with such different service types using different transport formats. The WTRU may transmit different transport blocks using the same grant from the cell and / or the same semi-static resources provided to the WTRU.

[0173] The WTRU may receive (dynamically and / or semi-statically) a grant that may indicate a set of available PHY resources (e.g., the number of transport blocks). The WTRU may receive an indication regarding the radio quality of such resources, for example, via downlink channel state information (CSI) feedback. The WTRU may make an autonomous decision regarding the transport format to utilize when transmitting on these resources (e.g., based on the radio quality associated with these resources).

[0174] The WTRU can partition the grant spectrum for one, more, or each TrCH. The WTRU partitions the PHY resources into separate portions to be associated with one, more, or each of the transport blocks to be transmitted. The WTRU can restrict the partitioning based on specific rules associated with a particular association, such as a carrier or resource block. For example, the WTRU may not be allowed to partition a resource block between two different transport blocks to transmit. The WTRU can associate different transport formats (MCS, HARQ type, TTI, retransmission rule, etc.) with one, more, or each of the transport blocks to be transmitted simultaneously. The WTRU can indicate to the cell the specific transport format to be utilized in the transmission. Such signaling may be included within the transmission itself (e.g., based on the methods described herein). The WTRU may include such signaling in a dedicated control channel used for UL PHY signaling.

[0175] Traffic types may be prioritized in the MAC for UL transmission. Traffic may be associated with different latency requirements, may be mapped to different SOMs, and / or may have different reliability requirements.

[0176] The WTRU may prioritize traffic based on associated latency requirements. For example, the WTRU may select a MAC PDU to be scheduled for transmission based on the time-criticality of the data and / or the time available for data in a previous MAC PDU in which the data is deemed to have missed its timing requirements. For example, the WTRU may select a MAC PDU for transmission based on QoS-based parameter values ​​and / or ranges associated with and / or potentially assigned to the MAC PDU by the WTRU.

[0177] At a particular scheduling instant and / or TTI, and / or at a particular time when PHY resources become available to the WTRU, the WTRU may select the pending MAC PDU with the smallest TTL and / or TTL range among the pending MAC PDUs. The WTRU may select one or more or multiple available PDUs for transmission, perhaps, for example, at the same instant and / or substantially the same time. The WTRU may select the buffered PDU with the smallest TTL and / or TTL range.

[0178] The WTRU may perform assembly in combination with the scheduling criteria described herein, for example, the WTRU may select the MAC SDU with the smallest TTL and / or perform multiplexing / assembly, perhaps to include, for example, the MAC SDU with the smallest TTL of the pending MAC SDUs, in satisfying the grant and / or available resources for transmission.

[0179] The WTRU may perform such scheduling decisions with respect to a subset of transport channels and / or SOMs, etc. For example, the WTRU may perform such scheduling decisions on (e.g., only on) transmissions for the subset and / or TRP. The WTRU may perform such scheduling decisions when (e.g., only when) it is given a grant of resources on a particular transport channel and / or SOM (e.g., associated with a ULLRC transmission).

[0180] The WTRU may prioritize traffic based on the PHY layer providing the TTI of the grant. For example, the MAC layer may make its scheduling decisions based on the TTI that may be provided by the PHY layer. The MAC layer may receive the TTI at which it may transmit along with information about the transmission grant. The WTRU may select MAC SDUs to be multiplexed onto the MAC PDU based on this TTI knowledge. For example, if a short TTI grant is provided, the WTRU may select MAC SDUs associated with logical channels that may be for low latency transmissions. The WTRU may select MAC SDUs whose TTL may be below a certain threshold. The WTRU may receive one or more or multiple grants that may apply to different TTIs and / or different TTI lengths.

[0181] The MAC layer can dynamically select and / or determine the TTI length used to transmit the MAC PDU. Such a decision may be made by the WTRU on the TTI and / or at the scheduling moment itself. This decision may be made some time prior to the TTI, over a period of time, and / or with respect to a set of resources that the WTRU MAC has been informed of available.

[0182] The WTRU may receive an indication of a particular resource and / or resource set from which the MAC layer can select a TTI. The WTRU may select data to be transmitted on resources with a shortened TTI based on scheduling decisions and / or prioritization rules. This decision may be made to allow data with time-critical requirements to be transmitted within the time needed when taking potential retransmissions into account. For example, the MAC layer may receive an indication (potentially from the PHY layer) of the location and / or amount of resources for which a shortened TTI may be utilized. The MAC layer may receive an indication of the current data to be transmitted and / or the TTL associated with this data. The MAC layer may schedule transmissions based on this information by ensuring that latency-critical transmissions are successfully performed. The particular TTI to use for a particular MAC PDU may not be restricted. The transport block size for such a planned transmission may be driven by the amount of resources that may be associated with the shortened TTI in the next subframe, frame, and / or longer time period.

[0183] Logical channel prioritization may be performed, in part, using legacy LCP to multiplex time-critical data with non-time-critical data. Different logical channel types (e.g., low latency, ultra-reliable, MBB, etc.) may be multiplexed onto the same MAC PDU, and the WTRU may first select MAC SDUs that may be time-critical for inclusion in the MAC PDU before performing legacy LCP procedures.

[0184] In particular, the WTRU may determine which MAC SDUs are considered time-critical based on one or more of: the TTL associated with the SDU is below a threshold; the TTL associated with the SDU has expired and is below a threshold; the SDU comes from a particular logical channel and / or flow that has been identified by the WTRU as latency-critical; the size of the SDU is below a particular threshold; and / or the SDU has already been transmitted (e.g., unsuccessfully) in a previously transmitted PDU, which may indicate a retransmission.

[0185] The WTRU may include selected SDUs in a MAC PDU for transmission. The WTRU may include the SDUs in an order based on some specific criteria, such as QoS-based parameters, size, and / or logical channel priority. If the MAC PDU size is insufficient to include the time-critical SDUs, the WTRU may do one or more of: include as many SDUs as will fit into the MAC PDU by considering the potential order of inclusion; trigger the PHY layer to transmit a request for more resources and / or include a request for more resources (e.g., a PHY layer indication of more resources) in the transmission of this MAC PDU; include a BSR and / or similar MAC CE in the MAC PDU to indicate this condition to the cell; trigger an autonomous transmission at the WTRU that may include additional time-critical SDUs and / or include a request for resources; and / or trigger the PHY layer to utilize a shortened TTI for the transmission of this MAC PDU.

[0186] The WTRU may run the legacy LCP to serve the logical channel up to the PBR. The WTRU may consider the data selected in the second step as already in use when considering whether the logical channel is being served up to its PBR.

[0187] The WTRU may select a MAC SDU for the remainder of the MAC PDU according to one or more of the logical channel priorities for each legacy LCP. The WTRU may select one or more SDUs that may have a second level of time-criticality (e.g., a TTL greater than a first threshold but less than a second threshold).

[0188] The amount of data included in a MAC PDU while running an LCP may differ from the current LCP. The WTRU may select MAC SDUs for creation of a MAC PDU by selecting MAC PDUs from potentially different buffers (e.g., associated with logical channels, flows, services, etc.) in order of time-criticality. Time-criticality may be measured, for example, by TTL. In other words, the WTRU may select SDUs starting from the smallest TTL and / or in order of TTL until the MAC PDU is filled.

[0189] The WTRU may select MAC SDUs for creation of a MAC PDU by selecting MAC SDUs in order of time-criticality (e.g., smallest to largest TTL) and / or importance based on any QoS-based parameters (e.g., TTL below a threshold) until a MAC SDU with a particular time-criticality is addressed. The remainder of the MAC PDU size may be used to pad control data (MAC CE) and / or increase coding and / or redundancy.

[0190] The WTRU may select MAC SDUs for creation of a MAC PDU with some added restrictions on the logical channels / flows / services it selects, for example, the selection may be limited to one or more of the logical channels, perhaps up to a certain threshold, before other logical channels may be considered.

[0191] The WTRU may be configured with a priority index for one or more or each LCH. The priority index may be used, for example, to determine the order in which PDUs with the same time delay requirement are scheduled. The priority index may indicate the order in which PDUs of the same type and / or class (e.g., best effort) are scheduled.

[0192] The WTRU may determine the order in which PDUs that do not meet their latency requirements may be discarded. More specifically, the WTRU may be configured to determine the order in which PDUs are transmitted according to the PDU's latency requirement (e.g., first) and / or according to priority. If there are not enough resources to transmit a PDU, the WTRU may decide to discard a PDU with a lower priority index (e.g., remove the PDU from the buffer and / or not attempt transmission when the packet expires).

[0193] The WTRU may (e.g., autonomously) select transmission parameters. A transport format may be selected. For example, the WTRU may select a transport format from a pre-configured list associated with a traffic type, an LCH, and / or an SOM.

[0194] The WTRU (e.g., the MAC layer) may receive an indication of transport formats that may be usable for a particular grant. For example, the WTRU may be provided with a choice of transport formats to be used on the grant provided by the cell, and / or the WTRU may select an appropriate transport format and / or corresponding MAC PDU size based on one or more of the characteristics of the data that the WTRU plans to transmit (e.g., time-critical, reliable, efficient, etc.), a buffer status at the WTRU potentially associated with one or more or each type of data, and / or QoS-based parameters associated with the selected one or more or each packet.

[0195] Different transport formats may be associated with services and / or service types (e.g., ULRRC transport format (TF), eMBB TF, etc.) Transport formats may be associated with different levels of reliability (e.g., error probability) and / or transmission rate.

[0196] A WTRU may be associated with one and / or multiple or each transport format signaled by the cell with the service and / or service type. The association may be signaled as part of the transport format itself, e.g., via an index and / or special field. The association may be fixed / static and / or may be previously known by the eNB and / or WTRU. The WTRU may choose its association based on the characteristics of one or multiple or each TF (e.g., more coding may be associated with more reliable communication). The WTRU may be given a range of services and / or service types to which it may associate a given TF.

[0197] The WTRU may be configured with a set of transport formats for one, more, or each SOM. The WTRU may determine the set of transport formats to use based on the SOM used for transmission. The WTRU may select a TF that matches the type of data being sent based on the configuration. Specifically, the WTRU may make a TF selection based on the service associated with the data (and / or most of the data) in the MAC PDU.

[0198] Following transport format selection, the WTRU may indicate the selected format to the cell in a transmission. The WTRU may provide this information as an index transmitted on a PHY layer uplink control channel, such as the PUCCH and / or a 5G control channel.

[0199] The WTRU may prepend / append an index to the uplink transmission (the granted resource itself), which may be encoded using a predefined and / or fixed mechanism. Such a transport format indication from the WTRU may be present with the UL transmission. The WTRU may not provide such an indication, and / or the cell may be required to first blind decode to determine the selected TF.

[0200] The WTRU may receive an indication of a particular TF in the grant, but may decide to dynamically change the TF and / or inform the cell of this decision. The WTRU may be restricted to changing the TF of a grant on (e.g., only) a MAC PDU that may contain data from a particular logical channel and / or a particular service. The WTRU may be restricted to changing the TF from the currently signaled TF to a finite set of "derived" TFs that may have a certain relationship to the original TF (thus facilitating signaling of the derived TFs to the cell).

[0201] The WTRU may modify the TF to add additional coding to the scheduled data, e.g., to increase robustness. The decision to add additional coding may be based on one or more of reliability and / or latency requirements associated with the data that needs to be sent, QoS-based parameters associated with the data to be sent and / or other data pending transmission, buffer occupancy or lack thereof, and / or whether the MAC PDU is being retransmitted or whether it is the initial transmission of a PDU.

[0202] The WTRU may, for example, decide not to include additional SDUs in the MAC PDU, perhaps after processing a certain number of logical channels (e.g., up to a Prioritized Bit Rate (PBR)) and / or a certain number of MAC SDUs taking into account latency-criticality requirements. The WTRU may indicate to the PHY layer to increase the redundancy associated with a particular MAC PDU (e.g., by reducing the code rate). For example, after MAC SDUs with a TTL below a threshold have been included in the MAC PDU and / or a logical channel has been served up to the PRB, the WTRU may not include additional MAC SDUs for transmission in the MAC PDU and may reduce the code rate (at the PHY layer) of the resulting MAC PDU.

[0203] The WTRU may indicate the selected format in a transmission (eg, using at least one of the techniques described herein), perhaps following a transport format reselection, for example.

[0204] Although features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal or 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, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU) in communication with a wireless communications network, comprising: Memory and A receiver comprising at least: a receiver configured to receive a configuration, the configuration including one or more characteristics for one or more transmission modes (TM) of the WTRU; A processor comprising at least: dynamically selecting at least one TM of the one or more TMs for transmission of an uplink data unit, the dynamic selection being based on one or more data transfer requirements and the one or more TM characteristics; identifying at least one transport channel associated with said at least one TM; mapping the uplink data units to the at least one transport channel; a processor configured to: A transmitter comprising at least: a transmitter configured to send the transmission of the uplink data unit to one or more devices of the wireless communication network; A WTRU comprising:

2. 2. The WTRU of claim 1, wherein the one or more characteristics of the one or more transmission modes include one or more of a TTI duration, a bandwidth, a symbol rate, one or more coding characteristics, a set of supported modulation and coding schemes (MCS), or a numerology.

3. The WTRU of claim 2 , wherein the one or more coding characteristics include at least one of rate or reliability.

4. The WTRU of claim 2 , wherein the numerology includes at least one of a subcarrier spacing or an associated symbol period.

5. The WTRU of claim 1 , wherein the processor is further configured to: cause the dynamic selection of the at least one TM of the one or more TMs for the transmission of the uplink data unit to occur on a packet-by-packet basis.

6. 10. The WTRU of claim 1, wherein the one or more data transfer requirements include at least one of a level of service, latency, reliability, peak rate, average rate, priority, or a Quality of Service (QoS) Class Identifier (QCI).

7. The processor: Identifying a Hybrid Automatic Repeat Request (HARQ) process associated with at least one of the at least one transport channel or the at least one TM; The WTRU of claim 1 , further configured to select the HARQ process for the transmission of the uplink data unit.

8. The receiver includes: The WTRU of claim 1 , further configured to receive downlink control information (DCI) from at least one device of the one or more devices of the wireless communications network.

9. The processor: Identifying a first resource allocation indicated by the DCI for transmission of the uplink data unit; determining quality of service (QoS) requirements for the transmission of the uplink data unit; determining whether the first resource allocation indicated by the DCI for transmission of the uplink data unit at least satisfies or does not satisfy the QoS requirements; 9. The WTRU of claim 8, further configured to: determine not to utilize the first resource allocation indicated by the DCI for the transmission of the uplink data unit when it is determined that the first resource allocation indicated by the DCI cannot meet the QoS requirements.

10. The processor: identifying a second resource allocation corresponding to the at least one TM of the one or more TMs for the transmission of the uplink data unit; 10. The WTRU of claim 9, further configured to: determine, when it is determined that the first resource allocation indicated by the DCI cannot meet the QoS requirement, to utilize the second resource allocation corresponding to the at least one TM of the one or more TMs for the transmission of the uplink data unit.

11. The uplink data unit is a first uplink data unit, and the processor: Identifying a second uplink data unit for transmission; Identifying a first quality of service for the transmission of the first uplink data unit; Identifying a second QoS for the transmission of the second uplink data unit; determining that a difference between the first QoS and the second QoS is within a preconfigured threshold; The WTRU of claim 1 , further configured to multiplex the second uplink data unit with the first uplink data unit in the transmission.

12. 12. The WTRU of claim 11, wherein the processor is further configured to multiplex the second uplink data units with the first uplink data units in the transmission up to a preconfigured multiplexing ratio.

13. 1. A method performed by a wireless transmit / receive unit (WTRU) in communication with a wireless communications network, comprising: receiving a configuration, the configuration including one or more characteristics for one or more transmission modes (TM) of the WTRU; dynamically selecting at least one TM of the one or more TMs for transmission of an uplink data unit, the dynamic selection being based on one or more data transfer requirements and the one or more TM characteristics; identifying at least one transport channel associated with said at least one TM; mapping the uplink data units to the at least one transport channel; sending the transmission of the uplink data unit to one or more devices of the wireless communications network; A method comprising:

14. 14. The method of claim 13, wherein the one or more characteristics of the one or more transmission modes include one or more of a TTI duration, a bandwidth, a symbol rate, one or more coding characteristics, a set of supported modulation and coding schemes (MCS), or a numerology.

15. The method of claim 14 , wherein the one or more coding characteristics include at least one of rate or reliability.

16. 15. The method of claim 14, wherein the numerology includes at least one of a subcarrier spacing or an associated symbol period.

17. 14. The method of claim 13, wherein the dynamic selection of the at least one TM of the one or more TMs for the transmission of the uplink data unit is performed on a packet-by-packet basis.

18. 14. The method of claim 13, wherein the one or more data transfer requirements include at least one of a level of service, latency, reliability, peak rate, average rate, priority, or a Quality of Service (QoS) Class Identifier (QCI).

19. identifying a Hybrid Automatic Repeat Request (HARQ) process associated with at least one of the at least one transport channel or the at least one TM; selecting the HARQ process for the transmission of the uplink data unit; The method of claim 13 further comprising:

20. 14. The method of claim 13, further comprising receiving downlink control information (DCI) from at least one device of the one or more devices of the wireless communications network.

21. identifying a first resource allocation indicated by the DCI for transmission of the uplink data unit; determining quality of service (QoS) requirements for the transmission of the uplink data unit; determining whether the first resource allocation indicated by the DCI for transmission of the uplink data unit at least meets or does not meet the QoS requirements; determining not to utilize the first resource allocation indicated by the DCI for the transmission of the uplink data unit upon determining that the first resource allocation indicated by the DCI cannot meet the QoS requirements; 21. The method of claim 20 further comprising:

22. identifying a second resource allocation corresponding to the at least one TM of the one or more TMs for the transmission of the uplink data unit; determining, upon determining that the first resource allocation indicated by the DCI cannot meet the QoS requirements, to utilize the second resource allocation corresponding to the at least one TM of the one or more TMs for the transmission of the uplink data unit; 22. The method of claim 21 further comprising:

23. The uplink data unit is a first uplink data unit, and the method includes: identifying a second uplink data unit for transmission; identifying a first quality of service for the transmission of the first uplink data unit; identifying a second QoS for the transmission of the second uplink data unit; determining that a difference between the first QoS and the second QoS is within a preconfigured threshold; multiplexing the second uplink data unit with the first uplink data unit in the transmission; The method of claim 13 further comprising:

24. 24. The method of claim 23, wherein the second uplink data units are multiplexed with the first uplink data units in the transmission up to a preconfigured multiplexing ratio.

Images