JP7281512B2 - Wireless transmit/receive unit and method performed by a wireless transmit/receive unit in a wireless communication network - Google Patents

Description

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

CROSS-REFERENCE TO RELATED APPLICATIONS This application, filed March 30, 2016, is incorporated herein by reference as if fully set forth herein for all purposes. The benefit of provisional patent application Ser. No. 62/315,165 is claimed.

Mobile communications are continuously evolving and are already on the threshold of the fifth generation, ie 5G. As with previous generations, new use cases have contributed significantly to setting the requirements for the new system. 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) There is expected.

5G network deployments can include stand-alone systems and/or can include phased approaches, e.g., in combination with existing deployments and/or existing technologies (e.g., LTE and/or evolution thereof, etc.). can. Combinations with existing technologies can include radio access network components and/or core network components. Initial deployments using a phased approach are expected to allow 5G systems to 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, core network functions, and so on. As more commercial 5G deployments become available, it can be expected that deployments can evolve to make 5G systems independent and possibly LTE independent. This second phase of 5G can be expected to target new (eg, previously undefined) use cases, possibly with stringent reliability and/or latency requirements.

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

Logical channels may be multiplexed together based on latency requirements. The mapping of LCH to SOM can be based on SOM capabilities and/or LCH requirements. A WTRU may determine the mapping based on pre-defined rules. The mapping can be based on various types of traffic and/or SOM capability requirements. A radio bearer may be mapped to one or more SOMs. A WTRU may be configured with a set of SOMs that it may use, perhaps for one or more or each radio bearer, for example. A WTRU may dynamically determine which SOM to use, perhaps based on radio conditions, buffer status, and/or other parameters, for example. Incompatible multiplexing of the LCH may result in (e.g. single) transport block (TB) (e.g. limited by data ratio) and/or one or more or It can be reduced and/or avoided based on using multiple TBs. Traffic may be prioritized, perhaps based on latency requirements, for example.

A wireless transmit/receive unit (WTRU) may be in communication with a wireless communication network. A WTRU may comprise a memory. A WTRU may be equipped with a receiver. A receiver may be configured to receive the configuration. The configuration may include one or more characteristics for one or more transmission modes (TM) of the WTRU. A 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 uplink data units. Dynamic selection can 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 at least one TM. The processor may be configured to map the uplink data units to at least one transport channel. A WTRU may comprise a transmitter. The transmitter may be configured to at least send transmissions of uplink data units to one or more devices of the wireless communication network.

1 is a system diagram of an exemplary communication system; FIG. 1B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A; FIG. 1B is a system diagram of an example radio access network and an example core network that may be used within the communication system illustrated in FIG. 1A; FIG. 1B is a system diagram of another example radio access network and an example core network that may be used within the communication system illustrated in FIG. 1A; FIG. 1B is a system diagram of another example radio access network and an example core network that may be used within the communication system illustrated in FIG. 1A; FIG. Figure 2 shows an example LTE user plane protocol stack; FIG. 2 illustrates an example LTE Medium Access Control (MAC) architecture; FIG. 4 illustrates an example system bandwidth; FIG. 2 illustrates an exemplary spectrum allocation in which different subcarriers may be assigned, at least conceptually, to different modes of operation (“SOM”); FIG. 2 illustrates exemplary timing relationships for Time Division Duplex (TDD); FIG. 2 illustrates exemplary timing relationships for frequency division duplexing (FDD); FIG. 2 illustrates example deployments supported and/or not supported by LTE; Fig. 3 shows example functionality of a 5G protocol stack at a high level; FIG. 4 shows an exemplary high-level mapping between logical channels (LCH) and SOMs; [0013] Figure 4 shows an example (eg, single) HARQ entity per WTRU technique in the context of a complete protocol stack and/or in the context of all features of the protocol stack; FIG. 4 shows an exemplary high-level mapping between LCH and SOM; [0014] Figure 4 shows an example (eg, single) HARQ entity for each SOM technique in the context of a complete protocol stack and/or in the context of all features of a protocol stack; FIG. 4 shows an exemplary high-level mapping between LCH and SOM; FIG. 2 shows an exemplary (eg, single) HARQ entity for each SOM technique in the context of a complete protocol stack, eg, all functions of the protocol stack; FIG. 10 illustrates an example of a WTRU controller dynamically matching data units to TrCHs that may satisfy the QoS requirements of the data units;

A detailed description of illustrative embodiments will now be described with reference to the various figures. While this description provides detailed examples of possible implementations, it should be noted that these details are intended to be examples and in no way limit the scope of the present application.

FIG. 1A is a diagram of an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, communication system 100 may include 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). One or more channel access methods may be utilized.

As shown in FIG. 1A, a communication system 100 includes wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which may be collectively or collectively referred to as WTRUs 102), radio access Although it may include networks (RAN) 103/104/105, core networks 106/107/109, public switched telephone networks (PSTN) 108, Internet 110, as well as other networks 112, the disclosed embodiments: It will be appreciated that any number of WTRUs, base stations, networks and/or network elements are contemplated. Each of the 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 be user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, It may include personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, and/or consumer electronics, and the like.

Communication system 100 can also include base stations 114a and base stations 114b. Each of the base stations 114a, 114b wirelessly interfaces with at least one of the WTRUs 102a, 102b, 102c, 102d to one or It may be any type of device configured to facilitate access to multiple communication networks. By way of example, base stations 114a, 114b may be base stations (BTS), Node-Bs, eNode Bs, home Node Bs, home eNode Bs, site controllers, access points (APs), and/or wireless routers, etc. . Although each base station 114a, 114b is shown as a single element, it is understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 103/104/105, which may be connected to other base stations and/or network elements (not shown), e.g., base station controllers (BSCs), radio It may also include network controllers (RNCs), relay nodes, and the like. 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, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, eg, 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.

The base stations 114a, 114b have air interfaces 115/116/117, which may be any suitable wireless communication link (eg, radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via. Air interfaces 115/116/117 may be established using any suitable radio access technology (RAT).

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

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

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c support IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 ( IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolved High-Speed Data Rate (EDGE), and/or GSM EDGE (GERAN ) may be implemented.

Base stations 114b in FIG. 1A may be, for example, wireless routers, Home Node Bs, Home eNode Bs, or access points that provide wireless connectivity in localized areas such as businesses, homes, vehicles, and/or campuses. Any suitable RAT may be utilized to facilitate. 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 WTRUs 102c, 102d utilize cellular-based RATs (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. can be done. As shown in FIG. 1A, base station 114b may have a direct connection to Internet 110. FIG. Accordingly, base station 114b may not be used to access Internet 110 via core networks 106/107/109.

RAN 103/104/105 may be in communication with core network 106/107/109, which provides voice, voice, It may be any type of network configured to provide data, applications, and/or Voice over Internet Protocol (VoIP) services. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and/or higher levels of user authentication, etc. It can perform security functions. Although not shown in FIG. 1A, RANs 103/104/105 and/or core networks 106/107/109 are directly or indirectly connected to other RANs utilizing the same RAT as RANs 103/104/105 or different RATs. It will be appreciated that it may be communicating with the For example, in addition to being connected to RAN 103/104/105, which may be using E-UTRA radio technology, Core Network 106/107/109 is connected to another RAN (not shown) using GSM radio technology. You may also be communicating with

Core network 106/107/109 may also act as a gateway for WTRUs 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and/or other networks 112. PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). Internet 110 is a global network 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. system. Network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may utilize the same RAT as RANs 103/104/105 or a different RAT.

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 communicate with different wireless networks via different wireless links. may include multiple transceivers for For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a capable of utilizing cellular-based radio technology and a base station 114b capable of utilizing IEEE 802 radio technology.

FIG. 1B is a system diagram of an exemplary WTRU 102. As shown in FIG. As shown in FIG. 1B, the WTRU 102 includes a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, and a power supply 134. , a global positioning system (GPS) chipset 136 , and other peripherals 138 . It will be appreciated that the WTRU 102 may include any subcombination of the above-described elements while remaining consistent with the embodiments. Embodiments also include base stations 114a and 114b, and/or nodes that base stations 114a and 114b may represent, such as, but not limited to, Base Station Transceiver (BTS), Node-B, Site Controller, Access Point (AP), home node-B, evolved home node-B (eNodeB), home evolved node-B (HeNB), home evolved node-B gateway, proxy node, etc. are also shown in FIG. 1B. It is contemplated that this may include one or more of the elements described herein.

Processor 118 may include general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, one or more microprocessors associated with DSP cores, controllers, microcontrollers, application-specific integrated circuits ( ASIC), field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and/or state machine. Processor 118 may perform signal encoding, data processing, power control, input/output processing, and/or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120 , which can be coupled to transmit/receive element 122 . Although FIG. 1B shows processor 118 and transceiver 120 as separate components, it is understood that processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

Transmit/receive element 122 may be configured to transmit signals to or receive signals from a base station (eg, base station 114a) over air interfaces 115/116/117. For example, in one embodiment, transmit/receive element 122 may be an antenna configured to transmit and/or receive radio frequency (RF) signals. In another embodiment, transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, transmit/receive element 122 may be configured to transmit and receive both RF and optical signals. It will be appreciated that transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Additionally, although transmit/receive element 122 is shown as a single element in FIG. 1, WTRU 102 may include any number of transmit/receive elements 122 . More specifically, the WTRU 102 may utilize MIMO technology. Accordingly, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (eg, multiple antennas) for transmitting and receiving wireless signals over the air interfaces 115/116/117. .

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

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). , from which user input data can be received. Processor 118 may also output user data to speaker/microphone 124 , keypad 126 , and/or display/touchpad 128 . Additionally, processor 118 can access information in and store data in any type of suitable memory, such as non-removable memory 130 and/or removable memory 132 . Non-removable memory 130 may include random access memory (RAM), read only memory (ROM), hard disk, or any other type of memory storage device. Removable memory 132 may include subscriber identity module (SIM) cards, memory sticks, and/or secure digital (SD) memory cards, and the like. In other embodiments, the processor 118 accesses information in memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and stores data in such memory. can be done.

Processor 118 may receive power from power source 134 and may be configured to power and/or control power to other components in WTRU 102 . Power supply 134 may be any suitable device for powering WTRU 102 . For example, the power source 134 may include one or more dry cell batteries (eg, nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, and/or fuel. May include batteries and the like.

Processor 118 may be coupled to GPS chipset 136 which may be configured to provide location information (eg, longitude and latitude) regarding the current location of WTRU 102 . In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 receives location information over the air interface 115/116/117 from base stations (eg, base stations 114a, 114b) and/or Its position may be determined based on the timing of signals being received from more than one base station. It will be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the embodiments.

Processor 118 may be further coupled to other peripherals 138, which may be one or more software and/or components that provide additional features, functionality, and/or wired or wireless connectivity. It may include hardware modules. For example, peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photo or video), universal serial bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth modules , a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, and/or an Internet browser, and the like.

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

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

The core network 106 shown in FIG. 1C includes a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving General Percent Radio Service (GPRS) Support Node (SGSN) 148, and/or a Gateway GPRS Support Node ( GGSN) 150. Although each of the above elements are shown as part of core network 106, it is understood that any of these elements may be owned and/or operated by entities other than the core network operator. .

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

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

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

FIG. 1D is a system diagram of 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. RAN 103 may also communicate with core network 106 .

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

Each eNode-B 160a, 160b, 160c may be associated with a particular cell (not shown) to make radio resource management decisions, handover decisions, and/or scheduling users on the uplink and/or downlink. and so on. As shown in FIG. 1D, eNode-Bs 160a, 160b, 160c can communicate with each other via the X2 interface.

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

The MME 162 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and can 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. can be done. MME 162 may also provide control plane functionality for switching between RAN 104 and a RAN (not shown) that utilizes other radio technologies such as GSM or WCDMA.

Serving gateway 164 may be connected to each of eNode-Bs 160a, 160b, 160c in 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 anchor the user plane during inter-eNode B handovers, trigger paging when downlink data is available for the WTRUs 102a, 102b, 102c and/or the WTRUs 102a, 102b, Other functions may also be performed, such as managing and storing the context of 102c.

Serving gateway 164 may also provide WTRUs 102a, 102b, 102c access to a packet-switched network, such as Internet 110, to facilitate communications between WTRUs 102a, 102b, 102c and IP-enabled devices. It may be connected to gateway 166 .

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

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

As shown in FIG. 1E, RAN 105 may include base stations 180a, 180b, 180c and ASN gateways, but RAN 105 may include any number of base stations and ASN gateways while remaining consistent with embodiments. It will be understood. Base stations 180a, 180b, 180c, each may be associated with a particular cell (not shown) in the RAN 105, and each have one or a Each may include multiple transceivers. In one embodiment, base stations 180a, 180b, 180c may implement MIMO techniques. Thus, the base station 180a may, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a. 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. ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, subscriber profile caching, and/or routing to core network 109, and the like.

The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as the R1 reference point implementing the IEEE 802.16 specification. Additionally, each of the WTRUs 102 a , 102 b , 102 c may establish a logical interface (not shown) with the core network 109 . A 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.

A 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 transfer of data between base stations. Communication links between base stations 180a, 180b, 180c and ASN gateway 182 may be defined as R6 reference points. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

RAN 105 may be connected to core network 109, as shown in FIG. 1E. A communication link between RAN 105 and core network 109 may be defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. Core network 109 may include mobile IP home agent (MIP-HA) 184 , authentication, authorization and accounting (AAA) server 186 and gateway 188 . Although each of the above elements are shown as part of core network 109, it is understood that any of these elements may be owned and/or operated by entities other than the core network operator. .

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

Although not shown in FIG. 1E, it will be appreciated that RAN 105 may be connected to other ASNs and core network 109 may be connected to other core networks. Communication links between RAN 105 and other ASNs may be defined as R4 reference points that may include protocols for coordinating mobility of WTRUs 102a, 102b, 102c between RAN 105 and other ASNs. Communication links between core network 109 and other core networks may be defined as the R5 standard, which may include protocols for facilitating inter-network connections between home core networks and visited core networks.

1A-1E and the corresponding description of FIGS. 1A-1E, WTRUs 102a-d, base stations 114a-b, Node Bs 140a-c, RNCs 142a-b, MSC 146, SGSN 148, MGW 144, GGSN 150, eNode-B 160a , 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., as described herein. One or more or all of the functions described herein are configured to emulate one or more or all of the functions described herein by one or more emulation devices (not shown) (e.g., by one or more devices).

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 being fully or partially implemented/deployed as part of a wired and/or wireless communication 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 communication network. One or more emulation devices may be implemented/deployed as part of a wired and/or wireless communication network (e.g., testing scenarios in a lab and/or non-deployed (e.g., testing) wired and/or one or more or all functions may be performed), such as in tests performed on a wireless communication network and/or one or more deployed components of a wired and/or wireless communication network; One or more emulation devices may be test equipment.

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 5G Flex Node B
ACK acknowledgment BLER block error rate BTI base TI (integer multiple of one or more symbol periods)
CB Contention based (e.g. access, channel, resource)
CoMP Coordinated multipoint transmission/reception CP Cyclic prefix CP-OFDM Conventional OFDM (depending on cyclic prefix)
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

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 duplexing 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 Medium 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 stratum OFDM orthogonal frequency division multiplexing

By way of example and not limitation, one or more of the following acronyms may be referenced herein.
OOB Out of Band (Emissions)
P _cmax total available WTRU power at 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 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

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 Spectrum Operating Mode SS Synchronization 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 (integer multiple of one or more BTIs)
TTI Transmission Time Interval (one or more integer multiples of TI)
TrCH transport channel TRP transmit/receive 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 Communications V2V Vehicle-to-Vehicle Communications V2X Vehicle Communications WLAN Wireless Local Area Networks and Associated Technologies (IEEE 802.xx Domains)

FIG. 2 shows an exemplary 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 functions used to transfer data from a WTRU to an eNB (and vice versa, for example) over the wireless medium.

The MAC sublayer multiplexes MAC Service Data Units (SDUs) belonging to one or more or different logical channels into/from transport blocks (TB) that are delivered to/from the physical layer on transport channels. / demultiplexing, scheduling information reporting, error correction over HARQ, priority handling between logical channels of at least one WTRU, priority handling between WTRUs with dynamic scheduling, MBMS service identification, transport format selection and/or padding It provides several services and/or features, including but not limited to.

FIG. 3 shows an exemplary LTE MAC architecture. Various functions interact with each other as shown. For logical channel prioritization and/or multiplexing (specified for the uplink) to determine and/or select the set of data (MAC Protocol Data Units (PDUs)) to be transmitted in a particular TTI can be used for

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 retransmissions are 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 many parallel HARQ processes (e.g., up to 8 ) can be used. One or more or each HARQ process may carry different MAC PDUs and/or operate independently with respect to transmission and/or retransmission.

HARQ retransmissions on the LTE uplink can be synchronized. For example, there may be a fixed time relationship between transmission and retransmission of a given MAC PDU. On the LTE downlink, HARQ operation is asynchronous and/or HARQ process ID may be explicitly signaled in the downlink signaling grant. HARQ ACK/NACK may be sent by the WTRU with fixed timing (eg, after 4 TTs) relative to the associated transmission.

A 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 can provide support for ultra-low transmission latency (LLC). Air interface latency can be as low as 1 ms round trip time (RTT) and/or can provide support for TTIs anywhere between 100 μs and 250 μs (perhaps less than 250 μs, for example). The 5G flexible air interface can provide support for targeted but low priority ultra-low access latency (eg, time from initial system access to completion of transmission of the first user plane data unit). A 5G flexible air interface can provide support for end-to-end (e2e) latency of less than 10ms. A 5G flexible air interface may provide support for ultra-reliable transmission (URC). The goal may be 99.999% transmission success and/or service availability.

A 5G flexible air interface can provide support for mobility with speeds ranging from 0 to 500 km/h. At least the IC and/or V2X can 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 provide narrowband operation (e.g., using less than 200 kHz), extended battery life (e.g., autonomy up to 15 years), and/or small and/or infrequent, e.g., seconds to few It can support minimal communication overhead for data transmission at low data rates in the range of 1-100 kbps with access latencies of hours.

A flexible radio 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 partition the spectrum into one, multiple, 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 relies on strict management of uplink timing alignment within the duration of perfect frequency synchronization and/or cyclic prefix to maintain orthogonality between signals and/or minimize inter-carrier interference. can be associated. Such strict synchronization may not be suitable in systems where WTRUs are connected (eg, simultaneously) to multiple access points. Power reduction may be applied to uplink transmissions to meet spectral emissions requirements for adjacent bands, especially in the presence of fragmented spectrum aggregation for WTRU transmissions.

Some of the drawbacks of conventional OFDM (CP-OFDM) can be overcome by stricter RF requirements for implementation and/or when operating with large amounts of continuous spectrum that do not require aggregation. CP-based OFDM transmission schemes may result in modifications to the downlink physical layer for 5G similar to those of legacy systems, eg, mainly to pilot signal density and/or location.

A number of principles applicable to the design of flexible radio access for 5G are described herein. The description herein in no way limits the applicability of the methods further described herein to other wireless technologies and/or wireless technologies using different principles where applicable. Not intended.

A 5G Flexible Radio Access Technology (5gFLEX) downlink transmission scheme can be based on multi-carrier waveforms characterized by high spectral confinement (eg, lower sidelobes and/or lower out-of-band (OOB) emissions). Multi-Carrier (MC) waveform candidates for 5G may include, but are not limited to OFDM-OQAM (Offset Quadrature Amplitude Modulation) and/or Universal Filtering Multi-Carrier (UFMC) (UF-OFDM).

A multi-carrier modulating waveform may divide the channel into subchannels and/or modulate data symbols on the subcarriers in these subchannels. In OFDM-OQAM, filters can be adapted in the time domain for each subcarrier to the OFDM signal to reduce OOB.

In UFMC (UF-OFDM), filters can be adapted in the time domain to OFDM signals to reduce OOB. Filtering is applied per subband to use spectral fragments, which may reduce complexity and/or be somewhat more practical for implementing UF-OFDM.

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 also used for illustrative purposes.

Such waveforms allow multiplexing in frequency of signals with non-orthogonal characteristics (e.g., different subcarrier spacing, etc.) and/or coexistence of asynchronous signals without the need for complex interference cancellation receivers. be able to. It can facilitate aggregation of fragmented portions of spectrum in baseband processing as a lower cost alternative to its implementation as part of RF processing.

Different waveforms can coexist within the same band. mMTC narrowband operation may be supported using single carrier multiple access (SCMA), for example. Combinations of different waveforms within the same band, eg, 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 between different WTRUs and/or between transmissions from the same WTRU at the same time, with some overlap and/or in succession in the time domain.

Hybrid type waveforms may be supported. For example, waveforms and/or transmissions may include cyclic prefix (CP) durations that vary from time to time (e.g., from transmission to transmission), combinations of CP and low power tails (e.g., zero tails), and/or (e.g., low power CP and adaptive low power tails). form of hybrid guide interval (using power tail), and/or the like. Such waveforms can be used to dynamically vary and/or control further aspects, such as how filtering is applied (e.g., the spectrum used to receive any transmission on a given carrier frequency). and/or at the edges of the spectrum used to receive transmissions associated with a particular SOM, and/or per subband and/or per group thereof. Please) can support.

Uplink transmissions may have the same or different waveforms as downlink transmissions. Multiplexing of transmissions to and from different WTRUs within the same cell may be based on FDMA and/or TDMA.

The 5g FLEX radio access system can be characterized by a very high degree of spectrum flexibility, allowing deployment in different frequency bands with different characteristics, such different characteristics being different duplex deployments, same or different Includes different and/or variable sizes of available spectrum, including contiguous and/or non-contiguous spectrum allocation in bands. It can support variable timing aspects, including support for one, multiple or multiple TTI lengths, and/or support for asynchronous transmission.

A 5g FLEX radio access system can provide flexibility in duplex deployment. TDD and/or FDD duplexing schemes may be supported. For FDD operation, supplemental downlink operation may 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 may be dynamic. DL/UL assignments may not be based on a fixed DL/UL frame structure. The length of the DL and/or UL transmission intervals may be set for each transmission opportunity.

A 5g FLEX radio access system can provide bandwidth flexibility, e.g., different transmissions on the uplink and/or downlink, either from a nominal system bandwidth to a maximum value corresponding to that system bandwidth. Realize your bandwidth potential.

For single-carrier operation, supported system bandwidths 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 possibly be one or more fixed possible values. Narrowband transmissions up to 200 kHz may be supported within the operating bandwidth for MTC devices.

System bandwidth, as used herein, may include the largest portion of spectrum that can be managed by the network for a given carrier. For such carriers, the portion of the WTRU that minimally supports 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 overall system bandwidth. FIG. 4 shows an exemplary system bandwidth. The WTRU's configured channel bandwidth may or may not include the nominal portion of the system bandwidth as shown in FIG.

Bandwidth flexibility is achievable because the set of applicable RF requirements for a given maximum operating bandwidth within a band varies with that operating band for efficient support of baseband filtering of frequency-domain waveforms. This is because it can be satisfied without introducing additional admitted channel bandwidth.

Method for configuring, reconfiguring and/or dynamically changing a WTRU's channel bandwidth for single carrier operation and spectrum for narrowband transmission within nominal system, system and/or configured channel bandwidth is contemplated.

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

Methods are contemplated for scaling and/or managing (eg, scheduling, resource addressing, broadcast signals, measurements) cell-specific and/or WTRU-specific channel bandwidths for any spectral block size.

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

Downlink data channels may be allocated across a bandwidth that may or may not correspond to the nominal system bandwidth, with no restrictions other than being within the WTRU's configured channel bandwidth. For example, a network may operate a carrier with a 12 MHz system bandwidth using a 5 MHz nominal bandwidth, allowing devices supporting a maximum RF bandwidth of up to 5 MHz to acquire and/or access the system. and possibly assign +10 to -10 MHz of carrier frequency to other WTRUs supporting up to 20 MHz worth of channel bandwidth.

FIG. 5 shows an exemplary spectrum allocation in which different subcarriers can be at least conceptually allocated to different modes of operation (spectrum modes of operation (SOM)). Different SOMs can 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, eg, HARQ processing aspects, and/or secondary control channels. The SOM can include specific waveforms and/or processing aspects that support coexistence of different waveforms within the same carrier using, for example, FDM and/or TDM. Coexistence of FDD operation within the TDD band may be supported, for example, in a TDM fashion and/or similar fashion.

A WTRU may be configured to perform transmissions according to one or more SOMs. For example, the SOM may specify a specific TTI duration, a specific initial power level, a specific HARQ process type, a specific upper bound for HARQ reception/transmission, a specific configuration of a set of resources (e.g., managed network) for WTRU operation, Transmissions according to specific physical channels (uplink and/or downlink), specific operating frequencies, bands and/or carriers, specific waveform types, and/or specific RATs (e.g. legacy LTE and/or 5G transmission methods) according to ). The SOM may correspond to one or more of QoS levels and/or related aspects such as maximum/target latency and/or maximum/target block error rate (BLER).

A SOM may correspond to a spectral domain and/or a particular control channel and/or aspect thereof (eg, 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 service, LLC-type service, and/or MBB-type service. A WTRU may transmit L3 control signaling (e.g., radio resource control (RRC)) for system access and/or in a portion of the spectrum associated with the system, e.g. signaling) for transmission/reception of SOMs.

As described herein, a SOM may be a characterization of a block of physical resources in time, space, and/or frequency. A SOM may contain an applicable set of actions. A transmission mode (TM) may correspond to an instance (eg, a particular instance) of SOM characterization, perhaps in terms of a particular configuration, for example. For example, a particular configuration may include one or more of applicable TTI durations, sets of physical resource blocks, waveform types, and the like. 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. The transmission mode (TM) may correspond to the WTRU's configuration, whereby the WTRU is possibly configured for processing transmissions (UL or DL), eg, when the WTRU receives an allocation of one or more resources. can determine one or more parameters applicable to The configuration of the TM (eg, applicable TM) depends on how it receives WTRU-specific reference signals, how it interprets downlink control signaling received on the PDCCH, and/or precoding bits. , etc., to the WTRU.

Spectrum aggregation may be supported for single-carrier operation, whereby a WTRU may operate one or more or many over contiguous and/or non-contiguous sets of physical resource blocks (PRBs) within the same operating band. Transmission and/or reception of transport blocks may be supported. A (eg, single) transport block may be mapped to a separate PRB set. Support may be provided for simultaneous transmissions associated with different SOM requirements.

Multi-carrier operation may be supported using contiguous and/or non-contiguous spectral 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 how to configure, reconfigure, and/or dynamically change a WTRU's multi-carrier aggregation.

Flexible framing, timing, and/or synchronization may be supported. Downlink and/or uplink transmissions are characterized by some fixed aspects (e.g., location of downlink control information) and/or some varying aspects (e.g., transmission timing, supported transmission types). can be organized into attached radio frames.

A basic time interval (BTI) may be expressed in symbol periods, which may be an integer number of one or more symbols and/or a function of the subcarrier spacing applicable to the time/frequency resource. For FDD, the subcarrier spacing may differ between the uplink carrier frequency f _UL and the downlink carrier frequency f _DL for a given frame.

A transmission time interval (TTI) may be the minimum time supported by the system between successive transmissions. Consecutive transmissions may, for example, possibly eliminate any preamble (e.g., where applicable) and/or possibly any control information (e.g., DCI for the downlink and/or uplink control information (UCI) for the uplink. ) may be associated with different transport blocks (TB) for the downlink (TTI _DL ) for the uplink transceiver (UL TRx). A TTI may be expressed as an integer of one or more BTIs. A BTI may be unique and/or associated with a given SOM.

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

A frame is downlink control information (DCI) for a fixed time period t _dci preceding any downlink data transmission (DL TRx) for the associated carrier frequency (f _UL +DL for TDD and f _DL for FDD). can start. For TDD duplexing (eg, TDD duplexing only), a 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.

For FDD duplexing (eg, FDD duplexing only), a frame may include a downlink reference TTI and/or one or more TTIs for the uplink. The start of the uplink TTI may be derived using an offset (t _offset ) applied from the start of the downlink reference frame that may overlap the start of the uplink frame.

With respect to TDD, 5gFLEX can be used in the DCI+DL TRx part (e.g. if semi-static allocation of the respective resource is used) and/or in the DL TRx part (e.g. only that part) (e.g. in case of dynamic allocation) , by including respective downlink control and/or forward transmissions, and/or by including respective reverse transmissions in the UL TRx part, device-to-device transmission (D2D)/vehicle communication (V2X)/ Side link operation can be supported.

With respect to FDD, 5gFLEX defines the UL TRx portion of the frame by including each downlink control, forward, and/or reverse transmission in the UL TRx portion (e.g., dynamic allocation of respective resources may be used). can support D2D/V2X/sidelink operation in

FIG. 6 shows an exemplary frame structure and/or frame timing relationships for TDD duplex. FIG. 7 shows an exemplary frame structure and/or frame timing relationships for FDD duplex.

A WTRU may receive downlink control information (DCI) from at least one of one or more devices in a wireless communication network. A WTRU may identify the resource allocation indicated by the DCI for transmission of uplink data units. A WTRU may determine quality of service (QoS) requirements for transmission of uplink data units. A WTRU may determine whether the resource allocation indicated by the DCI for transmission of uplink data units at least meets or fails to meet the QoS requirements. A WTRU should not utilize the resource allocation indicated by the DCI for transmission of uplink data units, for example, when the resource allocation indicated by the DCI fails (eg, is determined to fail) to meet QoS requirements. can decide.

A WTRU may identify a resource allocation corresponding to at least one TM of the one or more TMs for transmission of uplink data units. The WTRU may, for example, preclude the resource allocation indicated by the DCI (eg, for transmission of uplink data units) when the resource allocation indicated by the DCI fails (eg, is determined to fail) to meet QoS requirements. Alternatively), it may be determined to utilize the resource allocation corresponding to at least one TM of the one or more TMs for transmission of uplink data units.

Scheduling functions may be supported at the MAC layer. A scheduling mode may be selected. The available scheduling modes are network-based scheduling for resource-rigid scheduling, timing and/or transmission parameters for downlink and/or uplink transmissions, and/or more flexible with respect to timing and/or transmission parameters. WTRU-based scheduling may be included. The scheduling information may be valid for a single and/or one or multiple or many TTIs.

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

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

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.

Forward error correction (FEC) and/or block coding may be performed. A transmission may be encoded using a number of different encoding methods. Different encoding methods may have different properties. For example, the encoding method can 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 the first block may be sufficient for the second block and/or another block that is at least partly successfully decoded, especially if the second block is error-free. If significant redundancy is found, it may not impair the receiver's ability to successfully decode the second block.

An example encoding method may include a raptor/fountain code, in which the transmitter may contain a sequence of N raptor codes. One or more such codes may be mapped to one or more transmitted "symbols" in time. A "symbol" may correspond to one or more sets of information bits, eg, one or more octets. Such encoding can be used to add FEC to the transmission, whereby N+1 and/or N+2 raptor codes (and/or perhaps, given for example one raptor code symbol relation, symbol). This allows the transmission to be more resilient to the loss of one "symbol" due to, for example, interference and/or puncture by another transmission that overlaps in time.

A WTRU may receive and/or detect one or more system signatures. A system signature can contain a signal structure using a sequence. Such signals may be similar to synchronization signals, eg, LTE primary synchronization signals (PSS) and/or secondary synchronization signals (SSS). Such a signature may be unique to a particular node (and/or transmit/receive point (TRP)) within a given domain, or it may apply to multiple such nodes (and/or TRPs) within a domain. ) may be common to Such aspects may not be known to and/or relevant to the WTRU. A WTRU may determine and/or detect a 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 an index to look up associated parameters in a table, such as the access table described below. . For example, a WTRU may use open loop power control, e.g., for the purpose of setting an initial transmit power, if the WTRU determines that it can access (and/or transmit) using applicable resources of the system. The received power associated with the signature can be used to For example, a WTRU may use a received signature sequence, e.g., for purposes of timing transmissions, if the WTRU determines that it can access (and/or transmit) using system applicability. timing (eg, preambles on physical random access channel (PRACH) resources) can be used.

A WTRU may be configured with a list of one or more entries. Such lists are sometimes called access tables. Such lists can be indexed. One or more or each entry may be associated with a system signature and/or a sequence thereof. Such an access table can 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 be one or more sets of random access parameters (e.g., including applicable physical layer resources (e.g., PRACH resources) in time and/or frequency), initial power levels, and/or response At least one of the physical layer resources for reception may be included. Such parameters may include access restrictions, including, for example, public land mobile network (PLMN) identities 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). A WTRU may receive such an access table by transmission using dedicated resources, eg, by RRC configuration and/or by transmission using broadcasted resources. In the latter case, the periodicity of transmission of access tables may be relatively long (eg, up to 10240 ms), eg, it may be longer than the periodicity of transmission of signatures (eg, in the range of 100 ms).

FIG. 8 shows an example deployment supported and/or not supported by LTE. Initial deployments using a phased approach may deploy 5G systems 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, core network functions, and so on. Deployments can evolve such that 5G systems can become independent and LTE independent, eg unsupported.

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

A standalone 5gFLEX radio access network may be provided. For example, a standalone 5gFLEX radio access network may not be supported by an LTE network. Although solutions based on standalone 5G deployment architectures are described here, the solutions given here may also be applicable to LTE-supported architectures.

The 5G protocol stack can provide transport services for IP packets from a source node to a destination node over the wireless medium. FIG. 9 shows exemplary functionality of the 5G protocol stack at a high level. Depending on the implementation and/or configuration, the functions of the protocol stack are header compression, security, integrity protection, ciphering, segmentation, concatenation, multiplexing, ARQ, mapping to spectral modes of operation (SOM), modulation and/or Or it may include one or more of encoding, HARQ, and/or mapping to antennas/physical channels.

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, a logical association may be based on data units associated with the same bearer and/or associated with the same SOM and/or slice (eg, processing paths using a set of physical resources). For example, associations are characterized by one or more of a chain of processing functions, applicable physical data (and/or control) channels (and/or instances thereof), and/or protocol stack instantiations. may be a centralized part, such as PDCP (e.g. PDCP only) and/or some part beyond the physical layer processing part (e.g. radio front (RF) end) and/or a front hauling interface (e.g. another portion closer to the edge (eg, MAC/PHY and/or RF only in TRP) that may be separated by a front hauling interface).

A Logical Channel Group (LCG) may include a group of LCHs and/or equivalents (eg, as described above). LCG may have a different and/or broader meaning than similar terms in previous generations such as LTE systems. Grouping can be based on one or more criteria. For example, the criterion is one of the same LCG (similar to legacy), the same SOM (and/or its type), and/or one or more or all LCHs of the same slice (and/or its type) Or it may be that one or more LCHs have similar priority levels that are applicable to (and/or associated with) multiples. For example, associations are characterized by one or more of a chain of processing functions, applicable physical data (and/or control) channels (and/or instances thereof), and/or protocol stack instantiations. may be a centralized part (e.g. PDCP only and/or some part other than RF) and/or another part closer to the edge that may be separated by a fronthauling interface (e.g. MAC/PHY in TRP, and/or RF only).

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

TrCHs may or may not carry user plane data, Broadcast Channel (BCH), Paging Channel (PCH), Downlink Shared Channel (DL-SCH), Multicast Channel (MCH), Uplink Shared Channel (UL- SCH) and/or random access channel, may be defined (eg, for LTE) with one or more or multiple types of TrCHs. The main transport channels for carrying user plane data can be eg DL-SCH and/or UL-SCH for downlink and/or uplink respectively.

TrCH extends requirements supported by interfaces 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 set. TrCH may have a different and/or broader meaning than similar terms in previous generations such as LTE systems. For example, transport channels for URLLC (eg, URLLCH), mobile broadband (MBBCH), and/or machine type communications (MTCCH) may be used for downlink transmission (eg, DL-URLLCH, DL-MBBCH, and/or DL -MTCCH) and/or uplink transmissions (eg, UL-URLLCCH, UL-MBBCH, and/or UL-MTCCH).

For example, one or more or many TrCHs may be mapped to different sets of physical resources (eg 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, URLLCH may be transmitted along with MTCCH at the same time, eg, when a WTRU may be configured with SOM (eg, single SOM).

A WTRU may be configured with one or more parameters associated with characterizing how data may be transmitted. Characterizations may represent constraints and/or requirements that a WTRU may be expected to comply with and/or enforce. The WTRU may perform different actions and/or adjust its behavior depending on the state associated with the characterization-based data. The parameter may, for example, be a time-related aspect, such as the (e.g., per-packet) time-to-live (TTL) of a packet (which is the time before which a packet can be sent to meet and/or acknowledgment of meeting latency requirements), rate-related aspects, and/or configuration-related aspects (eg, absolute priority). The parameters may change over time, eg, while packets and/or data may be pending for transmission.

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

A WTRU may be configured with a (eg, single) HARQ entity. A WTRU may have a (eg, single) HARQ buffer for managing HARQ signals received across SOMs. A WTRU may be configured to transmit/receive any kind of traffic over any SOM. FIG. 10 shows at a high level an exemplary mapping between LCHs and one or more SOMs. For example, in FIG. 10, there may be one (eg, at least one) HARQ entity per WTRU. Retransmission can be done on any SOM.

FIG. 11 shows an exemplary (eg, 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 stacks herein include (this example assumes M IP packet flows (and/or radio bearers) and N SOMs) header compression and/or security mechanisms, security, segmentation/concatenation /ARQ, (inverse) multiplexing/prioritization, HARQ/SOM/carrier mapping and/or modulation, physical channel (PhCH)/SOM mapping. A header compression and/or security mechanism receives IP packets as input and/or, depending on configuration, performs header compression and/or applies security (eg, integrity protection, encryption). There can be as many blocks as there are radio bearers, M in this example. Security may reside in another network node, for example remote from the 5G cell/TRP.

Segmentation/concatenation/ARQ may be responsible for segmenting and/or concatenating PDUs according to available radio resources. ARQ functionality can ensure delivery. Demultiplexing/prioritization on the transmitting side (e.g., uplink to a WTRU) is responsible for multiplexing together one or more radio bearer PDUs and/or prioritizing transmission according to rules. be able to. Multiplexing and/or prioritization rules may be configured by higher layers. The output of demultiplexing/prioritization may be mapped to the SOM for transmission. Re-segmentation may be performed when needed. On the receiving side (eg, downlink to a WTRU), demultiplexing/prioritization demultiplexes the SDUs and/or pushes them to the appropriate segmentation/concatenation/ARQ entity. Mapping to HARQ/SOM/carrier 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 or more or any SOM. In modulation, the mapping to PhCH/SOM is encoded with appropriate symbols mapped to appropriate resources on at least one physical channel of the selected SOM _(1...N) Bits can be mapped.

A WTRU may be configured with a HARQ entity for one or more or each configured SOM. Logical channels can be assigned/mapped to any SOM. Retransmissions may not occur on one or more or any SOM. FIG. 12 shows an exemplary high level mapping between LCH and one or more SOMs. One or more or each logical channel may be mapped to a SOM. A SOM may be associated with at least one (eg, dedicated) HARQ entity. A 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 the (eg, best) SOM at one or more or each instant of a given PDU (perhaps according to predefined criteria, for example). FIG. 13 shows an example (eg, single) HARQ entity for each SOM technique in the context of a complete protocol stack and/or in the context of all features of a protocol stack. This exemplary protocol stack includes (this example assumes M IP packet flows (and/or radio bearers) and N SOMs) header compression and/or security mechanisms, security, segmentation/concatenation/ It may include one or more of ARQ, (de)multiplexing/prioritization, HARQ/SOM/carrier mapping and/or modulation, PhCH/SOM mapping. Similar functionality may be performed as described herein with respect to FIG. The mapping to SOM/carrier may be done before the HARQ entity. There may be N HARQ entities, eg, one or more or at least one for each SOM. One or more HARQ retransmissions may occur in the same SOM.

LCH may be mapped to SOM using predefined rules. The mapping can be based on various types of traffic and/or requirements of one or more SOM capabilities. 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. FIG. 14 shows an exemplary high level mapping between LCH and SOM. For example, at least one HARQ entity may be assigned per SOM. An LCH may be mapped to one or more or a single SOM.

FIG. 15 shows an example (eg, single) HARQ entity for each SOM technique in the context of a complete protocol stack and/or in the context of all features of a protocol stack. As shown, the exemplary protocol stack includes (this example assumes M IP packet flows (and/or radio bearers) and N SOMs) header compression and/or security mechanisms, security , segmentation/concatenation/ARQ, (de)multiplexing/prioritization, mapping to HARQ/SOM/carrier and/or modulation, mapping to PhCH/SOM. Similar functionality may be performed as described herein with respect to FIG. Although placed below segmentation/concatenation/ARQ, the mapping block to SOM/carrier may be placed higher in the stack even before header compression/security. After mapping to SOM/carrier, the WTRU may be configured with at least one set of one or more or each block for one or more or each SOM. A WTRU may prioritize per SOM. A WTRU may independently determine traffic priority for the (eg, one or more or each) SOM. ARQ retransmissions may occur in the same SOM. A WTRU may be configured by higher layers (eg, RRC signaling and/or other) with a SOM for (eg, one or more or each) radio bearers.

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

A temporary upgrade and/or downgrade of LCH may be performed. The LCH and/or radio bearer may maintain its general characteristics (e.g., priority and/or bandwidth requirements, etc.), but may have higher priority and/or higher priority, e.g. It can be upgraded to a low latency SOM. Specifically, a service can generally have certain characteristics, but the service can be "temporarily upgraded." A logical channel may be moved to a different SOM for a period of time during which it is temporarily upgraded. The underlying PHY treatment of the same radio bearer/logical channel may be changed.

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

A WTRU may perform autonomous transmissions under certain circumstances, such as when time-critical data arrives at the WTRU that takes precedence over other ongoing (cell-scheduled) transmissions. A WTRU may not be provided with the size and/or transport block parameters used by the cell. In response to triggers within the MAC layer and/or from higher layers, the WTRU may require immediate transmission into one or more MAC PDUs sent to the PHY layer for transmission. Higher layer SDUs can be multiplexed. Autonomous creation of transport blocks depends on the arrival of time-critical packets at the MAC layer and/or higher layers, QoS-based parameters associated with one or more packets and/or data below a threshold, periodic (e.g. , upon expiration of a timer), the creation and/or (re)configuration of latency-critical and/or other services and/or the creation and/or (re)configuration of the SOM, the MAC layer and/or its buffers from above is no longer empty, and/or buffer occupancy information from the MAC layer and/or higher layers, and/or retransmission of MAC PDUs may be useful. It may be triggered by one or more of the indicated HARQ entities.

A 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) that may be less than a certain threshold. At MAC PDU creation time, the WTRU may select SDUs whose TTL is less than a threshold and/or multiplex them within the same MAC PDU. If there are restrictions associated with mapping logical channels to transport channels, then individual MAC PDUs can be created for sending to the PHY layer while adhering to those restrictions. The WTRU may select SDUs whose TTL is below a threshold (e.g., periodically, possibly based on a timer) and/or perform multiplexing of these SDUs onto one or more MAC PDUs. can.

LCH to TrCH/SOM mapping and/or multiplexing may be performed. A WTRU may be configured to transmit data from different logical channels on different SOMs in the uplink. One, multiple, or many logical channels may be transmitted together on (eg, a single) transport channel (TrCH). A 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. A WTRU may dynamically (eg, autonomously) determine transmission parameters (including SOM and/or multiplexing).

Multiplexing and/or prioritization of one or more or multiple LCHs to one or 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 have been described in the context of associating or mapping LCHs to SOMs, similar techniques may also be applicable for multiplexing one or more or many LCHs.

A WTRU may determine transmission parameters based on a predetermined transport and/or service type. The WTRU's MAC layer differentiates a particular set of logical channels and/or service types such that a set of logical channels and/or services can be mapped to (eg, only) a particular transport channel. It can be multiplexed into a set of transport channels. The WTRU then configures the PHY so that a given transport channel can receive (eg, receive only) data associated with logical channels that can be mapped to that transport channel and/or its SOM. Transport blocks and/or data blocks that are transferred to the layer can be created.

Mappings between logical channels and associated transport channels may be statically defined based on standardized mappings. For example, the set of transport channels T1, T2, . . . TN may correspond to different service levels, quality of service and/or service guarantees provided by the PHY layer. A set of logical channels L1, L2, . . . LM may be defined. A 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. A WTRU may multiplex some specific logical channels onto a specific transport channel based on a 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 to T1, packets with service type S3 may be sent to T2, and so on.

A WTRU may determine transmission parameters based on service type, eg, ultra-reliable and/or low-latency communication (URLLC), MTC, eMBB, and the like. One or more specific transport channels may be associated with logical channels/flows/services associated with ultra-reliable communication. Certain transport channels may be associated with low latency communications. A particular transport channel may be associated with machine type communication (MTC). A particular transport channel may be associated with mobile broadband communication (MBB). Specific transport channels may be associated with WTRU control information and/or a final 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 can follow association rules.

A WTRU may determine transmission parameters based on the mapping configuration for each SOM. The mapping of logical channels and/or service types to transport channels may be configurable by the network, eg, through broadcast or dedicated signaling and/or use of access tables by WTRUs.

Multiplexed list mapping may be performed per SOM. For example, multiplexed lists can be mapped to SOMs. A multiplex list configuration may be generated for one or more or each LCH in one or more or each SOM. A WTRU may be configured (eg, via higher layers and/or RRC signaling) with a set of multiplexing rules. A WTRU may be configured with a previous (eg, enabled) set of SOMs to which it may be mapped for one or more or each LCH. A WTRU is configured with one or more or each SOM and/or one or more or each LCH with a set of one or more (eg other) LCHs that may be multiplexed together in a TrCH can be The network may allow one or more (eg, particular) LCHs to be multiplexed in a SOM, but perhaps not in different SOMs, eg, in some scenarios.

The WTRU may determine transmission parameters/data transfer parameters, perhaps based on, for example, meeting LCH requirements, among other scenarios. A WTRU may be configured with a set of requirements for one or more or each LCH. These requirements are for example latency and/or maximum delay, reliability, average bitrate, guaranteed bitrate, traffic and/or service type (e.g. ultra low latency/ultra high reliability, MTC, eMBB, voice , video streaming, control information, etc.), and/or QCI, etc.

A WTRU may be configured and/or itself determine a set of characteristics/capabilities of a configured SOM. These characteristics are, for example, TTI duration, bandwidth, symbol rate, coding characteristics (e.g., rate and/or reliability, etc.), set of modulation and coding schemes (MCS) supported, HARQ parameters (e.g., maximum number of retransmissions, incremental redundancy versus chase combining), subcarrier spacing, waveform and/or associated parameters (e.g., cyclic prefix length, guard, preamble, etc.), spectrum licensing mode (e.g., licensed, licensed unlicensed, lightly licensed, connectivity type (e.g. device-to-device (D2D) and/or wide area network (WAN)), relay or direct, destination and/or TRP receiver points, a set of supported traffic types, and/or a set of supported QCIs, and/or the like.

A WTRU may determine the set of LCHs that may be multiplexed together into a given transport block in a given SOM. For example, the WTRU may determine the mapping of one or more or each LCH to the SOM, possibly based on LCH requirements and/or SOM characteristics. A WTRU may determine for LCH whether the characteristics of a particular SOM satisfy the LCH requirements. The WTRU may determine (eg, a single) SOM for the (eg, one or more or each) LCH. A WTRU may determine a set of SOMs that may satisfy one or more LCH requirements for one or more or each LCH.

For example, the WTRU compares the latency requirement of the LCH with the minimum latency of the SOM and/or determines whether the SOM meets the latency requirement, eg, based on TTI length, HARQ feedback delay, and/or other parameters. can decide. In such scenarios, among other things, the WTRU may determine that the LCH may be mapped to its particular SOM. For example, the WTRU may compare the bitrate requirements of a particular LCH (eg, due to maximum MCS and/or available and/or configured bandwidth) to the maximum bitrate achievable by the SOM. , and/or possibly mapping the LCH to the SOM, eg, if it meets the requirements.

The WTRU may determine the mapping of LCH to SOM based on matching attributes of LCH, SOM. The WTRU may initiate LCH to SOM based on matching LCH requirements and/or one or more SOM characteristics, eg, using one or more of the requirements/characteristics described herein. A mapping can be determined. A WTRU may multiplex the LCH into the same SOM based on the destination.

A 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 specific devices (eg, L2 addresses). For example, an LCH may be associated with a particular TRP. A WTRU may configure an LCH associated with the same destination (eg, D2D, TRP, and/or other) for the associated SOM.

The WTRU may determine the LCH to SOM mapping based on the set of QoS Class Identifiers (QCIs) supported. A WTRU may be configured with a set of supported QCIs (eg, for one or more or each SOM). A WTRU may determine a set of SOMs for one or more or each LCH, possibly based on configured LCH QCIs, for example. The WTRU may determine that the LCH can be mapped to the SOM when (eg, only when) there is an exact QCI match. A WTRU may be configured to determine the set of SOMs that at least satisfy the QCI of the LCH.

A WTRU may determine the mapping of LCH to SOM based on supported traffic types. A 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, possibly based on the LCH traffic type, for example. For example, the SOM may be configured to support best effort traffic (eg, 60 GHz, unlicensed). A WTRU maps best effort LCH to its SOM and/or maps other types of traffic (eg, conventional voice, ultra-reliable, and/or other) to different SOMs (eg, in the 2 GHz band) can do.

Mapping of LCH to SOM/TrCH may be performed dynamically. Transport channels may be selected based on transport layer state/attribute information. A WTRU selects from one or more (eg, available) transport channels (eg, T1 and/or T2) to which a particular logical channel may be mapped and/or a particular higher layer packet may be transmitted. can do. The WTRU may make such determinations based on dynamic conditions of the transport channel (eg, at a given time) and/or MAC entity information. The information includes 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, .

FIG. 16 illustrates an example of a WTRU (eg, a WTRU processor and/or controller) dynamically matching data units to TrCHs that may satisfy the data unit's QoS requirements. One or more or each data unit may have its own QoS requirements (QoS_1, QoS_2, etc.). In some scenarios, one or more data units may have the same QoS requirements. Data unit requirements may include one or more of latency, reliability, data rate and/or transport block size, and/or QCI, and/or the like. The WTRU may one or more of numerology (eg, which may include subcarrier spacing and/or associated symbol periods), MCS, coding rate, TTI period, reliability, HARQ retransmissions, and/or delay , may be configured with one or more or multiple transport channels each having their own characteristics.

A WTRU may determine a target TrCH for one or more or each data unit by matching requirements with TrCH capabilities. This ensures that the data unit requirements are met, possibly at least to a satisfactory degree. In FIG. 16, data units from LCH _M can be mapped to TrCH _N . A (eg, a particular) data unit of LCH ₁ with QoS ₂ may be routed to TrCH _N because, for example, its QoS requirement (eg, QoS ₂ ) may not be met by TrCH ₁ in this scenario. LCH ₁ and LCH _M data units (e.g., those mapped to TrCH _N ) are probably, for example, data units sufficiently large (e.g., within determined and/or preconfigured tolerances and/or thresholds) If they have matching QoS requirements, they can be multiplexed together.

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

A WTRU may receive such dynamic transport layer state information from the PHY layer. For example, based on information dynamically provided by the PHY layer and/or statically associated with particular transport channels and/or transport channel types, the MAC layer may make its decisions of mapping. can. Such information may include 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 used by the transport channel). TTI), HARQ information such as HARQ process type, number or processes, occupancy of one or more or each process, status of available HARQ processes on the associated transport channel (e.g. pending transmission or replay). transmission), the SOM to which the transport channel is mapped, and/or the maximum transport block size supported and/or currently allowed for the transport channel. can contain.

One or more transmission channels may be reserved for retransmissions. One or more special transport channels may be reserved specifically for retransmission purposes by WTRUs. A WTRU may retransmit a PDU using at least one of the reserved transport channels when the transmission of the PDU fails at a layer (eg, MAC/RLC/etc). These transport channels are HARQ processes that allow shorter TTIs and/or more HARQ transmissions in shorter time periods, higher coding rates, lower modulation schemes, and/or higher transmit power. It can have specific PHY/MAC attributes, including type.

Mismatched multiplexing of LCH may be avoided or reduced. The WTRU may dynamically determine which LCH sets out of the enabled LCH sets 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.

Transmission characteristics for large amounts of data may be determined based on latency requirements associated with small amounts of data. For example, an LCH with low latency requirements can be multiplexed with logical channels with much higher latency requirements. LCHs associated with very different reliability requirements may be multiplexed.

Multiplexing constraints may be imposed based on logical channels. For example, a WTRU may perform MAC segmentation/assembly over (eg, only over) MAC SDUs associated with a particular logical channel/service type/priority. For example, the MAC layer performs 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 reliable transmission. be able to.

SOM/transport channels may be selected and/or multiplexed for transmission of control information. The MAC layer may send different types of control information over different underlying transport channels and/or PHY resource types. For example, MAC CEs may be of different types. A WTRU may decide whether to transmit such a MAC CE on a given transport channel, and/or a particular set of MAC SDUs and/or SDU segments and MAC CEs can be multiplexed.

For example, a WTRU may have different MAC CEs for transmission of buffer status reports (BSRs) associated with its low latency logical channels. The WTRU may send a message such as "ULL MAC CE" over (eg, only over) a dedicated ULL transport channel (eg, by piggybacking the MAC CE on the transport block containing the ULL MAC PDU). CE can be sent. However, such restrictions may allow non-ULL MAC CEs to be sent with ULL resources and/or they may be sent using (eg, only using) non-ULL transport block resources. may need to be

For example, high priority MAC CEs may be associated (eg, exclusively) with transport channels dedicated to the transmission of such information. Transport channels may be associated with dedicated PHY resources, for example.

A WTRU may multiplex the LCH upon request up to a certain percentage of the primary LCH. For example, a WTRU may be configured with a set of parameters that control the amount of data of varying requirements that can be multiplexed together.

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

A WTRU may be configured with a ratio ρ, which indicates the maximum amount of data from non-primary LCH sets 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 Np bits from the primary LCH set are to be transmitted in a particular transport block, the WTRU may transfer up to Nnon−p<ρ×Np bits from the non-primary LCHs to the same transport block. can be multiplexed in In embodiments, the non-primary LCH and/or the primary LCH may include (eg, include only) the LCH for which data is available in the associated buffer.

WTRUs may multiplex LCHs based on their associated data types. The WTRU may multiplex the LCH such that differences in data types can be minimized. The WTRU has a minimum percentage of data for a particular type (e.g., logical channel type, service type, latency requirements, etc.) so that the MAC PDU can be associated with that type for assembly. A MAC SDU can be selected. For example, the WTRU ensures that the maximum possible number of low latency SDUs and/or SDU segments are assembled together and/or minimizes the number of non-low latency segments that are assembled together with low latency segments. can do.

A WTRU may associate logical channels, MAC SDUs, and/or SDU segments with particular multiplexing categories and/or classes. Categories and/or classes may be defined as logical channels, types of data (time-critical vs. high reliability requirements vs. high efficiency requirements), severity of latency requirements for associated data, and/or QoS-based criteria associated with data. Any combination of parameters may be associated. A WTRU has a certain minimum percentage of data in a PDU associated with its category and/or class (eg, 60% of the data is associated with time-critical data, where the TTL may be below a certain threshold) A MAC PDU can be created as follows. Low-latency MAC SDU segments can be mostly placed within a PDU that consists primarily of low-latency data. The underlying PHY layer can treat such MAC PDUs with high priority. Categories and/or classes may be defined in a dynamic fashion. For example, based on the current data being transmitted, the WTRU may create specific states that may define classes.

A WTRU may multiplex LCH and/or SDUs based on latency characteristics (eg, TTL range). A WTRU may perform multiplexing of MAC SDUs by taking into account latency characteristics associated with the SDUs and/or associating together MAC SDUs that can meet certain QoS-based characteristics.

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

A WTRU may multiplex the LCH with different latency requirements. For example, a WTRU may multiplex and/or transmit data packets with latency requirements greater than or equal to ΔLatency apart in the same transport block. The parameter/variable ΔLatency may be a fixed value configured by the network and/or may be fixed by specification. The parameter/variable ΔLatency may be dynamically and/or semi-dynamically signaled to the WTRU.

The WTRU may multiplex based on the TTI duration and/or multiplex on the SDUs as utilized at the PHY layer. A WTRU may segment/assemble MAC SDUs based on the TTI duration to be utilized for transmission on the PHY layer. A WTRU may associate MAC SDUs and/or logical channels/flows/services with (eg, specific) TTIs. SDUs may be assembled/segmented such that (eg, one or more or all) SDU segments used in creating a MAC PDU can utilize the same TTI value. An SDU segment may be substantially a TTI period during which the PHY layer transmits a PDU. A TTI associated with a particular MAC SDU may be determined by the WTRU. For example, TTIs may be statically and/or dynamically associated with logical channel/service type data in MAC SDUs via signaling by the cell and/or based on certain internal states 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 (eg, potentially in combination with other methods). For example, the PHY layer may have a TTI of 0.5 ms available at a given point in time and/or time period and/or be used for logical channel groups with index x and/or larger It can be shown that For example, a TTI may be defined by QoS-based parameters associated with a logical channel. For example, if the TTL for the 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, and so on. Once the pending SDU with the current TTI value is included, the WTRU may include SDUs associated with different TTIs in the associated grant.

A WTRU may send one or more or multiple transport blocks (TB) of the LCH with different requirements using one or multiple or multiple TrCHs. Data with widely varying requirements can be transmitted simultaneously. A WTRU may transmit (eg, simultaneously) one, multiple, or multiple transport blocks on each of its TrCHs.

Based on the specific scheduling decisions made by the WTRU (e.g., TTL, logical channel prioritization (LCP), and/or buffer occupancy of such rules), the WTRU has highly varying characterizations and /Or more than one set of data can be scheduled, with highly varying service types and/or requirements, and the like. A WTRU may use different transport formats to transmit MAC PDUs associated with such different service types. A WTRU may transmit different transport blocks using the same grant from the cell and/or the same semi-static resource provided to the WTRU.

A WTRU may receive (dynamically and/or semi-statically) a grant that may indicate a set of available PHY resources (such as the number of transport blocks). A WTRU may receive an indication of the radio quality of such resources, eg, via downlink channel state information (CSI) feedback. A WTRU may make autonomous decisions regarding the transport format to utilize when transmitting on these resources (eg, based on the radio quality associated with those resources).

A WTRU may split the grant spectrum for one or more or each TrCH. The WTRU divides the PHY resources into separate portions to be associated with one or more or each of the transport blocks to be transmitted. A WTRU may restrict splitting based on specific rules associated with specific associations such as carriers or resource blocks. For example, a WTRU may not be allowed to split resource blocks between two different transport blocks to transmit. A WTRU may associate different transport formats (MCS, HARQ type, TTI, retransmission rules, etc.) with one or more or each of the transport blocks to be transmitted simultaneously. A WTRU may indicate to a cell the particular transport format to be utilized for transmission. Such signaling may be included within the transmission itself (eg, based on the methods described herein). A WTRU may include such signaling in a dedicated control channel used for UL PHY signaling.

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.

A WTRU may prioritize traffic based on associated latency requirements. For example, the WTRU may schedule MAC PDUs for transmission based on the time criticality of the data and/or the time available for data in previous MAC PDUs where the data is considered to have missed its timing requirements. can be selected. For example, a 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. can.

At a particular scheduling instant and/or TTI and/or at a particular time when PHY resources are available to the WTRU, the WTRU has the lowest TTL and/or TTL range among the pending MAC PDUs pending of MAC PDUs can be selected. A WTRU may select one or more or multiple available PDUs for transmission, possibly at the same time and/or at substantially the same time, for example. The WTRU may select the buffered PDU that has the lowest TTL and/or TTL range.

A WTRU may perform assembly in combination with the scheduling criteria described herein. For example, the WTRU may select the MAC SDU with the lowest TTL in satisfying the grant and/or available resources for transmission, and/or perhaps, e.g., the lowest TTL of pending MAC SDUs. Multiplexing/assembly can be performed to include MAC SDUs with

A WTRU may make such scheduling decisions regarding a subset of transport channels and/or SOMs, and the like. For example, a WTRU may make such scheduling decisions on (eg, only on) transmissions for a subset and/or TRPs. A WTRU may make such scheduling decisions when (eg, only when) it is granted a resource grant on a particular transport channel and/or SOM (eg, associated with a ULLRC transmission). can.

A WTRU may prioritize traffic based on the PHY layer that provides the grant's TTI. For example, the MAC layer can make its scheduling decisions based on the TTI that can be provided by the PHY layer. The MAC layer can receive the TTIs in which it can transmit along with the information of the transmission grant. The WTRU may select MAC SDUs to be multiplexed onto the MAC PDU based on knowledge of this TTI. 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 transmission. A WTRU may select MAC SDUs whose TTL may be less than a certain threshold. A WTRU may receive one or more or multiple grants that may apply to different TTIs and/or different TTI lengths.

The MAC layer can dynamically select and/or determine the TTI length used to transmit MAC PDUs. Such decisions may be made by the WTRU on the TTI and/or at the scheduling instant itself. This determination may be made at 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 the available resources.

A WTRU may receive an indication of a particular resource and/or resource set from which the MAC layer can select a TTI. A WTRU may select data to be transmitted on resources with reduced TTIs based on scheduling decisions and/or prioritization rules. This determination may allow data with time-critical requirements to be transmitted within the time required when taking into account potential retransmissions. For example, the MAC layer may receive an indication (potentially information from the PHY layer) of the location and/or amount of resources for which the shortened TTI may be utilized. The MAC layer can receive an indication of the current data being sent and/or the TTL associated with this data. The MAC layer can schedule transmissions based on this information by ensuring that latency-critical transmissions are performed successfully. A particular TTI to use for a particular MAC PDU may not be restricted. Transport block sizes for such planned transmissions 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.

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.) can be multiplexed onto the same MAC PDU, which the WTRU may include in the MAC PDU before performing legacy LCP procedures. MAC SDUs that may be time-critical to the time may be selected first.

Specifically, the WTRU may decide which MAC SDUs are considered time-critical. This determination is based on the fact that the TTL associated with the SDU is below a threshold, the TTL associated with the SDU that is below the threshold has expired, the specific logical channels and/or flows identified by the WTRU as being latency critical. the size of the SDU is below a certain threshold, and/or the SDU may indicate a retransmission that has already been transmitted (e.g., without success) in a previously transmitted PDU. can be based on one or more.

The WTRU may include the selected SDU in the MAC PDU it transmits. A WTRU may include SDUs in an order according to some specific criteria, such as QoS-based parameters, size, and/or logical channel priority. If the MAC PDU size is insufficient to contain the time-critical SDUs, the WTRU triggers the PHY layer to include as many SDUs as will fit in the MAC PDU by considering the potential order of inclusion. , causing a request for more resources to be transmitted and/or including a request for more resources (e.g., PHY layer indication of more resources) in the transmission of this MAC PDU, BSR and/or similar MAC Including the CE to indicate this state to the cell, triggering autonomous transmissions in the WTRU, which may include additional time-critical SDUs, and/or request resources, and/or this MAC PDU. may do one or more of triggering the PHY layer to take advantage of the shortened TTI for the transmission of .

A WTRU may run legacy LCP to serve a logical channel up to 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.

The WTRU may select MAC SDUs for the rest of the MAC PDUs 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 (eg, TTL greater than first threshold but less than second threshold).

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

The WTRU may determine the time-criticality (e.g., min-to-max TTL) and/or based on any QoS-based parameter (e.g., TTL below threshold) until a MAC SDU with a particular time-criticality is addressed. Alternatively, the MAC SDUs for creation of the MAC PDU can be selected by selecting the MAC SDUs in order of importance. The remainder of the MAC PDU size may be used to embed control data (MAC CE) and/or increase coding and/or redundancy.

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

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

A WTRU may determine the order in which PDUs that do not meet its latency requirements may be discarded. More specifically, the WTRU may be configured to determine the order in which PDUs are transmitted according to the delay requirements of the PDUs (eg, according to first) and/or according to priority. If there are not enough resources to transmit a PDU, the WTRU discards PDUs with a lower priority index (e.g., when the packet expires, it removes the PDU from its buffer and/or does not attempt to transmit it). ) can be determined as

A WTRU may (eg, autonomously) select transmission parameters. A transport format can be selected. For example, a WTRU may select a transport format from a pre-configured list associated with traffic type, LCH, and/or SOM.

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

Different transport formats may be associated with services and/or service types (eg, ULRRC transport format (TF), and/or eMBB TF, etc.). Transport formats may be associated with different levels of reliability (eg, error probability) and/or transmission rates.

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

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

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

The WTRU may prepend/postfix the uplink transmission (the granted resource itself) with an index that may be encoded using a predefined and/or fixed mechanism. Such a transport format indicator from the WTRU may be present with the UL transmission. The WTRU may not provide such an indication and/or the cell may require blind decoding first to determine the selected TF.

A WTRU may receive an indication of a particular TF in the grant, but may decide to change the TF dynamically and/or inform the cell of this decision. A WTRU may be restricted to change the TF of grants (eg, only that) on MAC PDUs that may contain data from a particular logical channel and/or a particular service. The WTRU may be restricted to change the TF from the currently signaled TF to a finite set of "derived" TFs that may have a certain relationship to the original TF (hence the derived facilitate signaling of the TF to the cell).

A WTRU may change the TF to add additional encoding to scheduled data, eg, to increase robustness. The decision to add additional encoding is based on reliability and/or latency requirements associated with the data that needs to be sent, QoS-based data associated with the data to be sent and/or other data pending transmission. It can be based on one or more of the parameters, buffer occupancy or lack thereof, and/or whether the MAC PDU is being retransmitted or whether it is the initial transmission of the PDU.

After processing a certain number of logical channels (e.g., up to a Prioritized Bit Rate (PBR), for example) and/or a certain number of MAC SDUs, which may take into account latency-critical requirements, the WTRU may, for example, It can be decided not to include additional SDUs in the MAC PDU. A WTRU may indicate to the PHY layer to increase (eg, by reducing the code rate) the redundancy associated with a particular MAC PDU. For example, after a MAC SDU with a TTL below the threshold is included in the MAC PDU and/or the logical channel is served up to the PRB, the WTRU does not include additional MAC SDUs ready for transmission within the MAC PDU. can reduce the coding rate (at the PHY layer) of the resulting MAC PDU.

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

Although features and elements are described above in particular combinations, those skilled in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied on a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks or removable disks, magneto-optical media, and CD-ROMs. Including, but not limited to, optical media such as discs and digital versatile discs (DVDs). A software related processor may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims (16)

A wireless transmit/receive unit (WTRU),
is a processor;
receiving configuration information for a plurality of logical channels, said configuration information including information indicating requirements associated with each of said plurality of logical channels;
receiving an indication of physical channel resources, said indication of physical channel resources being associated with a transmission period;
selecting one or more of the plurality of logical channels based on one or more requirements associated with the one or more of the plurality of logical channels satisfied by the transmission period; a processor configured to
a transmitter configured to transmit data associated with the selected one or more of the plurality of logical channels;
, a WTRU. 2. The WTRU of claim 1, wherein the physical channel resource further comprises at least one of bandwidth, symbol rate, coding characteristics, set of supported modulation and coding schemes (MCS), or numerology. 2. The WTRU of claim 1, wherein the transmission duration is 1 millisecond (ms) or less. 3. The WTRU of claim 2, wherein the numerology comprises subcarrier spacing or associated symbol periods. such that the processor selects the one or more of the plurality of logical channels according to a logical channel prioritization (LCP) procedure that defines the requirements associated with each of the plurality of logical channels. 2. The WTRU of claim 1, further configured to: 6. The WTRU of claim 5, wherein the requirements include low latency service requirements or ultra-reliable service requirements. 2. The WTRU of claim 1, wherein the processor configured to receive the indication of physical channel resources is configured to receive downlink control information (DCI). the physical channel resources comprise subcarrier spacing;
the processor configured to select one or more of the plurality of logical channels selects one or more of the plurality of logical channels from the plurality of logical channels filled by the subcarrier spacing; 8. The WTRU of claim 7, configured to select based on one or more requirements associated with said one or more of. A method implemented by a wireless transmit/receive unit (WTRU), comprising:
receiving configuration information for a plurality of logical channels, said configuration information including information indicative of requirements associated with each of said plurality of logical channels;
receiving an indication of physical channel resources, said indication of physical channel resources being associated with a transmission duration;
selecting one or more of the plurality of logical channels based on one or more requirements associated with the one or more of the plurality of logical channels satisfied by the transmission period; and,
transmitting data associated with the selected one or more of the plurality of logical channels;
A method, including 10. The method of claim 9, wherein the physical channel resource further comprises at least one of bandwidth, symbol rate, coding characteristics, set of supported modulation and coding schemes (MCS), or numerology. 10. The method of claim 9, wherein the transmission period is 1 millisecond (ms) or less. 11. The method of claim 10, wherein the numerology includes subcarrier spacing or associated symbol periods. further comprising selecting said one or more of said plurality of logical channels according to a logical channel prioritization (LCP) procedure that defines said requirements associated with each of said plurality of logical channels; 10. The method of claim 9. 14. The method of claim 13, wherein the requirements include low latency service requirements or ultra-reliable service requirements. 10. The method of claim 9, wherein receiving the indication of physical channel resources comprises receiving downlink control information (DCI). the physical channel resources comprise subcarrier spacing;
10. The method of claim 9, wherein each of said one or more of said plurality of logical channels is associated with one or more requirements met by said subcarrier spacing.

Images