Handling user plane in wireless systems

Abstract

Systems, methods, and instrumentalities are presented for handling a user plane in a wireless communication system. The wireless communication system can be characterized by a flexible air interface. One aspect of the flexible air interface is that transmissions made by wireless transmit / receive units (WTRUs) in the system can have different quality of service (QoS) requirements, e.g., different latency requirements. The WTRUs can adjust their behavior based on the QoS requirements, e.g., by using preconfigured resources, resource requests, and / or self-scheduling, etc., so that transmissions can be performed in accordance with the corresponding QoS requirements.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201780021388.5, filed on March 29, 2017, entitled "Processing the User Plane in a Wireless System," the entire disclosure of which is incorporated herein by reference.

[0002] Cross-references to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application 62 / 315,373, filed March 30, 2016, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0004] Mobile communication technology is constantly evolving and is on the verge of its fifth generation—5G. 5G networks can be built on flexible radio access technologies. With the emergence of these new technologies, challenges arise in determining how to support various use cases with different characteristics. Summary of the Invention

[0005] This document discloses systems, methods, and tools for transmitting uplink data from a wireless transmit / receive unit (WTRU) to a network. Uplink data may include uplink data units (e.g., uplink data packets), and the transmission of uplink data units can be performed in a manner that satisfies specific Quality of Service (QoS) requirements. These QoS requirements may be timing requirements. As an example, a QoS requirement may be to transmit uplink data units with relatively low latency.

[0006] The WTRU can maintain a Time-to-Live (TTL) parameter for monitoring uplink data unit transmission delay. For example, the TTL parameter value could reflect the amount of time elapsed since the uplink became available for transmission and / or the amount of time remaining before the uplink data unit is assumed to be transmitted. The WTRU can determine a threshold for the TTL parameter based on QoS requirements and can attempt to transmit the uplink data unit using a first transmission mode, and determine if the TTL parameter value has reached the threshold before successful transmission. The WTRU can then attempt to transmit the uplink data unit using a second transmission mode, for example, before the TTL parameter expires.

[0007] The second transmission mode can differ from the first transmission mode in one or more ways. For example, the WTRU can use a pre-configured set of resources to transmit uplink data units in the second transmission mode. The WTRU can receive such pre-configured resources, for example, from the network. The network can reserve the pre-configured resources for transmissions characterized by specific QoS requirements, such as QoS requirements associated with pending uplink data units. The network can specify that the pre-configured resources will be shared by multiple WTRUs.

[0008] A WTRU can receive pre-configured resources upon its initial registration with the network. Alternatively or supplementarily, the WTRU can receive pre-configured resources from the network using dedicated signaling (e.g., after the WTRU has already registered with the network). The WTRU can obtain access to the pre-configured resource set via an uplink transmission to the network. As an example, this uplink transmission could indicate when the WTRU wishes to use the pre-configured resources. The WTRU can receive a response from the network in response to the uplink transmission.

[0009] In the second transmission mode, the WTRU can send uplink control information (UCI) to the network. This UCI may contain a request for resources. The UCI may indicate QoS requirements associated with an uplink data unit, or the parameter configuration (numerology) of the uplink data unit. The WTRU can receive a permission from the network in response to the UCI. This permission may indicate which resources the WTRU can use in the second transmission mode. Alternatively or supplementarily, the permission may specify the spectrum operating mode (SOM) or transport channel available for the WTRU to use in the second transmission mode. For example, the permission may specify the parameter configuration and / or waveform available for the WTRU to use in the second transmission mode.

[0010] In the second transmission mode, the WTRU can interrupt the existing Hybrid Automatic Repeat Request (HARQ) process in order to transmit uplink data units. Attached Figure Description

[0011] A more detailed understanding can be obtained from the following description, illustrated with the accompanying diagram, in which:

[0012] Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0013] Figure 1B It is possible Figure 1A The diagram shows an example of a wireless transmit / receive unit (WTRU) used within a communication system.

[0014] Figure 1C It is possible Figure 1AThe diagram shows an example radio access network and an example core network used within the communication system.

[0015] Figure 1D It is possible Figure 1A The system diagram shows another example of a radio access network and another example of a core network used within the communication system.

[0016] Figure 1E It is possible Figure 1A The system diagram shows another example of a radio access network and another example of a core network used within the communication system.

[0017] Figure 2 This is an illustration of an example of bandwidth flexibility.

[0018] Figure 3 This is an illustration of an example of flexible spectrum allocation.

[0019] Figure 4A This is a diagram illustrating an example of the timing relationship in TDD duplexing.

[0020] Figure 4B This is a diagram illustrating an example of the timing relationship in FDD duplexing.

[0021] Figure 5 This is a diagram illustrating an example of prioritized transmissions. Detailed Implementation

[0022] Specific embodiments will now be described with reference to the accompanying drawings. While this description provides detailed examples of possible embodiments, it should be noted that these details are illustrative and do not limit the scope of this application.

[0023] The following abbreviations and acronyms will be used in the description of the exemplary embodiments:

[0024] Δf Subcarrier spacing

[0025] 5GFlex 5G Flexible Radio Access Technology

[0026] 5GNB 5GFlex Node B

[0027] ACK response

[0028] BLER block error rate

[0029] BTI (Base TI, an integer multiple of the duration of one or more symbols)

[0030] CB is based on contention (e.g., access, channel, resources).

[0031] CoMP Cooperative Multipoint Transmission / Reception

[0032] CP cyclic prefix

[0033] CP-OFDM vs. Conventional OFDM (depending on the cyclic prefix)

[0034] CQI Channel Quality Indicator

[0035] CN core network (e.g., LTE packet core)

[0036] CRC Cyclic Redundancy Check

[0037] CSI Channel State Information

[0038] CSG Closed Subscriber Group

[0039] D2D device-to-device transmission (e.g., LTE sidelink)

[0040] DCI Downlink Control Information

[0041] DL downlink

[0042] DM-RS demodulation reference signal

[0043] DRB Data Radio Bearer

[0044] EMBB Enhanced Mobile Broadband

[0045] EPC Evolved Packet Core

[0046] FBMC filter bank multicarrier

[0047] FBMC / OQAM uses offset quadrature amplitude modulation (OQAM) FBMC

[0048] FDD (Frequency Division Duplex)

[0049] FDM (Frequency Division Multiplexing)

[0050] FEC Forward Error Correction

[0051] ICC Industrial Control and Communications

[0052] ICIC Inter-cell Interference Cancellation

[0053] IP Internet Protocol

[0054] LAA Licensed Assisted Access

[0055] LBT Listen before you speak

[0056] LCH Logical Channel

[0057] LCG (Logical Channel Group)

[0058] LCP Logical Channel Priority

[0059] LLC Low Latency Communication

[0060] LTE Long Term Evolution, for example, moving up from 3GPP LTE Release 8.

[0061] MAC Media Access Control

[0062] NACK (Negative)

[0063] MBB Massive Broadband Communications

[0064] MC Multicarrier

[0065] MCS modulation and coding scheme

[0066] MIMO (Multiple Input Multiple Output)

[0067] MTC Machine Type Communication

[0068] NAS Non-Access Layer

[0069] OFDM (Orthogonal Frequency Division Multiplexing)

[0070] OFDMA (Orthogonal Frequency Division Multiple Access)

[0071] Out-of-band (OOB) radiation

[0072] PBR (Priority Bit Rate)

[0073] P cmax Specify the total available UE power in TI.

[0074] PHY physical layer

[0075] PRACH (Physical Random Access Channel)

[0076] PDU Protocol Data Unit

[0077] PER (Grouping Error Rate)

[0078] PL path loss (estimated)

[0079] PLMN Public Land Mobile Network

[0080] PLR packet loss rate

[0081] PSS Master Synchronization Signal

[0082] QoS (Quality of Service) from a physical layer perspective

[0083] RAB Radio Access Bearer

[0084] RACH (Random Access Channel or Procedure)

[0085] RF radio front end

[0086] RNTI Radio Network Identifier

[0087] RRC Radio Resource Control

[0088] RRM Radio Resource Management

[0089] RS reference signal

[0090] RTT round trip time

[0091] SCMA (Single Carrier Multiple Access)

[0092] SDU Service Data Unit

[0093] SOM Spectrum Operating Mode

[0094] SS synchronization signal

[0095] SSS auxiliary synchronization signal

[0096] SRB signal radio bearer

[0097] SWG switching interval (within a self-contained subframe)

[0098] TB transfer block

[0099] TBS (Transfer Block Size)

[0100] TDD (Time Division Duplex)

[0101] TDM (Time Division Multiplexing)

[0102] TI time interval (an integer multiple of one or more BTIs)

[0103] TTI (Transmission Time Interval) (an integer multiple of one or more TIs)

[0104] TRP Transmit / Receive Point

[0105] TRx transceiver

[0106] UFMC Universal Filtering Multicarrier

[0107] UF-OFDM Universal Filtering OFDM

[0108] UL uplink

[0109] URC Ultra-Reliable Communication

[0110] URLLC Ultra-Reliable Low-Latency Communication

[0111] V2V vehicle-to-vehicle communication

[0112] V2X vehicle communication

[0113] WLAN (Wireless Local Area Network) and related technologies (IEEE 802.xx domain)

[0114] WTRU Wireless Transmit / Receive Unit

[0115] Figure 1A This is an illustration of an example communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system providing voice, data, video, messaging, broadcasting, and other content to multiple wireless users. The communication system 100 allows multiple wireless users to access such content by sharing system resources, including wireless bandwidth. As an example, the communication system 100 can use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Orthogonal Frequency Division Multiplexing with Offset Orthogonal Amplitude Modulation (OFDM-OQAM), Universal Filtered Orthogonal Frequency Division Multiplexing (UF-OFDM), and so on.

[0116] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c and / or 102d (which are generally collectively referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110 and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks and / or network components.

[0117] The communication system 100 may also include multiple base stations, such as base station 114a and base station 114b. Each base station 114a, 114b may be any type of device configured to enable access to one or more communication networks by wirelessly interfacing with at least one of WTRUs 102a, 102b, 102c, 102d, which may be a core network 106 / 107 / 109, the Internet 110, and / or network 112. As an example, base stations 114a, 114b may be a base transceiver station (BTS), a node B, an e-node B, a home node B, a home e-node B, a site controller, an access point (AP), a wireless router, etc. Although each base station 114a, 114b is described as a single component, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0118] Base station 114a may be part of RAN 103 / 104 / 105, and the RAN may also include other base stations and / or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals within a specific geographical area called a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, each transceiver corresponds to one sector of the cell. In another embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology, thereby allowing multiple transceivers to be used for each sector of the cell.

[0119] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0120] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, OFDM-OQAM, UF-OFDM, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN103 / 104 / 105 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), and this technology can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0121] In another embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE), Advanced LTE (LTE-A), and / or 5g FLEX to establish air interfaces 115 / 116 / 117.

[0122] In other embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement radio access technologies such as IEEE 802.16 (Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate Evolution for GSM (EDGE), and GSM EDGE (GERAN).

[0123] As an example, Figure 1A Base station 114b can be a wireless router, home node B, home e node B, or access point, and can use any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, residence, vehicle, campus, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In another embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c, 102d can establish a picocell or femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, 5G FLEX, etc.). Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b does not necessarily need to access the Internet 110 through core networks 106 / 107 / 109.

[0124] RANs 103 / 104 / 105 can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. While in Figure 1AAlthough not shown, it should be understood that RAN103 / 104 / 105 and / or core networks 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT or a different RAT as RAN103 / 104 / 105. For example, in addition to connecting with RAN103 / 104 / 105 using E-UTRA radio technology, core networks 106 / 107 / 109 can also communicate with other RANs (not shown) using GSM radio technology.

[0125] Core networks 106 / 107 / 109 can also act as gateways for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). The Internet 110 may include a global interconnected computer network system using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. 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, which may use the same RAT or a different RAT as RAN 103 / 104 / 105.

[0126] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability; in other words, the WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links. For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a using cellular-based radio technology, and with base station 114b using IEEE 802 radio technology.

[0127] Figure 1B This is a system diagram illustrating WTRU 102. (Example) Figure 1B As shown, WTRUs 102a, 102b, 102c, and 102d may include a processor 118, a transceiver 120, a transmitter / receiver unit 122, a speaker / microphone 124, a numeric keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while maintaining compliance with the embodiments, WTRU 102 may also include any sub-combination of the foregoing components.

[0128] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving unit 122. Although Figure 1B While the processor 118 and transceiver 120 are described as separate components, it should be understood that the processor 118 and transceiver 120 can be integrated into a single electronic component or chip.

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

[0130] In addition, although Figure 1B While the transmit / receive component 122 is described as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may use MIMO technology. Therefore, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive radio signals via air interfaces 115 / 116 / 117.

[0131] The transceiver 120 of WTRU 102 can be configured to modulate signals to be transmitted by the transmitting / receiving unit 122 and demodulate signals received by the transmitting / receiving unit 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers that allow WTRU 102 to communicate using various RATs such as UTRA and IEEE 802.11.

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

[0133] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device that powers the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (such as nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0134] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117, and / or determine its location based on signal timing received from two or more nearby base stations. It should be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable positioning method.

[0135] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game console modules, internet browsers, etc.

[0136] Figure 1C This is a system diagram of RAN 103 and core network 106 according to one embodiment. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c using E-UTRA radio technology and via air interface 115. RAN 103 can also communicate with core network 106. Figure 1C As shown, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c via air interface 115. Each of nodes B 140a, 140b, and 140c may be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of nodes B and RNCs while remaining consistent with the embodiments.

[0137] like Figure 1C As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can also communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each RNC 142a and 142b can be configured to control its connected node B 140a, 140b, or 140c. Furthermore, each RNC 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, permission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0138] Figure 1CThe core network 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Node Switching Center (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing components is described as part of the core network 106, it should be understood that entities other than the core network operator may also own and / or operate any of these components.

[0139] RNC 142a in RAN 103 can connect to MSC 146 in core network 106 via the IuCS interface. MSC 146 can then connect to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment.

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

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

[0142] Figure 1D This is a system diagram of RAN 104 and core network 107 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c using E-UTRA radio technology and via air interface 116. Furthermore, RAN 104 can also communicate with core network 107.

[0143] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each eNodeB 160a, 160b, and 160c may include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0144] Each eNodeB 160a, 160b, or 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. For example... Figure 1D As shown, nodes B160a, 160b, and 160c can communicate with each other on the X2 interface.

[0145] Figure 1D The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the above components is described as part of the core network 107, it should be understood that entities other than the core network operator may also own and / or operate any of these components.

[0146] MME 162 can connect to each eNodeB 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attach process of WTRUs 102a, 102b, and 102c, etc. MME 162 can also provide control plane functions to perform handovers between RAN 104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

[0147] Service gateway 164 can connect to each eNodeB 160a, 160b, 160c in RAN 104 via the S1 interface. Service gateway 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, 102c. In addition, service gateway 164 can perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when downlink data is available to WTRUs 102a, 102b, 102c, managing and storing the context of WTRUs 102a, 102b, 102c, etc.

[0148] Service gateway 164 can also be connected to PDN gateway 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as the Internet 110, in order to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

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

[0150] Figure 1E This is a system diagram of RAN 105 and core network 109 according to one embodiment. RAN 105 may be an Access Service Network (ASN) communicating with WTRUs 102a, 102b, and 102c on air interface 117 using IEEE 802.16 radio technology. As further discussed below, communication links between different functional entities of WTRUs 102a, 102b, and 102c, RAN 105, and core network 109 can be defined as reference points.

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

[0152] The air interface 117 between WTRUs 102a, 102b, and 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 standard. Additionally, each WTRU 102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. This logical interface between WTRUs 102a, 102b, and 102c and the core network 109 can be defined as an R2 reference point, which can be used for authentication, licensing, IP host configuration management, and / or mobility management.

[0153] The communication link between each base station 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transmission between base stations. The communication link between base stations 180a, 180b, and 180c and ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each WTRU 102a, 102b, and 180c.

[0154] like Figure 1EAs shown, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which, as an example, includes protocols used to facilitate data transmission and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the aforementioned components is described as part of core network 109, it should be understood that entities other than the core network operator may also own and / or operate any of these components.

[0155] MIP-HA can handle IP address management and allow WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA Server 186 can handle user authentication and support user services. Gateway 188 can facilitate interoperability with other networks. For example, Gateway 188 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as the PSTN 108, facilitating communication between WTRUs 102a, 102b, and 102c and legacy terrestrial communication equipment. Additionally, gateway 188 can also provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0156] Although Figure 1E Although not shown, it should be understood that RAN 105 can connect to other ASNs, and core network 109 can connect to other core networks. The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the movement of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference point, which may include protocols for facilitating interoperability between the home core network and the visited core network.

[0157] The exemplary communication systems described herein can support air interfaces capable of implementing one or more of the following: Improved Broadband Performance (IBB), Industrial Control and Communication (ICC), Vehicle-to-Everything (V2X) applications, and Massive Machine-Type Communication (mMTC). The air interface can support Ultra-Low Latency Communication (LLC), Ultra-Reliable Communication (URC), and / or MTC operation (including narrowband operation as an example). For LLC, one or more of the following can be supported: low air interface latency (e.g., 1 millisecond RTT), short TTI (e.g., between 100 and 250 microseconds), ultra-low access latency (for example, access latency can be associated with the amount of time from initial system access to completion of the first user plane data unit transmission), and / or low end-to-end (e2e) latency (e.g., less than 10 milliseconds in ICC and / or V2X). As for URC, as an example, transmission / communication reliability will achieve a transmission success rate of 99.999% and / or service availability. The desired mobility has a speed range of 0-500 km / h. The packet loss rate can be designed to be less than 10e. -6 (For example, in ICC and V2X). For MTC operation, the air interface can support narrowband operation (e.g., using less than 200 kHz), extended battery life (e.g., autonomy up to 15 years) and / or reduced communication overhead (as an example, at least for small and / or infrequent data transmissions, such as transmissions with data rates ranging from 1 to 100 kbps and / or access latency of several seconds to several hours).

[0158] The exemplary communication system described herein can use OFDM as the waveform (e.g., at least on the downlink). OFDM can be the basic data format for data transmission in LTE and / or 802.11. For OFDM, the spectrum can be divided into multiple parallel orthogonal subbands. Subcarriers can be shaped using rectangular windows in the time domain, thereby producing sinusoidal subcarriers in the frequency domain. OFDMA can be designed to attempt to achieve a high level of frequency synchronization and / or uplink timing calibration within the duration of the cyclic prefix (for example, thereby maintaining orthogonality between signals and / or minimizing inter-carrier interference). In exemplary communication systems designed to achieve other design goals as described above, meeting the synchronization requirements of OFDM (e.g., conventional OFDM or CP-OFDM) can be quite challenging (for example, since WTRUs can be connected to multiple access points simultaneously). Additional power reduction processing can be applied to uplink transmissions to meet the spectral radiation requirements of adjacent frequency bands (e.g., in the presence of segmented spectrum aggregation for WTRU transmissions). Given these challenges, the exemplary communication system described herein may impose more stringent RF requirements on CP-OFDM (e.g., when using a large contiguous spectrum that does not rely on aggregation). If used, CP-OFDM-based transmission schemes may result in a downlink physical layer similar to that of legacy systems (e.g., in the case of modifications to pilot signal density and location).

[0159] The exemplary communication system described herein can use other waveforms. For example, the downlink transmission scheme in this exemplary communication system can be based on a multicarrier (MC) waveform. As an example, an MC waveform can be characterized by high spectral constraints (e.g., low sidelobes and / or low OOB radiation). The MC waveform can divide the channel into subchannels, and data symbols can be modulated on the subcarriers in these subchannels. The exemplary MC waveform is OFDM-OQAM. For OFDM-OQAM, as an example, filters can be applied to the OFDM signal in the time domain (e.g., according to the subcarrier) to reduce OOB. OFDM-OQAM may cause very low interference to adjacent frequency bands, may not require a large guard band, and does not use a cyclic prefix. OFDM-OQAM can be a suitable FBMC technique. However, it should be noted that in some exemplary systems, OFDM-OQAM may be very sensitive to multipath interference and high delay spread in terms of orthogonality. The equalization and channel estimation processing for OFDM-OQAM can be quite complex.

[0160] Another example of a usable MC waveform is UFMC (UF-OFDM). For UFMC (UF-OFDM), filters can be applied to OFDM symbols in the time domain (e.g., to reduce OOB). In one example, the filtering can be applied along the sub-band so that spectral segmentation can be used (e.g., to reduce implementation complexity). If some spectral segments in a band are unused, then the OOB emissions in those segments may be high (as an example, this could happen with conventional OFDM). At least for this reason, UF-OFDM would be a waveform suitable at least for use at the edges of the filtered spectrum.

[0161] It should be noted that the waveforms described herein are examples, and therefore the only waveforms described in the embodiments herein cannot be implemented. These exemplary waveforms can at least enable multiplexing of signals with non-orthogonal characteristics (e.g., signals with different subcarrier spacings). These exemplary waveforms can allow asynchronous signals to coexist (e.g., in situations where complex interference cancellation receivers are not required). These exemplary waveforms can facilitate segmented spectrum aggregation in baseband processing, thereby serving as a low-cost alternative to the processing used for aggregating segmented spectrum as part of RF processing.

[0162] In the illustrated communication system, different waveforms may coexist within the same frequency band (as an example, at least to support mMTC narrowband operation using SCMA). Combinations of different waveforms, such as CP-OFDM, OFDM-OQAM, and / or UF-OFDM, can be supported for some or all operational aspects and / or for one or both of downlink and uplink transmissions. As an example, waveform coexistence may include transmissions using different waveform types between different WTRUs, or transmissions from the same WTRU (for example, the transmissions may be simultaneous, have some overlap, or be continuous in the time domain).

[0163] As an example, other coexistence aspects may include: support for mixed-type waveforms (e.g., support for waveforms and / or transmissions with potentially variable CP durations, such as those varying with transmission), support for combinations of CP with low-power tails (e.g., zero tails), and / or support for some form of mixed guard interval (e.g., using low-power CP and / or adaptive low-power tails), etc. The illustrated waveforms may support dynamic changes and / or control over one or more other aspects, such as filtering. For example, one or more of the following may be dynamically changed and / or controlled: whether filtering is applied at the edges of the spectrum used to receive transmissions with respect to a specified carrier frequency, whether filtering is applied at the edges of the spectrum used to receive transmissions associated with a specific SOM, whether filtering is applied by subband or by group, etc. Generally, waveforms / waveform types can be considered as examples of transmission parameters that can be changed to achieve different types of transmission schemes. Thus, a first transmission scheme may use a first type of waveform (e.g., CP-OFDM), while a second transmission scheme may use a different waveform (e.g., OFDM-OQAM). Different waveforms may be associated with different transmission characteristics, such as different potential throughput, different delay characteristics, different overhead requirements, etc.

[0164] The uplink transmission scheme can use the same or different waveforms as the downlink transmission scheme. Multiplexing of transmissions between different WTRUs within the same cell can be based on FDMA and / or TDMA.

[0165] The exemplary communication system described herein can be characterized by a high degree of spectral flexibility. This spectral flexibility allows (e.g., enables) deployment in different frequency bands with different characteristics, such as different duplex arrangements and / or different sizes of available spectrum (e.g., including, for example, continuous and discontinuous spectrum allocations in the same or different frequency bands). This spectral flexibility can support variable timing aspects, examples of which include support for multiple TTI lengths and / or support for asynchronous transmission.

[0166] The exemplary communication system described herein can be characterized by flexibility in duplex configuration. For example, this exemplary communication system can simultaneously support TDD and FDD duplex schemes. For FDD operation, supplementary downlink operation can be supported using spectrum aggregation. Both full-duplex FDD and half-duplex FDD operation can be supported. For TDD operation, DL / UL allocation can be dynamic. For example, the allocation is not based on a fixed DL / UL frame configuration; instead, the length of the DL or UL transmission interval can be set according to the transmission timing.

[0167] The exemplary communication system described herein can be characterized by flexibility in bandwidth allocation. For example, different transmission bandwidths can be enabled for uplink and / or downlink transmissions (for example, the range of which could be from the nominal system bandwidth to the maximum bandwidth corresponding to the system bandwidth). In the exemplary single-carrier operation, for example, the supported system bandwidth could include at least 5, 10, 20, 40, and 80 MHz. In one example, the supported system bandwidth could be any bandwidth within a specified range (e.g., from several megahertz to 160 MHz). The nominal bandwidth can have one or more values ​​(e.g., one or more fixed values). Supported narrowband transmissions up to 200 kHz can be provided (as an example, this transmission could be within the operating range of an MTC device).

[0168] Figure 2 The illustration shows an example of the transmission bandwidth that a communication system can support. The system bandwidth referred to here can be associated with the maximum portion of the spectrum managed by a specified carrier network. For such a carrier, the portion of the spectrum that the WTRU can support (e.g., the minimum support) for cell acquisition, measurement, and initial network access can correspond to the nominal system bandwidth. The WTRU can be configured to have a channel bandwidth that falls within the entire system bandwidth range. The channel bandwidth configured for the WTRU may or may not include the nominal portion of the system bandwidth.

[0169] One illustrative reason for achieving bandwidth flexibility in the exemplary communication system described herein is that some or all applicable RF requirements for a specified operating bandwidth (e.g., maximum operating bandwidth) can be met without introducing additional licensed channel bandwidth for that operating band. As an example, this is due to efficient support for baseband filtering of relevant frequency domain waveforms. The embodiments described herein can utilize techniques for configuring, reconfiguring, and / or dynamically changing WTRU channel bandwidth for single-carrier operation. The embodiments described herein can allocate spectrum for narrowband transmission within the nominal system bandwidth, system bandwidth, or configured channel bandwidth. The physical layer of this exemplary communication system can be band-agnostic. This physical layer can support operation in licensed bands (e.g., below 5 GHz) and unlicensed bands (e.g., in the 5-6 GHz range or higher). For operation in unlicensed bands, the supported channel access framework can be based on LBT Cat 4 (e.g., a channel access framework similar to LTE LAA). The embodiments described herein can utilize techniques for scaling and / or managing cell-specific and / or WTRU-specific channel bandwidth for different spectrum block sizes. As examples, these techniques can be associated with scheduling, addressing resources, broadcasting signals, measurement, and so on. The size of the spectrum block can be arbitrary.

[0170] The exemplary communication system described herein is characterized by its flexibility in spectrum allocation. Downlink control channels and signaling can support FDM operation. The WTRU can capture downlink carriers, for example, by receiving transmissions via a nominal portion of the system bandwidth (e.g., only the nominal portion). For instance, the WTRU is not initially configured to receive transmissions via the full bandwidth managed by the relevant carrier network.

[0171] Downlink data channels can be allocated on bandwidths that correspond to or do not correspond to the nominal system bandwidth. As an example, unlike within the channel bandwidth configured for a WTRU, this allocation can be unrestricted. For instance, a carrier can operate with a nominal bandwidth of 5 MHz and a system bandwidth of 12 MHz. This arrangement allows devices supporting a maximum RF bandwidth of 5 MHz to acquire and access the system, while allocating the carrier frequency +10 to -10 MHz to other WTRUs supporting channel bandwidths up to 20 MHz.

[0172] Figure 3 Examples of spectrum allocations that can assign different subcarriers to (e.g., at least conceptually) different SOMs are shown. Different SOMs can be used to meet different requirements of different transmissions. An SOM may include or be defined based on one or more of the following: subcarrier spacing, TTI length, or reliability aspects (e.g., HARQ processing aspects). An SOM may include an auxiliary control channel. For example, an SOM may include a separate control channel (e.g., separate from the main control channel), where an associated WTRU can be configured to monitor that channel. An SOM may be used to refer to a specific waveform or may be associated with processing aspects, such as supporting the coexistence of different waveforms on the same carrier using FDM and / or TDM, or the coexistence of FDD and TDD (e.g., performing FDD operation in a TDD band, for example, in a TDM manner).

[0173] A WTRU can be configured to perform a transmission according to one or more SOMs. For example, an SOM may correspond to a transmission using one or more of the following: a specific TTI duration, a specific initial power level, a specific HARQ processing type, a specific upper limit for successful HARQ reception / transmission, a specific transmission mode, a specific physical channel (uplink or downlink), a specific waveform type, or a transmission according to a specific RAT (as an example, the transmission may use legacy LTE or 5G transmission technologies). An SOM may correspond to a QoS level and / or related aspects, such as maximum / target delay, and / or maximum / target BLER, etc. An SOM may correspond to a spectrum region and / or a specific control channel or aspects thereof (e.g., search space, DCI type, etc.). As an example, a WTRU can be configured to have an SOM for one or more of the following: URC service type, LLC service type, or MBB service type. The WTRU may have (e.g., the WTRU can receive) SOM configurations for system access and / or for transmitting / receiving L3 control signaling (e.g., RRC). As an example, the WTRU can be configured to use a portion of the system spectrum, such as the nominal system bandwidth described here, to send and / or receive L3 control signaling.

[0174] The resources specified for a SOM can be defined or described according to the parameter configurations for that SOM. For example, a first SOM may use a first parameter configuration (e.g., first subcarrier spacing, first symbol length, first TTI length, first bandwidth, first waveform type, etc.), and a second SOM may use a second parameter configuration (e.g., second subcarrier spacing, second symbol length, second TTI length, second bandwidth, second waveform type, etc.). Here, the terms SOM and parameter configurations are used interchangeably.

[0175] The WTRU in the exemplary communication system described herein can be configured to switch to a different transmission scheme if the WTRU determines that a transmission cannot be successfully completed using the original transmission scheme. The transmission scheme described herein can include resources, transmission technologies, transmission parameters, and / or other operational aspects related to transmission performance. For example, different transmission schemes may use different SOMs and / or different parameter configurations. Thus, the SOM and / or parameter configurations can be examples of operational aspects that can be changed for different types of transmission schemes.

[0176] The exemplary communication system described herein can support spectrum aggregation (e.g., at least for single-carrier operation). For example, spectrum aggregation can be supported if the WTRU can transmit and / or receive multiple transport blocks on contiguous and / or discontiguous sets of Physical Resource Blocks (PRBs) within the same operating frequency band. Transport blocks can be mapped to separate sets of PRBs. Transports associated with different SOMs can be performed simultaneously.

[0177] The exemplary communication system described herein supports multi-carrier operation. As an example, this support can be provided by using contiguous and / or discontinuous spectrum blocks on the same operating frequency band or on two or more operating frequency bands. The exemplary communication system can support spectrum block aggregation. For example, spectrum blocks can be aggregated using different modes such as FDD and / or TDD, and / or supported using different channel access technologies, such as licensed and unlicensed band operation below 6 GHz. The multi-carrier aggregation operation of the WTRU can be configured, reconfigured, and / or dynamically changed by the network and / or the WTRU.

[0178] Downlink and / or uplink transmissions can be organized into radio frames. These radio frames can be characterized by several fixed aspects (e.g., the location of downlink control information) and / or several variable aspects (e.g., transmission timing and / or supported transmission types). The Basic Time Interval (BTI) can be represented by the number of one or more symbols (e.g., an integer). The symbol duration can depend on the subcarrier spacing applicable to the time-frequency resources. At least for FDD, the subcarrier spacing is determined by the uplink carrier frequency f used to specify the frame. UL and downlink carrier frequency f DL The time interval (TTI) varies between these intervals. The Transmission Time Interval (TTI) can be the minimum time between consecutive transmissions supported by the system. One or more (e.g., each) consecutive transmissions can be associated with the downlink (TTI) interval. DL ) and / or uplink (UL TR) x The TTI is associated with different transport blocks (TBs). Downlink and / or uplink preorder codes may be excluded during TTI determination (if applicable). Control information (e.g., DCI for downlink or UCI for uplink) may be included during TTI determination. The TTI may be represented by the number (e.g., an integer) of one or more BTIs. BTIs may be specific and / or associated with a specified SOM and / or parameter configuration.

[0179] The exemplary communication systems described herein can support different frame durations, examples of which include 100 microseconds, 125 microseconds (1 / 8 millisecond), 142.85 microseconds (e.g., 1 / 7 millisecond or 2 nCP LTE OFDM symbols), and / or 1 millisecond. The frame duration can be set to be calibrated with legacy LTE timing architectures. A frame can have a fixed duration t. dci The downlink control information (DCI) begins at the frequency of the carrier involved (for example, f for TDD). UL +DL, for FDD is f DL Before any downlink data transmission (DL TRx) related to the uplink frame. For TDD duplex (e.g., for TDD duplex only), the frame may contain a downlink portion (e.g., DCI and / or DL ​​Rx) and / or an uplink portion (e.g., UL TRx). If a handover gap (swg) exists, it may precede the uplink portion of the frame. For FDD duplex (e.g., for FDD duplex only), the frame may include a downlink reference TTI and / or one or more TTIs for the uplink. The start of the uplink TTI can be an offset (t) applied from the start of a downlink reference frame that may overlap with the start of the uplink frame. offset This can be derived from the fact that duplex mode (e.g., TDD compared to FDD) can be an example of operational aspects that can be changed for different transmission schemes.

[0180] The exemplary communication system described herein can support D2D / V2x / sidelink operation within a frame. This exemplary communication system can use various configurations / techniques to provide D2D / V2x / sidelink support. In one example (e.g., when using TDD), the exemplary communication system can include the corresponding downlink and forward transmissions in the DCI+DL TRx portion of the frame (e.g., when using semi-static resource allocation) or in the DL TRx portion of the frame (e.g., when using dynamic resource allocation). As a supplement or alternative, the exemplary communication system can include the corresponding reverse transmissions in the UL TRx portion of the frame. In one example (e.g., when using FDD), for instance, by including the corresponding downlink control, forward, and reverse transmissions in the UL TRx portion of the frame, the exemplary communication system can support D2D / V2x / sidelink operation in the UL TRx portion of the frame. Furthermore, the resources associated with the corresponding transmissions can be dynamically allocated.

[0181] Figure 4A The example TDD frame structure is shown. Figure 4B The example FDD frame structure is shown.

[0182] The exemplary communication systems described herein can utilize various scheduling and / or rate control techniques, examples of which include scheduling functions in the MAC layer, network-based scheduling modes, and / or WTRU-based scheduling modes. For instance, a network-based scheduling mode results in intensive scheduling of resources, timing, and / or transmission parameters for downlink and / or uplink transmissions. As an example, a WTRU-based scheduling mode results in flexibility in timing and / or transmission parameters. For one or more scheduling techniques (e.g., scheduling modes), scheduling information can be in effect within a single TTI or multiple TTIs. A scheduling technique (e.g., scheduling mode) can be an example of an operational aspect that can be modified for different types of transmission schemes.

[0183] Network-based scheduling enables the network to intensively manage radio resources assigned to different WTRUs (e.g., for optimizing such resource sharing). In at least some cases, the network can implement this scheduling dynamically. WTRU-based scheduling enables WTRUs to access (e.g., timely access) uplink resources with minimal latency based on demand and / or within a set of shared or dedicated uplink resources assigned by the network. These shared or dedicated uplink resources can be dynamically or statically assigned. WTRUs can be configured to perform synchronous and / or asynchronous timely transmissions. WTRUs can be configured to perform contention-based and / or contention-free transmissions. For example, WTRUs can be configured to meet ultra-low latency requirements (e.g., for 5G) and / or energy-saving requirements (e.g., in mMTC use cases) by performing timely transmissions (e.g., scheduled or unscheduled).

[0184] The exemplary communication system described herein can prioritize logical channels. For example, this exemplary communication system can be configured to associate data and resources (e.g., for uplink transmissions). This exemplary communication system can multiplex data with different QoS requirements within the same transport block, for example, where such multiplexing does not negatively impact the QoS requirements of the service or unnecessarily waste system resources. Logical channel prioritization can be an example of an operational aspect that can be modified for different types of transmission schemes.

[0185] The exemplary communication system described herein can encode the transmission using different coding techniques. Different coding techniques can have different characteristics. The coding technique can produce a sequence having one or more information units or blocks. The information units or blocks (e.g., each information unit or block) can be self-contained. For example, if the second information block is error-free, and / or if sufficient redundancy can be found in the second information block or at least partially successfully decoded different information blocks, then errors in the transmission of the first information block will not impair the receiver's ability to successfully decode the second information block.

[0186] The exemplified encoding technique may include raptor / fountain codes, thus the transmission may include a sequence having N raptor codes. One or more such codes may be temporally mapped to one or more transmission symbols. A transmission symbol may correspond to one or more sets of information bits (e.g., one or more octets). By using this encoding technique, FEC can be added to the transmission, thus, if a relationship exists where each symbol has a raptor code, the transmission can use N+1 or N+2 raptor codes or symbols. This makes the transmission more resilient to symbol loss, which, for example, may be attributable to interference and / or puncturing caused by other transmissions that overlap temporally. The encoding / decoding technique may be an example of an operational aspect that can be varied for different types of transmission schemes.

[0187] The WTRU can be configured to receive and / or detect one or more system signatures. System signatures may include a signal structure using sequences. This signal may resemble a synchronization signal. A system signature may be specific to a particular node or TRP within a designated area (e.g., uniquely identifying that node or TRP), or it may be common to multiple such nodes or TRPs within the area. One or more of the foregoing aspects may be unknown to the WTRU and / or may be irrelevant to the WTRU. The WTRU can determine and / or detect the system signature sequence and may further determine one or more parameters associated with the system. For example, the WTRU may derive an index and use that index to retrieve the associated parameters (e.g., the WTRU may retrieve parameters from a table such as the access table described herein). The WTRU may use the received power associated with the system signature to perform open-loop power control (e.g., to set initial transmission power if the WTRU determines that it can use applicable system resources for access and / or transmission). As an example, if the WTRU determines that it can use applicable system resources for access and / or transmission, then the WTRU may use the timing of the received signature sequence to set transmission timing (e.g., a preamble on a PRACH resource). Different signal structures can be associated with different SOMs and / or different parameter configurations. In this way, the signal structure can serve as an example of operational aspects that can be varied for different types of transmission schemes.

[0188] A WTRU can be configured to have a list of entries (e.g., operating parameters), and this list may be referred to as an access table. While called an access table, it should be noted that the list of entries can be stored using any suitable type of structure, including a table structure. The list of entries or the access table can be indexed so that entries (e.g., each entry) can be associated with a system signature and / or its sequence. The list or access table can provide initial access parameters for one or more areas. For example, entries in the list (e.g., each entry) can provide one or more parameters associated with the initial access of the executing system. As an example, such parameters may include one or more random access parameters, such as applicable physical layer resources (e.g., PRACH resources) in time and / or frequency, initial power level, and / or physical layer resources for receiving responses. Such parameters may include access restrictions, such as PLMN identification and / or CSG information. Such parameters may include routing-related information, such as applicable routing areas. Entries (e.g., each entry) may be associated with and / or indexed by a system signature. Entries (e.g., each entry) may be shared by multiple nodes or TRPs. The WTRU can receive such a list or access table via transport on dedicated resources (e.g., RRC configuration) and / or transport using broadcast resources. In at least the latter case, the period for transporting the access table can be very long (e.g., up to 10240 milliseconds). As an example, the period for transporting the access table can be longer than the period for transport signing (for example, this period could be within the range of 100 milliseconds). The aforementioned access table can be an example of operational aspects that can be varied for different types of transport schemes.

[0189] The exemplary communication system described herein can support a variety of use cases. Each use case may include different QoS requirements. These use cases may differ in terms of applicable radio resources and / or transmission technologies. For example, these use cases may differ in TTI duration, reliability, diversity applied to transmission, maximum latency, etc. QoS differences can be introduced for different data packets, data streams, and / or data bearers (or their equivalents). These differences can be measured by maximum guaranteed delay budget, packet error rate, and / or data rate, etc. The MAC layer can handle one or more of the functions described herein to access all subsequent aspects or subsets thereof.

[0190] Given the different characteristics of various possible radio resources and / or transmission technologies, the WTRU can be configured to request, determine, and / or access resources (e.g., appropriate uplink transmission resources) that support the QoS requirements of the data service. Given the different characteristics of various possible resource allocations (e.g., in the uplink and / or downlink), the WTRU can be configured to exercise control over downlink and uplink transmissions (e.g., for controlling licensing and / or resource allocation) (e.g., determining and processing one or more types of allocations in different ways). Given the different characteristics associated with different transport blocks, the WTRU can be configured to multiplex and / or assemble MAC PDUs that meet applicable QoS requirements. For example, the WTRU can assign data associated with different bearers, and / or different logical connections, according to a set of extended rules (e.g., by considering the QoS attributes of the data involved and / or the SOM associated with the TB involved). Given the use cases and transmission technologies described herein, the WTRU can be configured to satisfy one or more prerequisites for uplink transmissions (as an example, these prerequisites may include ULTA, location, WTRU speed, PL estimation, etc.). For example, WTRU can manage and / or determine whether it has the prerequisites sufficient to perform a specified type of transport.

[0191] This exemplifies how a communication system can perform scheduling and / or scheduling-related operations based on QoS requirements. A network scheduler cannot always independently implement all types of QoS requirements for all types of data. For example, network-based scheduling functions may lack timely information and / or precise knowledge regarding the QoS requirements associated with uplink transmissions available in the WTRU buffer. The WTRU can be configured to enable services with stringent reliability and / or latency requirements (for example, these behaviors enable the WTRU to receive URLLC services). The WTRU can influence how and what data is transmitted (e.g., using additional parameters). For example, the WTRU can be configured to have one or more parameters associated with a characteristic description of how data is transmitted. This characteristic description can represent the constraints and / or requirements expected to be met and / or implemented when the WTRU transmits data. Based on this characteristic description, for example, the WTRU can perform different operations and / or adjust its behavior based on the state and / or characteristics of the data (e.g., depending on the state and / or characteristics of the data).

[0192] The exemplary communication system described herein may include one or more time-related QoS requirements (e.g., time-related characteristics). As an example, these time-related QoS requirements are beneficial when the network scheduler cannot implement timing / delay requirements independently (e.g., at least for a subset of data available for transmission). The WTRU can be configured to transmit data associated with one or more specific time-related QoS requirements. Depending on these time-related QoS requirements, the WTRU can modify one or more operational aspects of a specified transmission scheme used to transmit data. For example, if the WTRU is nearing the end of transmission due to unsuccessful data transmission using a first transmission scheme (e.g., failure to meet one or more time-based QoS requirements), the WTRU can switch to a second transmission scheme by modifying one or more operational aspects of the first transmission scheme to attempt and successfully transmit data before the time-based QoS requirements terminate.

[0193] The time-based QoS requirements described herein may include a maximum time allowed for satisfying one or more aspects of data transmission (e.g., uplink data transmission). The WTRU may determine whether this maximum time has been reached or exceeded based on observation and / or estimation. Time-based QoS requirements may include a maximum amount of time allowed for acquiring appropriate resources for data transmission. The WTRU may determine the time associated with acquiring appropriate resources by monitoring the control channel. For example, the WTRU may determine this time based on permission received via the control channel, and / or based on parameters announced by signaling in the control channel, etc. The WTRU may determine the time associated with acquiring appropriate resources by monitoring the SOM associated with resource acquisition. The WTRU may determine the time associated with acquiring appropriate resources by monitoring one or more states of the WTRU. As examples, such states may include whether the WTRU is synchronized or asynchronous, whether a scheduling request is in progress, etc.

[0194] Time-based QoS requirements can include the maximum time data is allowed to remain in the WTRU's transmit buffer. The WTRU can be configured to determine this maximum time based on the initial transmission timing of the data. For example, the WTRU can be configured to determine how long data remains in the WTRU's transmit buffer by maintaining a timer that tracks the time elapsed from when the data enters the transmit buffer until the initial transmission of that data begins.

[0195] Time-based QoS requirements can include the maximum amount of time it takes for data transmission to reach the HARQ working point. Taking the x-th transmission of a PDU containing relevant data as an example, the time it takes for the WTRU to reach the HARQ working point can be determined as the time it takes for the WTRU to perform the (x-1)-th retransmission of that PDU.

[0196] Time-based QoS requirements can include the time allowed for successful data transmission or for receiving feedback related to the transmission of a PDU containing data. A WTRU can determine this time based on when it receives HARQ feedback; for example, this feedback could be a HARQ ACK for a corresponding transport block.

[0197] Time-based QoS requirements can include a maximum time-to-live (TTL) associated with data. As an example, this TTL parameter can be associated with data packet transmission and other actions taken by the WTRU in response to the data packets. For instance, the WTRU can maintain (e.g., be configured to have) a TTL parameter with a threshold (e.g., N milliseconds) associated with data packet transmission. The WTRU can monitor the time elapsed since a data packet became available for transmission (e.g., after the WTRU receives a data packet from its buffer). If the threshold is reached without successfully transmitting a data packet, the WTRU can determine that the TTL has expired. The WTRU can then perform different actions based on the total remaining TTL. For example, the WTRU can switch to a different transmission scheme when it determines that the TTL has reached a threshold.

[0198] Time-based QoS requirements can include the maximum amount of time allowed to complete tasks such as radio-bearer-based logical grouping of data. Time-based QoS requirements can also include the maximum amount of time allowed for worst-case scenarios or head-of-queue latency. WTRUs can be configured to determine this latency based on the amount of data that has been consumed for the longest time in that WTRU buffer.

[0199] Time-based QoS requirements can include average or on-time time associated with one or more aspects of data transmission. The WTRU can determine such average or on-time time based on observation and / or estimation. For example, time-based QoS requirements can include the average amount of time that data can remain in the WTRU's transmission buffer (e.g., associated with the same logical channel, group, and / or SOM). The WTRU can be configured to determine this average time, for example, based on the period between the time when data is available for transmission and the time when the data is transmitted. As an example, the WTRU can determine the time when such data is available for transmission based on the timing of initiating the process for requesting and / or acquiring resources and / or the timing of transmitting signals for this effect. As an example, the WTRU can determine the time to transmit the data based on the timing of the initial transmission of the data or the timing of receiving an ACK corresponding to the data transmission. The average values ​​described herein can be moving averages (e.g., within a window of a specific length), burst-by-burst averages associated with the data, averages from when the WTRU last requested resources for such data, or averages from when the WTRU first acquired resources for transmitting such data.

[0200] Time-based QoS requirements can include permissible variations relative to the average time. For example, this variation could correspond to a decrease or increase in the average. Using the aforementioned buffer time as an example, the timing requirement could specify that the amount of time data is allowed to remain in the WTRU transmission can only exceed the average time by a specified amount.

[0201] Time-based QoS requirements can include the average or on-time time allowed to reduce the amount of data in the WTRU buffer. For example, this average or on-time time can be associated with a process that reduces the amount of data in the WTRU buffer to a certain level (which, by example, is configurable). This level can correspond to other time-related characteristics described herein, such as the maximum time allowed for a successful transmission. The WTRU can determine this average time based on estimations or observations.

[0202] Time-based QoS requirements can include average or on-time times for worst-case scenarios or queue head delays. WTRU can be configured to determine this average or on-time time based on the delays of multiple worst-case scenarios.

[0203] Time-based QoS requirements can include average or on-time time allowed for performing logical data grouping processes (e.g., based on radio bearers, etc.).

[0204] Time-based QoS requirements can be associated with HARQ entities, HARQ process types, and / or ongoing HARQ processes.

[0205] The WTRU can determine that the transmission of an uplink data unit (e.g., an uplink data packet) has QoS requirements. As described herein, QoS requirements can be time-related QoS requirements associated with one or more aspects of the uplink transmission. The WTRU can attempt to transmit the uplink data unit using a first transmission scheme. As an example, the WTRU can determine, at least for a subset of the data available for transmission, whether the first transmission scheme can satisfy the QoS requirements. For example, the WTRU can determine, based on the QoS requirements, that the TTL parameter maintained by the WTRU for the uplink data unit should not exceed a certain threshold. As an example, the TTL parameter can reflect the amount of time elapsed from when the uplink data unit becomes available for transmission until the uplink data unit is successfully transmitted. The WTRU can monitor the TTL parameter, and once it determines that the TTL has reached the threshold before successfully transmitting the uplink data unit using the first transmission scheme, the WTRU can select a second transmission scheme to transmit the uplink data unit. As described in more detail herein, the second transmission scheme will differ from the first transmission scheme in at least one operational aspect.

[0206] The exemplary communication system described herein may include one or more transmission rate-related requirements (e.g., transmission rate-related characteristics). As stated herein, the network scheduler is not always able to implement transmission rate-related requirements independently (e.g., at least for the subset of data available for transmission in the WTRU). The WTRU may be configured to cause data grouping processing to be associated with transmission rate-related requirements. Such grouping processing may include logical associations between data packets and / or PDUs, such as LCH, LCG, association of data with SOM and / or one or more aspects thereof, and / or association of data with radio bearers, etc. As an example, the WTRU may be configured to have a transmission rate for such data (e.g., a prioritized bit rate). The WTRU may use this transmission rate to determine how much data should be included in the transmission (e.g., by implementing logical channel prioritization operations). Transmission rate-related requirements may be associated with HARQ entities, HARQ process types, and / or ongoing HARQ processes. The WTRU may observe and / or estimate the transmission rate for at least one subset of data (e.g., using similar measures described herein for timing-related aspects). WTRU can determine whether the transmission rate-related requirements of interest can be met, and can take different actions based on this determination (such as switching to a different transmission scheme).

[0207] For illustration, the WTRU may attempt to transmit uplink data units using a first transmission scheme. The WTRU may determine whether the first transmission scheme can be used to meet rate-related requirements, or more generally, QoS requirements associated with uplink transmission. If the WTRU determines that the first transmission scheme cannot meet the rate-related requirements, then the WTRU may decide to switch to a second transmission scheme to meet the rate-related requirements of interest. As described in more detail here, the second transmission scheme may differ from the first transmission scheme in at least one operational respect.

[0208] The example communication system described herein may include one or more of the following configuration-related requirements (e.g., configuration-related characteristics). For example, a WTRU may be configured to give certain data a transmission priority (e.g., absolute priority) that overrides one or more other QoS requirements. In one example, the WTRU may be configured by an upper layer to transmit packets with the highest priority, regardless of other QoS requirements such as timing, rate, or efficiency.

[0209] The exemplary communication systems described herein may allow and / or enable other WTRU behaviors, examples of which include random access for TRP, changing and / or monitoring control channels, permission and / or transmission parameter selection, and / or SR method selection, etc.

[0210] As described herein, a WTRU can be configured to not meet one or more QoS requirements associated with a transmission (e.g., an uplink transmission). As an example, such QoS requirements may be timing- and / or rate-related (e.g., the QoS requirements described herein). As an example, if QoS requirements cannot be met, it may lead to changes in the applicable procedures, changes in the transmission scheme, and / or changes to other transmission-related behaviors. For example, the WTRU may attempt an uplink transmission using a first transmission scheme. The WTRU can determine whether using the first transmission scheme can meet QoS requirements, such as timing-related requirements or transmission rate-related requirements described herein (e.g., for at least a subset of the data available for transmission). If the WTRU determines that using the first transmission scheme cannot meet the QoS requirements, the WTRU can meet the QoS requirements by adjusting its operation. For example, the WTRU can autonomously adjust the transmission scheme used for transmission. Such adjustments may include increasing, changing, or decreasing resources used for transmission, and these adjustments may result in changes to one or more operational aspects of the transmission scheme (e.g., changes to one or more transmission parameters).

[0211] When the transmission scheme is changed, the connection between the WTRU and the network may be affected / altered. Therefore, the connection type can be an example of an operational aspect that changes between different transmission schemes. For example, once the connection type changes, the WTRU may initiate an access procedure and / or request a reconfiguration procedure with the network (e.g., L3 reconfiguration). In one example, the WTRU may initiate an RRC procedure requesting reconfiguration of its connection. This request may include one or more of the following: The request may include the identity of the applicable logical data grouping (e.g., LCH, LCG, and / or SOM, etc.). The request may include information related to the QoS aspects that triggered the connection change (e.g., resource adjustments for improvement, rate, or timing, etc.). The request may include information related to the data to be transmitted (e.g., queue head delay or average delay, amount of unprocessed data, etc.). The WTRU may include a metric in this request.

[0212] The WTRU can initiate TRP access and / or random access. For example, the WTRU may initiate system access for purposes such as increasing the amount of available resources, changing resource types, and / or modifying the number of associated TRPs. The WTRU can determine (e.g., in a metric of a reference signal such as a signature) that one or more TRPs may be within its range. The WTRU can determine appropriate random access resources (e.g., by using information contained in an access table). The WTRU can initiate preamble transmissions on such resources. The above operations may result in different sets of resources available to the WTRU (e.g., the resources may increase or decrease, and / or there may be different sets of control channels to monitor). For example, the WTRU may initiate a process to increase the set of available resources, which may result in the aggregation of more physical layer resources, more carriers, additional TRPs and / or Uu interfaces of network entities (as an example, the network entity may include an eNB and / or a TRP, which may be implemented using dual connectivity or similar techniques, etc.).

[0213] When changing transmission schemes, the WTRU can expand or modify the identity and / or number of control channels it is monitoring. Thus, the set of one or more control channels monitored by the WTRU can be one example of operational aspects that can be varied for different transmission modes. For example, the WTRU can determine that different and / or additional control channels are available for scheduling transmissions. The WTRU can request and / or activate these control channels. The WTRU can perform this determination after a signal has been transmitted (e.g., to the network). This signal can indicate a request to activate such a control channel. In one example, the WTRU can perform the determination in a manner similar to performing system access (but for the same signature and / or cell). The WTRU can switch and / or add control channels. For example, the WTRU can switch to and / or add control channels associated with different SOMs (for example, these control channels may be associated with different physical layer resources, different physical data channels, and / or different parameter configurations).

[0214] When changing the transmission scheme, the WTRU can expand and / or modify the available resources. Thus, the set of available resources can be an example of operational aspects that can be changed for different transmission modes. The WTRU can determine that different sets of resources are available. The WTRU can switch to different sets regarding DCI and / or DCI types. For example, the WTRU can determine that it can attempt to decode different sets of DCIs on the control channel. These DCIs can be associated with different SOMs, different parameter configurations, and / or different PRB sets, etc. The WTRU can update its control channel surveillance activity (e.g., the update could be DRX). For example, the WTRU can change its surveillance frequency or intensity regarding the control channel (e.g., start decoding with higher intensity). When more resources are desired, the WTRU can enter an activity mode regarding the control channel. The WTRU can select the scheme for scheduling requests based on QoS requirements (e.g., according to QoS requirements). For example, the WTRU can select a specific scheme for acquiring transmission resources based on the QoS requirements associated with the data to be transmitted (e.g., according to QoS requirements). If the WTRU determines that the QoS requirements applicable to the data can be met, then the WTRU can use a contention-based transmission scheme. If the WTRU determines that it cannot meet the QoS requirements applicable to the data, then the WTRU can use dedicated SR resources for transmission. If the WTRU determines that multiple resources and / or request scheduling schemes are available, then the WTRU can select the scheme and / or resources associated with the SOM if they can achieve transmission that meets the applicable transmission requirements.

[0215] When changing the transmission scheme, the WTRU can modify and / or select specific transmission parameters or licenses. Thus, transmission parameters and / or licenses can be an example of operational aspects that can be changed for different transmission modes. For instance, the WTRU can determine different sets of transmission parameters available and / or that can be used for data transmission. The WTRU can select one license from multiple licenses so that one or more characteristics of data transmission can be modified. Such characteristics can include reliability, HARQ operating point, diversity applied to the transmission, transmission power, etc.

[0216] When changing the transmission scheme, the WTRU can modify the multiplexing, assembly, and / or segmentation techniques and / or rules associated with data transmission. Thus, multiplexing, assembly, and segmentation can be an example of operational aspects that can be modified for different transmission modes. For instance, when creating a MAC PDU for transmitting data, the WTRU can change its multiplexing rules, assembly and / or segmentation rules, and so on. As an example, when processing data whose QoS requirements cannot be met, the WTRU can skip the MAC layer's segmentation of packets.

[0217] The WTRU can be configured to maintain and / or act on latency-related characteristics or criteria (e.g., time-related QoS requirements) associated with a first subset of data rather than a second subset of data. The first subset of data may be associated with a first logical channel, a first flow, a first service, and / or a first data type, etc. The second subset of data may be associated with a second logical channel, a second flow, a second service, and / or a second data type, etc. In one example, a rate-related criterion may be associated with a specific set of one or more logical channels rather than with other logical channels. In one example, QoS requirements may be provided along with packets from a higher layer that are on any logical channel or flow. QoS requirements may be provided on demand.

[0218] When changing transmission schemes, the WTRU can provide the network with information associated with the uplink data that the WTRU is attempting to transmit. For example, the WTRU can transmit QoS-related information. The WTRU can transmit QoS-related information along with the associated data packets, SDUs, and / or byte sets (e.g., in a MAC PDU). For example, the WTRU can transmit the TTL along with the associated packet, SDU, and / or byte set. The TTL (or absolute time) can be expressed in a time unit (e.g., milliseconds). The TTL can occupy the least significant portion of the absolute time (e.g., to allow the receiver to determine what the absolute time will be).

[0219] QoS-related information can be appended to the relevant data. The receiving entity that sends the data along with QoS-related information can be a network node (e.g., a base station) or a receiving WTRU. As an example, this receiving entity may be involved in data operations such as relaying and / or forwarding; for instance, the entity could be an eNB configured to enable V2V communication (e.g., by forwarding UL transmissions directly to the destination). The receiving entity can use the QoS-related information to determine how to process the received data. The receiving entity (e.g., a base station) can determine and / or modify the best or preferred path, resources, TTI, and / or SOM, etc., associated with delivering the data to the final destination. The receiving entity can modify and / or prioritize its processing of the received data according to QoS requirements. For example, the receiving entity can modify and / or prioritize the implementation of resource reception priorities (e.g., in the case of RF or baseband limitations). The receiving entity can modify the resources, RAT, and / or mechanisms used for relaying the received data (e.g., SC-PTM compared to unicast compared to eMBMS). The receiving entity can select a path for one or more relevant cells or one or more networks to forward the data. For example, the receiving entity can determine whether to send the data to an application server in the network or to a proxy application service located in the cell or TRP.

[0220] Time-related requirements (e.g., latency-related requirements) can have various representations in a WTRU. A WTRU can use time-based requirements as a criterion for determining when it should switch from a first transmission scheme to a second. For example, a WTRU can maintain latency requirements. A WTRU can acquire transmission latency requirements, for example, from an upper layer. As an example, a WTRU can use such requirements to make scheduling decisions and / or resource usage decisions, guide aspects related to resource requests, and perform multiplexing / demultiplexing and / or control transmissions. For instance, a WTRU can maintain and / or monitor a TTL parameter representing the time elapsed from receiving a data packet to successfully transmitting the data packet. A WTRU can use the TTL parameter to regulate behavior, and / or processes, etc., in a manner that satisfies time-related QoS requirements during transmission phases (e.g., at each transmission phase). A WTRU can maintain the TTL for packets, SDUs, and / or sets of bytes, etc. The TTL can be associated with the amount of time allocated for successfully completing a transmission on the air interface.

[0221] When the TTL reaches a certain value or exceeds a certain range, the WTRU can change its behavior by performing specific operations (e.g., within its transport stack). For example, when the TTL associated with the MAC PDU reaches a certain threshold, the WTRUMAC can use one or more techniques described herein to decide to initiate a deliberate transport (e.g., using contention-based resources).

[0222] For example, when the TTL associated with a MAC PDU has reached a certain threshold, the MAC can decide to use a successive HARQ type, a successive TTI, a successive transport channel, and / or a successive coding rate. Thus, TTI length, transport channel identification, coding rate, etc., can be an example of operational aspects that can be changed when the WTRU alters the transport scheme. When the TTL has reached a certain threshold, the WTRU can decide to trigger a specific request for resources from the network (e.g., on a certain SOM), or use a different mechanism to issue such a request.

[0223] It should be noted that the concept of TTL used here is not limited to any specific definition. For example, the concept of TTL can include any mechanism used to define and represent one or more QoS requirements. Thus, some examples may be described in contrast to the process of using TTL to determine when to switch transmission schemes and / or change transmission parameters, but other information used to indicate one or more QoS requirements can also be used as criteria to determine when to switch transmission schemes and / or change transmission parameters.

[0224] The exemplary communication system described herein can be characterized by features involving at least requesting, determining, and accessing appropriate transmission resources. For example, these features can be associated with processes for scheduling and / or determining one or more applicable control channels (e.g., SOM-dedicated control channels).

[0225] The exemplary communication system described herein is characterized by having a unique mechanism for requesting network access (e.g., access to applicable resources) to meet specific QoS requirements (e.g., time-related QoS requirements). In one exemplary embodiment, the WTRU may send a Resource Request (RR) to the network. The RR may include a request for new or modified resources and / or may indicate buffer status. The RR may include a request to change the connection with the network. The RR may include a request to change resources. The RR may include a request to change the control channel to be monitored or configured. The RR may include a request to change the TRP. The RR may include a request to change the SOM. The RR may include a request to change other aspects described herein.

[0226] RRs can indicate QoS-related parameters and / or provide indications or potential indications of unmet QoS requirements. To meet QoS-related requirements, different resource request mechanisms and / or formats can be defined for different services, logical channels, logical channel groups, and / or QoS groups. The type of RR can be determined based on one or more QoS parameters reaching a certain threshold. RRs can be sent based on one or more QoS parameters reaching a certain threshold (e.g., TTL reaching a threshold).

[0227] An RR can be characterized by the type of transport format used, the type of resources used to transmit the RR, the information provided within the RR, the length of the TTI used for the RR transmission, and / or SOM, etc. A WTRU can determine which RR to use based on one or more QoS characteristics.

[0228] As an example, the information transmitted in an RR may include requests for resources, requests to modify assigned resources, indications of buffer status, and / or indications of a QoS requirement that cannot be met or may not be met. An RR may include indications of the intention to perform a transfer in upcoming resources and / or resources that the RR is scheduled to use. An RR may include indications indicating that resources are being requested to meet certain QoS requirements associated with the data that triggered the RR. In some examples, such indications may be the only information provided in the RR. In other examples, additional information may also be provided in the RR, such as information related to the transfer and / or the WTRU performing the transfer.

[0229] The WTRU can identify one or more of the specific service, SOM, and / or LCG to which the RR is applied within the RR. In one example, the indication contained in the RR can signal a request for additional resources to be allocated for the SOM / transmission channel transmitting the RR (for example, assuming different physical resources are used for different SOMs / transmission channels). The WTRU can transmit multiple RRs within a single SOM (for example, each RR corresponds to resources associated with each SOM). RRs (e.g., each of multiple RRs) can signal a request for resources associated with different SOMs. The association between an RR and the SOM corresponding to the transmitted RR can be based on a tag (for example, the tag may be contained in the RR), based on the resources used (e.g., time or frequency, or bit positions in both), based on other physical characteristics of the RR transmission (e.g., transmit power / energy, modulation scheme, etc.), based on the RR format, based on the RR size, and / or based on the RR timing (e.g., the time the WTRU transmits the RR), etc.

[0230] An RR can indicate a request for additional transmission resources and / or whether currently allocated resources are sufficient (e.g., for data on a particular service or logical channel, or for a particular SOM). An RR can dynamically request additional resources (e.g., relative to prior transmissions). For example, a WTRU can obtain access to additional resources that are available shortly or immediately after a previous transmission by sending an RR. An RR can request resources in relation to the amount of resources currently allocated in the WTRU. For example, a WTRU can request and / or be configured to have a specific amount of resources per time unit for use by that WTRU for a limited period of time (e.g., the resources may be guaranteed or reserved). After such resources are configured, the WTRU can reduce or increase the amount of resources already provided to that WTRU by sending an RR (e.g., a new request) or indicating otherwise.

[0231] The indication in the RR can have a certain value. For example, the indication can take one of two possible values ​​(e.g., a 1-bit value). If, for at least one PDU, the expected time to successfully complete its transmission exceeds the current time plus the PDU's TTL, then the indication can take the first value. Otherwise, the indication will take the second value. In another example, the indication in the RR can take one of four possible values ​​(e.g., a 2-bit value). The WTRU can determine the difference between the expected successful completion time and the sum of the current time and the PDU's TTL for each PDU. The WTRU can set the indicated value based on this highest difference across all PDUs to be transmitted. If the difference exceeds a first threshold, then the indication can be set to the first value; if the difference exceeds a second threshold (but does not exceed the first threshold), then the indication can be set to the second value; if the difference exceeds a third threshold (but does not exceed the second threshold), then the indication can be set to the third value; otherwise, it can be set to the fourth value. The thresholds can be predefined or announced by higher layers via signaling. Increasing the number of possible values ​​for this indicator would allow for faster or more accurate adjustment of allocated resources.

[0232] In some options, or for certain RR types, the RR may include information derived from the QoS-related scheduling information described herein. For example, a WTRU may transmit latency-related or any QoS-related information to the receiving node. This information may be transmitted in an RR, MAC PDU, or RRC signaling message. As an example, the network may use this information to schedule resources and / or perform prioritization among different WTRUs that require resources. The information included in the RR (e.g., contained by the WTRU) may have or depend on one or more subsequent forms.

[0233] The WTRU can contain information associated with the TTL within the RR. For example, the WTRU can contain the minimum TTL or TTL for packets, PDUs, etc., currently queued on the WTRU for transmission. The WTRU can maintain multiple delay-sensitive transmission queues. The WTRU can transmit the TTL for the head of each of these multiple transmission queues.

[0234] WTRU can include information associated with buffer sizes in RR. For example, WTRU can include: the buffer size for data configured to have TTL requirements, the buffer size for data that can be reused by one or more services that triggered the request, or the buffer size for all data in the WTRU (as an example, along with their associated priorities and / or requirements).

[0235] The WTRU can contain information associated with the timing range and / or the corresponding buffer size of a specific packet, PDU, etc. For example, the WTRU can transmit the minimum and maximum acceptable latency range for a PDU or data set.

[0236] The WTRU may include information associated with the absolute time of over-the-air transmission / reception of packets or data volumes, or with an absolute time range for acceptable delays, in the RR. The WTRU may include information associated with QoS classification or absolute data priority, rate-related information, and / or the expected time for successful completion of the transmission of at least one PDU (e.g., given currently allocated resources). This expected time may instead depend on one or more of the following: The expected time may depend on the expected time for the PDU to be first included in a transport block submitted to the physical layer for transmission according to a defined set of priority rules. The expected time may depend on the expected time for retransmissions. One or more parameters described herein may be set to predefined values ​​or may be signaled by higher layers.

[0237] The WTRU may include in the RR information associated with a specific TTI available for the WTRU to use on resources (e.g., 2 symbols or 0.5 milliseconds), the number of resource blocks per time unit (e.g., the number of resource blocks in a fixed period of x frames), and / or the frequency range in which such resources can be located (e.g., in a specific narrowband bandwidth that the WTRU supports or that the WTRU prefers due to the radio characteristics of the WTRU).

[0238] The WTRU can indicate (e.g., implicitly indicate) specific RR-related information through the selection of resources, timing, encoding, and / or power, etc., associated with the transmission on PHY resources. For example, the WTRU can indicate the amount of additional resources allocated to it based on its time / frequency resources used to transmit the RR. RR-related information can be indicated by the format and / or transmission mechanism used in the RR transmission. As an example, the RR can be transmitted in the PHY layer (e.g., on a specific PHY control channel or piggybacked with data) and / or the MAC layer (e.g., using MAC CE, etc.). The RR can be transmitted entirely in the PHY layer. When transmitted in the PHY layer, the RR can be transmitted using one or more of the following methods.

[0239] RR can be transmitted using a single OFDM symbol or by using a single symbol within a resource block associated with the WTRU uplink transmission (e.g., at a predefined or configured location). In one example, the RR can be transmitted in the last one or more symbols of the OFDM subcarrier with the largest index (e.g., one or more symbols that are the last in time). The RR can be transmitted using the uplink control channel or as part of WTRU autonomous scheduling information that can be transmitted in the uplink control channel.

[0240] The RR can be transmitted using dedicated PHY resources, the location of which can be provided to the WTRU in the network via signaling (e.g., RRC signaling) or obtained through information included in the access table sent to the WTRU. The RR can be transmitted using information related to identification or timing (e.g., in combination with the above information) (e.g., for deriving the location of the PHY resource).

[0241] RR can be transmitted using contention-based resources, such as RACH or similar signaling. These contention-based resources can be extended to PHY resources used by other WTRUs in a manner that minimizes overall interference to the WTRU (e.g., using CDMA or punch-through processing, thereby using a small / minimal amount of interference resource elements associated with a particular WTRU). In an exemplary scenario concerning LTE-assisted 5Gflex tight interaction, the WTRU can be configured to transmit RR via LTE PUCCH. The PUCCH RR can be extended to carry information related to the request and having QoS characteristics that can be satisfied by the 5G system. More specifically, the SR can indicate that the WTRU is requesting 5G resources. As an example, this processing can be enabled by changing the SR format to include additional bits, reserving special resources for sending the 5G request that triggers the SR, and / or similar methods.

[0242] The WTRU can access multiple resource sets or mechanisms for transmitting RRs. As an example, for different services, the RR can be defined with different characteristics, including different formats or types, different transmission time values ​​(e.g., the time from triggering the request to transmitting the request over the air), different symbols, different signaling mechanisms, and / or different transmission formats, etc. The WTRU can select from these different mechanisms based on one or more of the following: The WTRU can select the mechanism for transmitting the RR based on the latency characteristics of the data in the queue or the data to be transmitted (e.g., the data may or may not be latency-sensitive). The WTRU can select the mechanism for transmitting the RR based on the TTL of one or more packets or the data to be transmitted (e.g., the TTL may or may not be threshold-related). The WTRU can select the mechanism for transmitting the RR based on the priority of the data or service type. The WTRU can select the mechanism for transmitting the RR based on one or more QoS requirements described herein (e.g., time-based or rate-based QoS requirements). As an example, WTRU can use different TTIs to send RRs in the PHY for a service (such as ULLRC or eMBB) based on the time criticality, priority, and / or timing requirements of the data in one or more buffers that sent / triggered the RR.

[0243] RRs used for a SOM (e.g., for each SOM), a specified service, or a logical channel can have different characteristics related to how the RR is transmitted in the PHY layer. In one example, RRs can be transmitted by employing different coding schemes, on different transport channels, using different TTIs and diversity / reliability, using dedicated (e.g., compared to shared / contention-based) resources, and / or using other mechanisms / techniques. WTRUs can use different RR mechanisms depending on the SOM or service involved. For example, a WTRU configured to have a ULL service can use a 1-bit PHY layer RR mechanism to request resources for the ULL service, while the WTRU can use a MAC layer RR if the buffer state corresponding to the RR on the PHY layer indicates a request for an IBB type service.

[0244] A WTRU can trigger RR based on one or more of the following: The WTRU can trigger RR based on QoS requirements described herein (e.g., QoS-related events). For example, the WTRU can trigger RR based on latency-related events. As an example, such latency-related events could include the arrival of time-sensitive packets at the MAC layer or higher. The WTRU can trigger RR based on one or more packets or data whose TTL falls below a threshold. The WTRU can trigger RR based on initiating, configuring, or reconfiguring services, TRPs, logical channels, and / or SOMs, etc., on the WTRU. The WTRU can trigger RR based on the arrival of packets with different QoS classifications than ongoing transmissions. The WTRU can trigger RR based on data not meeting rate-related QoS requirements, etc.

[0245] A WTRU can trigger a retransmission (RR) based on one or more of the following: A WTRU can trigger an RR based on an indication from the application layer. A WTRU can trigger an RR based on the periodic expiration of a timer. A WTRU can trigger an RR based on an indication that the buffer is no longer empty (or other buffer occupancy information). A WTRU can trigger an RR based on one or more HARQ entities that indicate retransmission upon returning from sleep, DRX, etc. A WTRU can trigger an RR based on the initiation, configuration, or reconfiguration of a service. A WTRU can trigger an RR based on the creation of a logical channel (e.g., a logical channel requiring low-latency communication). A WTRU can trigger an RR based on its connection to the network. For the last example of a triggering event, if the network is an LTE-assisted network and if the incoming new data has a requirement that LTE services cannot meet, then the WTRU can trigger a 5GFlex RR.

[0246] When data transmission is in progress or has already begun on resources serving another service or another logical channel, the WTRU can trigger a Rate of Response (RR) for that service or logical channel. In this scenario, for example, the WTRU can perform one or more of the following actions based on a determination of priority, resource availability, and / or the amount of data to be transmitted (e.g., in absolute terms or based on the current QoS characteristics of each service). The WTRU can append RR information to the ongoing data transmission, or the WTRU can delay the RR transmission until the ongoing data transmission is complete. However, for time-sensitive transmissions, if the WTRU delays the transmission of the RR, or if the network decodes the appended information at the end of the Time Interval (TTI), then no RR delay will be performed. The WTRU can send the RR to the network immediately. The WTRU can avoid transmitting the RR and can handle new services that have triggered RRs by prioritizing resources using existing resources.

[0247] For illustrative purposes, the WTRU may have an ongoing web browsing session and resources available for transmission. If the WTRU receives data with less stringent QoS requirements (e.g., time-related QoS requirements), it can transmit the resource request information along with the data (e.g., using a MAC PDU or embedding the RR at the PHY layer). If the received data has stringent QoS requirements, or if latency requirements are not met, the WTRU can trigger an RR transmission using RR characteristics associated with the service (e.g., the RR characteristics used for RR transmission may implicitly indicate the service to which the RR applies; these characteristics may reflect parameter configuration, timing, resources, and / or transmission technology, etc.). In this case, the WTRU can transmit the RR in parallel with the ongoing data transmission (e.g., on different resources), or the WTRU can transmit the RR by delaying the data transmission. For example, if data transmission is in progress and triggers an RR, the WTRU can transmit the data in the first available resource (e.g., immediately). If the next available resource appears later than the time when the corresponding RR is transmitted on the air interface, the WTRU can transmit the RR during the ongoing transmission. This section describes a mechanism for transmitting RRs while performing transmissions with long TTIs and / or when dedicated RR resources are limited or unavailable.

[0248] In the exemplary communication system described herein, the WTRU can obtain access to resources through a license derived from the network. Whether or not a licensed resource is used can be an example of an operational aspect that may change when switching transmission schemes. The WTRU may receive one or more of the following in the license: The WTRU may receive information (e.g., indications) about the resources available to the WTRU for access. As an example, the resource may be specified as a pre-configured resource index or explicitly announced in the license by signaling. The WTRU may receive information about the SOM or transport channel to which the license is valid. For example, this information may indicate the parameter configuration, TTI, and / or waveform available to the WTRU. The WTRU may receive information about the logical channel, service type, and / or priority, etc., available to the WTRU for specifying the license. This information may include identifiers or values ​​that are generally understood between the WTRU and the network. The WTRU may receive information about the transmission format of the license (e.g., MCS, block size, start time, etc.). The WTRU may receive information about the TTI length. The WTRU may receive information about the validity of the license. As an example, this information may indicate the TTI or TTI range that the WTRU is allowed to use for licenses, time periods, etc. The WTRU may receive information about logical channels, priorities, and / or service ranges that can be used with or excluded from licenses. This range may be greater than or less than a certain priority value (as an example, the priority value may be indicated by the network in the license).

[0249] The WTRU can perform priority ordering on logical channel transmissions. This priority ordering process for logical channel transmissions can be an example of an operational aspect that can be altered when the WTRU switches transmission schemes. As an example, the WTRU can use licenses to transmit logical channels (e.g., any logical channel) whose priority values ​​are less than or greater than the values ​​advertised in the license, or that fall within a range advertised in the license (e.g., from minimum to maximum). Within the permissible range of priority values, the WTRU can exclude certain priority levels.

[0250] The WTRU can be configured to prioritize the use of licensed resources. Prioritizing licensed resources across different services is one example of an operational aspect that can be changed when the WTRU switches transport schemes. For instance, the priority range for 5G services could include ten different priority levels associated with the scheduling and use of licensed resources, where level 10 is the highest priority that can be associated with the ULLC service type. The WTRU can be configured to assign resources to higher-priority services first (e.g., when these higher-priority services need to transmit data). For example, the WTRU could receive a license assigned to priority level 5. In this case, the WTRU can be configured to use that license (e.g., the resources associated with it) for transport blocks marked with priority level 5 or higher, or for transport blocks with the highest priority if the highest priority is less than 5. Once the instruction regarding the license is received from the PHY layer, the MAC layer can select packets with priority level 5 or higher, or the highest-priority packets if the highest priority is less than 5, in its transport buffer, and can send this packet to the PHY layer for transmission.

[0251] A WTRU can be configured to bind resource prioritization to a specific type of resource at the PHY layer. Binding resource prioritization to resource type is an example of an operational aspect that can be altered when the WTRU switches transport schemes. For instance, a WTRU can be configured to use a specific SOM only for logical channels with a specific priority. For illustrative purposes, a WTRU can receive a license assigned priority level 5. The WTRU can be configured to use that license (e.g., the resource associated with it) for transport blocks tagged with priority level 5 or lower. In this way, the WTRU can avoid using resources associated with licenses used for higher priority data (e.g., data with priority higher than 5), because these resources are not configured (e.g., in terms of reliability or timing) to accommodate higher priority data.

[0252] A WTRU can be configured to exclude a specific priority level from the range of priority levels from which licensed resources can be used. This process of excluding a specific priority level can be an example of an operational aspect that can be changed when the WTRU switches transmission schemes. The specific levels that can be excluded by the WTRU can be defined by a specification or announced to the WTRU by signaling. For example, since priority level 10 may be associated with the highest form of ultra-low latency communication, and this would require a specific type of resource that might need to be licensed separately (e.g., by indicating that specific priority level or by using a different mechanism), this priority level can be excluded.

[0253] A WTRU can be configured to autonomously access resources (e.g., pre-configured resources). Autonomous resource access can be an example of an operational aspect that can be altered when the WTRU switches transmission schemes. The WTRU can be pre-configured with a set of transmissions that it can autonomously execute. This capability is ideal, for example, in IoT applications, industrial applications, and / or automotive communications. In one or more of these scenarios, the WTRU can transition from having little or no uplink transmission over long periods to regular (e.g., periodic) transmission with very low latency. To initiate regular low-latency transmission, the WTRU can be configured to have a pre-configured set of resources. The WTRU can use one or more of these pre-configured resources to transmit data with a specific QoS requirement. For example, the WTRU can be configured to have resources for UL, DL, sidelinks, etc. This configuration does not necessarily reserve resources for the WTRU, but it can instruct the WTRU which resources it can use when needed.

[0254] Pre-configured resources may include static configurations of one or more overlapping or non-overlapping time-frequency resources. These resources may last for a limited period of time and / or occur periodically. For example, a pre-configured resource may include a single resource block located at a specific frame or subframe number. When registering and / or connecting to the network, the WTRU receives pre-configured resources or requests modification of pre-configured resources by means of dedicated signaling from the network (e.g., similar to RRC signaling), by means of an access table (e.g., associated with a system signature), by using an identity corresponding to the WTRU or service, and / or by establishing services, radio bearers, and / or logical channels that may require pre-configured resources, etc.

[0255] For example, a WTRU can obtain access to pre-configured resources via a short uplink transmission or via RR or scheduling information (SI) transmission. Such an uplink transmission may include one or more of the following: The transmission may include a request to be transmitted. The transmission may include an index or identifier for identifying the desired pre-configured resource in the set of pre-configured resources. The transmission may include information about the duration of use of the pre-configured resource (e.g., whether the WTRU wishes to use the resource once or periodically, the duration the WTRU wishes to use the resource, etc.). The transmission may include conditions that may be used to define whether and / or when the pre-configured resource is no longer valid. The transmission may include a request for an identifier / index and other information associated with the timing duration of the pre-configured resource. The transmission may include a period of time during which the WTRU can use the pre-configured resource. The transmission may include other information that can be carried in the RR or SI. The WTRU may be identified in this transmission, for example, by a WTRU-specific RR or SI resource, or by an explicit identifier as described herein.

[0256] Once a transmission request (such as the RR described herein) is received, the WTRU can begin monitoring one or more control channels associated with the service or QoS classification that triggered the request. For example, if the requested transmission is for low-latency data, the WTRU can begin monitoring one or more control channels associated with a low-latency service or the corresponding SOM. The WTRU can receive acknowledgments promptly (e.g., in a manner similar to that described herein). As described herein, the WTRU can receive a response from the network after sending a short uplink transmission. The WTRU can receive one or both of the following from the response: information related to indexing and / or timing that may be present in the short uplink transmission, or a response regarding resource usage. As an example, the WTRU can execute a short UL transmission to indicate a request for resources for a specific service or SOM. The network can respond using an index of pre-configured resources. Depending on the pre-configured conditions and / or the type of service requested, the pre-configured resources can be used for at least one transmission.

[0257] In the downlink (DL), pre-configured resources can be provided to the WTRU. For example, a provision can be made using the response mechanism described herein (which, as an example, could be included in a response from the network). The WTRU can disable pre-configured resources (e.g., in a similar manner to how pre-configured resources are enabled). For example, the WTRU can disable (e.g., implicitly) pre-configured resource transmissions by transmitting RRs when the amount of latency-sensitive data in the buffer falls below a threshold. The request and / or enable / disable processing of pre-configured resources is an example of an operational aspect that can be altered when the WTRU switches transmission schemes.

[0258] As an example, a WTRU can perform autonomous uplink transmissions by using potential resources that may not necessarily be allocated to that WTRU. For such transmissions, the WTRU will be able to use pre-configured resources and / or notify the network that such resources are being used by the WTRU. Alternatively or supplementarily, the WTRU can perform uplink transmissions on low-latency uplink control channels or by means of low-latency data transmissions (e.g., with short TTIs) assigned to or dedicated to one or more WTRUs. Autonomous uplink transmissions are an example of operational aspects that can be altered when a WTRU switches transmission schemes.

[0259] The WTRU can perform a UL transmission to enable a pre-configured resource using a MAC CE or other similar control message on the resource scheduled for uplink transmission. The WTRU can perform the aforementioned process instead of sending the UL transmission autonomously. Using the scheduled resource to enable a pre-configured resource is one example of an operational aspect that can be changed when the WTRU switches transmission schemes.

[0260] The WTRU can use any suitable techniques described herein to transmit requests for or instructions to use pre-configured resources. For example, the WTRU can transmit such requests or instructions in a manner similar to transmitting RRs. As an example, the WTRU can enable pre-configured resources using RRs (e.g., based on the content of the RR). As an example, the WTRU can explicitly enable pre-configured resources by sending an RR indicating a desired resource configuration. And as an example, the WTRU can implicitly enable pre-configured resources by including QoS-related parameters in an RR that can be interpreted as an automatic request for a specific type of resource configuration. Once an RR containing specific triggering conditions is transmitted, the WTRU can implicitly enable processing for using the pre-configured resources. These conditions can be part of the initial pre-configuration of the pre-configured resources themselves. As an example, the WTRU can be configured to use pre-configured resources when transmitting an RR indicating a latency-sensitive data amount exceeding a certain threshold.

[0261] The WTRU can be configured to perform the uplink transmissions described herein using one or more of the following mechanisms: The WTRU can be configured to perform uplink transmissions using short PHY layer signals reserved for one or more WTRUs to send signals to the network. The WTRU can be configured to perform uplink transmissions using CDMA-like or punched signals transmitted on a channel shared among multiple WTRUs. The WTRU can be configured to perform uplink transmissions using RACH-like uplink transmissions performed on well-defined specific time instances. The WTRU can be configured to perform uplink transmissions by means of an initial transmission on a resource associated with a pre-configured resource. Downlink network transmissions (examples of which may include ACKs or indications) can be performed using low-latency control channels, data channels with short TTIs, or other suitable DL channels.

[0262] A WTRU can be allocated resources to transmit data for one or more services. The WTRU can dynamically schedule data transmission (e.g., by means of self-scheduling) using all or a subset of the allocated resources. The allocated resources can be limited to one or more specific windows in the time domain (for example, such time windows can have a duration of several milliseconds). In some embodiments, the one or more time windows can recur periodically (e.g., substantially periodically). The allocated resources can be limited to a range in the frequency domain. This frequency range can be time-dependent (e.g., for providing frequency diversity). The allocated resources can be used on at least one uplink physical channel (UPCH), on which the WTRU can transmit data and control information. The allocated resources can be used on one or more sidelink physical channels (SPCH). Resources can be allocated based on service type (e.g., for each type of service), thereby reserving some resources for certain types of services.

[0263] The WTRU can be allocated resources to transmit scheduling information (SI), other uplink control information (UCI), and / or sidelink control information (SCI). As an example, this information may include HARQ-ACK and / or CSI feedback. It should be noted that the discussion of SI herein also applies to resource requests (RR) (for example, RR can be considered a type of SI and can be used interchangeably with SI; for example, examples described according to SI also apply to RR, and vice versa). Similarly, the discussion of RR herein also applies to SI. For example, although resource allocation for transmitting SI has been discussed above, those skilled in the art will understand that this mechanism can also be applied to transmitting RR. The resources allocated for transmitting SI and / or other UCI / SCI may be part of a resource block allocated for self-scheduling operations, or may be allocated separately. In some embodiments, these resources can be used to transmit data. The transmission of SI and / or other UCI / SCI may take place on a specific physical control channel (e.g., an uplink or sidelink physical control channel). The SI and / or other UCI / SCI may be encoded and multiplexed (e.g., in-band) in the uplink or sidelink physical channel (e.g., along with data).

[0264] Resource allocation for transmitting SIs and / or other UCI / SCIs can be configured to occur at regular intervals, such as on each of the shortest applicable TTIs, thus resulting in frequent transmission opportunities. Resources allocated for transmitting a single instance of a SI can occupy the entire range of the frequency domain. This reduces (e.g., minimizes) the number of time symbols configured to transmit an instance of a SI. SIs can be co-coded with other UCI / SCIs. The SIs and / or other UCI / SCIs can be individually encoded and multiplexed (e.g., concatenated) before modulation, layer mapping, and / or resource element mapping. The coding rate, coding scheme, and / or modulation can be determined using one or more techniques described herein.

[0265] The WTRU can transmit information related to parameters associated with SI and / or UCI / SCI transmissions. This information helps receiving nodes, such as network nodes or other WTRUs, decode the SI and / or UCI / SCI. For example, the WTRU can specify the number of information bits, modulation and coding scheme, and / or resource information associated with the SI and / or UCI / SCI (e.g., the number of time symbols). This information can be encoded separately from the SI and / or UCI / SCI, and / or can be mapped to known portions of allocated resources. The WTRU can contain indications about whether the next time symbol contains the SI and / or UCI / SCI (e.g., for each time symbol containing the SI and / or UCI / SCI).

[0266] A WTRU can transmit data in one or more TTIs. A WTRU can transmit data for one or more services, one or more logical or transport channels, and / or one or more receivers (e.g., network nodes or other WTRUs). The WTRU can include information associated with the data in an SI (e.g., an instance of an SI) to assist one or more receivers in decoding the data. Instances of the SI can be transmitted in one or more TTIs prior to data transmission. The transmission of the SI can follow a fixed timing relationship.

[0267] The WTRU can indicate in the SI whether data transmission occurs during the TTI. For example, the SI can indicate one or more of the following information regarding the TTI or the applicable transmission type within the TTI: The SI can indicate whether data is transmitted during the TTI. The SI can indicate the type of data, service, or logical channel included in the transmission. The SI can contain timing indications for the TTI (e.g., the number of time units from the SI instance). The SI can indicate the duration of the TTI. The SI can indicate the WTRU identifier (e.g., RNTI). The SI can contain indications about the destination node (e.g., the network node (TRP) or other WTRUs). The SI can indicate Cyclic Redundancy Check (CRC), such as a CRC combined with or masked by other fields like the WTRU identifier. The SI can indicate the number of codewords. The SI can indicate power-related information (e.g., power headroom). The SI can indicate other control information, such as scheduling requests and / or buffer status reports, HARQ-ACK or CSI feedback, and / or transmit power control commands.

[0268] The WTRU may indicate in the SI a description relating to how codeword information is transmitted. This description may, in turn, include one or more of the following: The description may include the transmission channel type. The description may include the coding type, such as convolutional code or turbo code. The description may include the modulation and coding scheme (MCS). The description may include HARQ information, such as New Data Indication (NDI), process identifier, and / or retransmission sequence number. The description may include frequency / time allocation within allocated resources or within the TTI. The description may include spatial processing information, such as transmit diversity or spatial multiplexing scheme and / or the number of transmission layers. The description may include antenna port and / or reference signal information.

[0269] As an example, the WTRU can use a single field to signal or indicate multiple parameters described herein in order to reduce overhead. For instance, the field could indicate a combination of MCS with coding type or transport channel type. The mapping between the combined value and the value of the corresponding parameter can be predefined or configured by a higher layer. The WTRU can use one or more of the following techniques to schedule transmissions and / or set parameters related to said transmissions.

[0270] A WTRU can be configured to multiplex transmissions in the frequency or spatial domain. For example, as described here, the WTRU can prioritize data transmissions based on other parameters such as type of service and / or TTL. The WTRU can apply priorities in such a way that the start time of higher-priority data is earlier than the start time of lower-priority data. The WTRU can transmit data with different priorities within the same time interval (e.g., where all higher-priority data can be transmitted within that time interval). In this case, higher-priority data can be transmitted using a portion of the available resources in the power, frequency, and / or spatial domains.

[0271] In the frequency domain, available resources can be partitioned. The WTRU can allocate as many frequency resources as possible to higher-priority data as needed, and can use the remaining resources to transmit lower-priority data. The WTRU can determine frequency allocation for transmissions (e.g., for each transmission) according to predefined rules. For example, the WTRU can allocate the highest or lowest frequency first. This allocation can be based on frequency-selective channel quality feedback from the receiver and / or on transmission priority. The WTRU can first allocate frequency portions with higher channel quality to higher-priority transmissions. For example, the WTRU might receive an indication from a network node that a first portion of the frequency range allocated to self-scheduled operations has a higher quality than a second portion. In this case, the WTRU can use at least a first portion of the frequency range to perform higher-priority transmissions.

[0272] If spatial multiplexing is available, the WTRU can allocate as many transport layers as possible to higher-priority data as needed, and can use the remaining spatial layers to transmit lower-priority data. For example, the WTRU can determine the layer selection for a transmission (e.g., for each transmission) based on predefined rules or on layer-specific channel quality feedback from the receiver.

[0273] The WTRU can select transmit power, MCS, and / or spatial transmission scheme according to one or more adaptation principles. For example, the WTRU can configure and reconfigure (e.g., adjust) the transmit power. As an example, this transmit power can be expressed as a ratio of the maximum transmit power. The WTRU can configure and reconfigure (e.g., adjust) the transmit power based on physical layer signaling, higher layer signaling, or a combination thereof. To assist in the configuration and reconfiguration (e.g., adjustment), the WTRU can transmit reference signals at the configured power level or using the power level advertised by the network signaling. The WTRU can use the same transmit power for one or more resource blocks (e.g., for each resource block). The transmit power can be configured based on resource blocks so that the total transmit power can depend on the number of resource blocks performing the transmission.

[0274] The WTRU can receive indications regarding the MCS and / or coding type used with a specific type of data. For example, the WTRU can receive indications relating to a first coding type (e.g., convolutional coding), a first modulation and coding scheme (e.g., QPSK and rate 1 / 3), and / or a first spatial transmission scheme (e.g., transport diversity such as SFBC) for a first type of service (e.g., URLLC). The WTRU can receive indications relating to a second coding type (e.g., turbo coding), a second modulation and coding scheme (e.g., 16-QAM and rate 1 / 2), and / or a second spatial transmission scheme (e.g., level 2 spatial multiplexing) for a second type of service (e.g., eMBB).

[0275] The WTRU can select the MCS and / or coding type based on channel quality feedback from the receiver and / or based on the type of data to be transmitted. As an example, for a specified value in the channel quality feedback from the receiver, if the data to be transmitted corresponds to a first service type (e.g., URLLC), then the WTRU can select a first coding type, a first modulation and coding scheme, and / or a first spatial transmission scheme. If the data to be transmitted corresponds to a second service type (e.g., eMBB), then the WTRU can select a second coding type, a second modulation and coding scheme, and / or a second spatial transmission scheme. The mapping between the channel quality feedback value and the MCS and / or coding type for a specific service type can be configured by higher layers.

[0276] The WTRU can receive indications about channel quality, MCS, and / or code type using physical layer signaling. For example, these indications can be signaled in downlink control information along with other parameters used to allocate resources for self-scheduled operations. These indications can be signaled periodically (e.g., at intervals of approximately several TTIs).

[0277] The WTRU can adjust its choices regarding MCS, transport scheme, and / or transmit power based on dynamic indications applicable to the TTI. The WTRU can receive such indications from the network via physical layer signaling. For example, if the indication is set to a first value, the WTRU can choose a more conservative MCS level and / or transport scheme, and if the indication is set to a second value, the WTRU can apply a less conservative MCS and / or transport scheme. Using this indication, the network can adjust transport robustness, for example, based on whether other WTRUs expect to use the same resources in that TTI (e.g., in the case of multi-user MIMO). Using this indication, the network can improve transport robustness after a certain number of HARQ retransmissions. The WTRU can map various indications to MCS / transport scheme combinations. MCS and transport scheme combinations can be ordered from least conservative to most conservative. For example, the WTRU can maintain this order in a table, and an indication can be mapped to an offset linked to one or more entries in that table. These offsets can be configured by higher layers and / or depend on the service type or transport channel.

[0278] The WTRU can adjust its choices regarding MCS, coding type, and / or transmit power based on the number of retransmissions performed, the delay since the initial data transmission, and / or the data's TTL. For example, when the TTL of the transmitted data is below a threshold, the WTRU can apply a more conservative MCS level and / or transmission scheme. This adjustment may include offsets applied in tables regarding MCS and / or transmission schemes. Such adjustments result in a larger portion of the allocated resources being allocated to the transmission, while improving the robustness of the transmission and the likelihood of successful completion. When the data's TTL is below a threshold, the WTRU can increase this offset in transmit power.

[0279] A WTRU can be configured to perform transmissions to more than one receiver (e.g., using more than one MAC instance and / or simultaneously). In one example, a first MAC instance may correspond to a transmission to a first network node, and a second MAC instance may correspond to a transmission to a second network node. In another example, a first MAC instance may correspond to a transmission to a network node, and a second MAC instance may correspond to a transmission to another WTRU. The MCS and / or coding type applicable to the transmission (e.g., each transmission) may depend on channel quality feedback and / or other indications provided by the receiver.

[0280] Resources can be configured for self-scheduling operations. For one or more service types (e.g., for each service type), these resources may include one or more of the following: Resources for self-scheduling may include resources for transmitting data and / or control information (e.g., SI and / or SCI / UCI). Resources for self-scheduling may include resources for receiving control information (e.g., downlink or sidelink control information, such as channel quality feedback, HARQ feedback, and / or other indications). Resources for self-scheduling may include parameters for link adaptation (e.g., transmit power, power adjustment offset, MCS, and / or transmission scheme). Resources for self-scheduling can be configured by higher layers or by a combination of physical layer signaling and higher layer signaling. For example, the WTRU may receive fields that can be mapped to a set of parameters associated with the configuration of resources for self-scheduling via downlink control signaling derived from the physical control channel. This mapping can be configured by higher layers.

[0281] A WTRU can access resources dedicated to a specific service type (e.g., URLLC). Such resources can be shared by multiple WTRUs. These multiple WTRUs can transmit URLLC data (e.g., at least occasionally). The dedicated resources can include specific time / frequency resources, such as specific resource blocks or subcarriers. Resources can be used for specific frames or sets of subframes, or can be used over long periods of time. For example, a WTRU can determine resources dedicated to a specific service (e.g., for URLLC) based on network broadcast or dedicated signaling, or through an access table.

[0282] The WTRU is capable of autonomously performing transmissions on dedicated PHY resources. For example, a WTRU can be configured to perform such autonomous transmissions when dedicated PHY resources are reserved for that WTRU (e.g., only for that WTRU). The WTRU can receive ACKs from the network via a low-latency downlink control channel. As an example, the ACK can be sent via the control channel. The ACK can be sent in the same subframe as an indication, and / or via a shortened TTI. The ACK can include an indication of which resources are used. The ACK can be sent using dedicated symbols within a certain time-frequency space (e.g., a time-frequency space reserved for this particular purpose). As an example, a set of symbols can be reserved here for each WTRU (e.g., for receiving downlink ACKs). As an example, on subframes or TTIs where the WTRU does not expect a response from the indication, these symbols can be used for other purposes (e.g., these symbols can serve as reference symbols).

[0283] The WTRU can be configured to have resources on the PHY layer available for transmissions with shortened TTIs (e.g., specifically reserved for them). For example, specific time / frequency resources (e.g., x resource blocks per y subframes) can be reserved for the WTRU to perform TTI-shortened transmissions (e.g., 2 OFDM symbols). The WTRU can use one or more of the following exemplary techniques to determine the resources reserved for transmissions with shortened TTIs. These resources can be statically defined for the WTRU. These resources can be announced by the network via dedicated signaling or signaling using access tables. These resources can be defined / created (e.g., implicitly) based on the WTRU's device type, service type, and / or the type of traffic currently managed by the WTRU. The WTRU can be configured to autonomously select resources.

[0284] One transport type may take precedence over other transport types. Figure 5 An example of prioritizing transmissions is shown. This transmission prioritization can be applied in various use cases, including those involving URLLC transmissions, differential QoS eMBB transmissions, and / or non-multiplexed URLLC transmissions. As an example, transmission prioritization can be implemented based on one or more of the following: Transmission prioritization can be implemented using request differential. Transmission prioritization can be implemented using transport channel selection. Transmission prioritization can be implemented using the reassociation of transmission resources with high-priority HARQ and / or different transport channels. Prioritized transmissions can be indicated and / or configured with specific parameters. Prioritized transmissions may include PDUs configured to have a maximum allowed time for successful completion of the transmission (e.g., for URLLC or differential QoS eMBB transmissions). Prioritized transmissions may include PDUs associated with a specific logical channel (e.g., for non-multiplexed URLLC transmissions).

[0285] As described herein, this exemplary communication system can support low-latency communication. The WTRU can be configured to transmit low-latency packets immediately at the MAC / PHY layer or with processing delays (e.g., the shortest possible delay). The WTRU can be configured to delay transmissions that are already in progress, have been cancelled, and / or terminated in order to prioritize low-latency packets. In an exemplary scenario for prioritizing low-latency communication, the WTRU performing the scheduled uplink transmission can autonomously decide to delay the scheduled transmission and can use the resources allocated to the scheduled transmission to transmit or retransmit transmissions with low-latency requirements.

[0286] Examples of transmissions that can be delayed by the WTRU may include dynamically scheduled uplink transmissions, semi-permanent transmissions, or statically granted uplink transmissions, and / or scheduled retransmissions, etc. In one example, a WTRU with multiple ongoing HARQ processes may pause one of them to allow the transmission of low-latency data. In one example, the WTRU may pause a transport block or transmission to be retransmitted and may use the resources allocated for the retransmission to perform the initial transmission of the transport block or data with low-latency requirements. In one example, the WTRU may receive a grant associated with a transmission, logical channel, and / or service of a specific priority, and the WTRU may decide to use the resources allocated for the granted transmission to deliver low-latency packets. As an example, low-latency packets may arrive at the MAC layer after a request for non-low-latency resources and a corresponding grant have been made. In such a scenario, the WTRU may send an indication to the network regarding a non-low-latency transmission for which resources are currently reserved and the different service, priority, or logical channel for which the WTRU intends to use the resources. This indication may be transmitted using the formats and / or techniques described herein.

[0287] Once a decision is made to delay a transmission, such as a non-low-latency transmission, the WTRU can send an indication to the network that the transmission has been delayed to support another transmission (e.g., a low-latency transmission). This indication may indicate that a license or resource allocation is being overridden. The indication may indicate the HARQ ID or process associated with the delayed data. The indication may indicate the HARQ ID or process associated with new data. The indication may indicate the resources, locations, and / or processes available for retransmission of the delayed data. As described herein, this indication may be provided in UCI / SCI, SI, and / or RR. The indication may include the type of data being delayed or to be transmitted. For example, the WTRU may indicate that a transmission is a low-latency transmission and should be processed accordingly. The WTRU may indicate the transmission format (e.g., MCS, encoding, etc.) and / or PHY layer parameters (e.g., TTI parameters) used to transmit the data on the same resources. Upon receiving the indication, the network may suspend HARQ processing associated with the specific HARQ process that was interrupted. Once the low-latency transmission block has been successfully transmitted, the network may resume HARQ processing.

[0288] Once a new transmission (e.g., a low-latency transmission) is prioritized over the original transmission, the WTRU can use the same modulation and / or coding techniques for the new transmission as those used for the original transmission. Alternatively, the WTRU can select new TTI, modulation, and / or coding techniques for the new transmission to allow the WTRU to transmit the new transmission within the same resource or within the same portion of the resource.

[0289] The WTRU can use a subset of resources allocated to it to send the aforementioned indication to the network. For example, the WTRU can send the indication within a transport block, within a set of resource elements, or within a set of subcarriers. The resource subset can be predefined for this purpose. As an example, the WTRU can use the first N subcarriers of a first transport block to send the indication. Furthermore, the WTRU can transmit a predefined sequence to signal the presence of the indication to the network. This technique allows the network to first decode dedicated resource elements to determine the presence of predefined sequences, pause indications, and / or physical layer parameters, etc.

[0290] As an alternative or supplement, the WTRU can transmit the aforementioned indications on a separate control channel (e.g., a control channel used for UL low-latency control communications). The WTRU can transmit indications across different resource sets with shortened TTIs. The network can be configured to blindly decode the information transmitted by the WTRU. The WTRU can use UCI / SCI, UL control channels, SI, or RR to deliver new scheduling information and / or indicate new HARQ information, new physical layer parameters, new SOMs, and / or new TTIs. The WTRU can use one or more of the techniques described herein to transmit relevant information and / or select relevant parameters.

[0291] The WTRU can be configured to transmit RR, SI, and / or low-latency data concurrently with another transmission. If an RR is triggered concurrently with another transmission, the WTRU can transmit the RR in the middle of the ongoing transmission. Certain symbols and / or resources can be reserved within the TTI for transmitting RR for time-sensitive data. The WTRU can use CDMA-like signaling to transmit RR and / or SI. The WTRU can perforate time-sensitive data and can embed RR requests into the data signal or channel. The receiving entity of the data can receive notification that the data has been perforated.

[0292] When data transmission is interrupted by RR and / or time-sensitive data, multiple bits (e.g., all bits following the interruption) are discarded. The WTRU can embed information in its signal to indicate to the receiving entity that data from a previous transmission has been discarded and a new transmission has begun, or to indicate that RR / SI is being transmitted. The WTRU can also announce to the receiving entity (e.g., the network) that data (e.g., all data following the interruption) has been discarded. To handle time-sensitive data, the WTRU can discard packets from its transmission buffer or packets received from a higher layer before the RAN processes them. The WTRU can be configured to discard packets at any layer. For example, a packet can be discarded when it is received from a higher layer. As another example, a specific layer on the WTRU can discard SDUs received by the WTRU from the layer above it.

[0293] When discarding a packet, the WTRU can perform one or more actions. The WTRU can reorder the sequence number so that the discarded packet and / or SDU does not occupy a specific sequence number. The WTRU can use this transmission to send specific indications (such as MACCE or similar control messages) to provide the network with information about the discarded packet. Examples of dropable packet conditions may include one or more of the following: The WTRU can discard a packet or SDU when it arrives later than its expected delivery time. For example, the expected delivery time may have expired when the packet or SDU arrives. The WTRU can discard a packet or SDU when the expected processing time of the packet or SDU (e.g., as expected by the current or lower layer) causes the expected transmission time of the packet or SDU to expire before transmission. The WTRU can discard a packet or SDU when it is associated with a logical channel, flow, and / or service that allows packet discarding. The relevant logical channel, flow, and / or service can be configured to allow packet discarding at startup. When a packet or SDU is multiplexed with other packets that have time-sensitive latency requirements and the packet or SDU itself does not have time-sensitive latency requirements, the WTRU may discard the packet or SDU.

[0294] A WTRU can be configured to send an indication that a packet has been dropped to a lower layer, a higher layer, or the application layer. For example, a WTRU can be configured to send an indication to the PHY layer to increase the amount of resources available for transmission. As another example, a WTRU can be configured to notify the application layer of potential erroneous operations.

[0295] The exemplary communication system described herein can use multiple MAC CE or MAC layer control messages for MAC layer control signaling. An example of such a message can be associated with TRP modifications, including TRP switching, conversion, addition, activation, and / or deactivation. The network can be configured to instruct a WTRU to move a Tx / Rx from one TRP to another by sending such messages. The message can instruct the WTRU to initiate a combined TX / RX for two different TRPs. The message may include one or more of the following fields: target TRP identifier, target TRP configuration (e.g., resources, power, timers, etc.), target TRP carrier frequency and bandwidth, target TRP RACH or WTRU autonomous transmission configuration, and / or timing calibration. The WTRU may be pre-configured with a target TRP configuration and can receive an index and / or subset of that configuration to access the TRP.

[0296] Another example is a MAC CE or MAC layer control message that can be associated with a TRP connection request. A WTRU can be configured to request a connection to a specific TRP by sending such a message. This message may include WTRU identification information, a list of logical channels and / or services, and / or a reason for the connection request, etc.

[0297] Another example of a MAC CE or MAC layer control message can be associated with a TRP measurement list (as an example, this message may contain a TRP measurement list). The network can be configured to provide the WTRU with a list of TRPs that the WTRU should measure. As an example, the WTRU may be instructed to measure DL quality associated with the TRP list. The network can be configured to provide the WTRU with a TRP list, wherein the WTRU should measure a Position Reference Signal (PRS) (e.g., for determining the WTRU's location) according to the TRP list. The network can be configured to provide the WTRU with a list of TRPs that should be maintained by the WTRU at UL timing calibration for a specified time. A message containing a TRP measurement list may include one or more of the following fields: message type, a list of TRP identifiers (e.g., an index or similar identifier for each TRP), and / or a threshold associated with each TRP (e.g., for each TRP). In one example, the information associated with the TRP measurement list may be provided as part of RR and / or SI information.

[0298] Another example of a MAC CE or MAC layer control message can be associated with cross-TRP scheduling configuration. For instance, a network can be configured to send such a message to WTRUs to configure a semi-static cross-TRP scheduling configuration. This message may include one or more of the following fields: source TRP identifier, destination / destination TRP identifier, and / or resource mapping between source and destination resources.

[0299] Another example of a MAC CE or MAC layer control message can be associated with the location of a TRP. The network is configured to send such messages to the WTRU to provide the appropriate location of a TRP located near that WTRU. The message may include one or more of the following fields: an identifier of the TRP near the WTRU, a system signature used by the TRP, and / or the appropriate location of the TRP.

[0300] Another example of a MAC CE or MAC layer control message can be associated with a timing calibration request. A WTRU can be configured to send such a message to the network to request the network to provide UL timing calibration and / or initiate a timing calibration process for that WTRU. This message may include one or more of the following fields: a request to enable / disable timing calibration, and a SOM in which timing calibration is requested.

[0301] Another example of a MAC CE or MAC layer control message can be associated with enhanced timing advance. The message may include one or more of the following fields: TRP identifier, timing offset associated with each TRP, timing offset associated with each SOM, and / or an indication of whether techniques are allowed or not for uplink timing calibration.

[0302] Another example of a MAC CE or MAC layer control message can be associated with an enhanced buffer status report. The message may include one or more of the following: logical channel ID or logical channel group ID, number of bytes in the queue, data priority, QoS classification, one or more pieces of information associated with an RR, transport channel type, number of bytes in the queue with a TTL below a first threshold, and / or number of bytes in the queue with a TTL above a threshold but below a second threshold. Different MAC CEs may be defined for different RR types. A MAC CE may include a header indicating the RR type corresponding to that MAC CE.

[0303] Another example of a MAC CE or MAC layer control message can be associated with a packet drop indication. This message can be sent from the WTRU to the network or from the network to the WTR to notify the SDU ordering entity in the WTRU or network scheduler of packet loss in the sequence. The message may include one or more of the following fields: the logical channel or flow from which the packet was dropped, and / or the index of the dropped packet (for example, or the index of the range of dropped packets).

[0304] Another example of a MAC CE or MAC layer control message can be associated with SPS configuration. The network can be configured to send such messages to WTRUs to configure and / or reconfigure resources in semi-permanent scheduling within the WTRUs (as an example, these resources may be pre-configured). The message may include one or more of the following fields: resource identifier (e.g., time, frequency, duration, period, etc.), usage restrictions, resource identifier or resource set identifier (e.g., several resources may be configured), and / or the SOM associated with the resource or resource set.

[0305] Another example of a MAC CE or MAC layer control message can be associated with SPS resource enable or disable processing. A WTRU can be configured to send such a message to the network to enable or disable a pre-configured SPS resource or set of SPS resources. This message may include one or more of the following fields: an instruction regarding enabling or disabling SPS, and / or an identifier for the resource or set of resources.

[0306] Another example of a MAC CE or MAC layer control message can be associated with resource requests, resource increases or decreases, and / or resource indications. A WTRU can be configured to send such a message to the network to indicate a request for a specific type of resource (e.g., short TTI resources), to request an increase or decrease in the amount of these resources allocated over time, and / or to indicate to the network that the WTRU is currently using or wants to use a specific resource. The message may include one or more of the following fields: message type, SOM identifier, increment / decrement, requested resource amount, and / or type of resource and / or constraint.

[0307] Another example of a MAC CE or MAC layer control message can be associated with connection reconfiguration. The network can be configured to send such messages to the WTRU to reconfigure a specific connection with the TRP. This message may include one or more of the following (e.g., for each SOM connected to the TRP): new radio configuration, resource configuration, power configuration, and / or timer configuration, etc.

[0308] While features and elements in specific combinations have been described above, those skilled in the art will recognize that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disk enclosures and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital multipurpose discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any computer host.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: The processor is configured as follows: Receive information indicating uplink transmission grants for the WTRU and the priority associated with the uplink transmission grants, wherein the uplink transmission grants are associated with subcarrier spacing; Determine that the data associated with the first logical channel is available for transmission; Based at least on the priority associated with the uplink transmission license, the subcarrier spacing associated with the uplink transmission license, the subcarrier spacing associated with the first logical channel, and the priority associated with the first logical channel, it is determined that the data associated with the first logical channel will be transmitted using the uplink transmission license; as well as The uplink transmission license is used to transmit the data associated with the first logical channel.

2. The WTRU of claim 1, wherein the processor is further configured to receive configuration information indicating the priority associated with the first logical channel.

3. The WTRU of claim 1, wherein determining that the data associated with the first logical channel will be transmitted using the uplink transmission license is made by matching the priority associated with the uplink transmission license with the priority associated with the first logical channel.

4. The WTRU of claim 1, wherein the determination that the data associated with the first logical channel will be transmitted using the uplink transmission license is further based on a spectrum operating mode (SOM) associated with the uplink transmission license, wherein the SOM is characterized by the subcarrier spacing associated with the uplink transmission license.

5. The WTRU of claim 1, wherein the determination that the data associated with the first logical channel will be transmitted using the uplink transmission license is further based on transmission timing parameters associated with the uplink transmission license.

6. The WTRU of claim 1, wherein the processor is further configured to determine that data associated with the second logical channel is available for transmission, and to determine, at least based on the priority associated with the uplink transmission license and the priority associated with the second logical channel, that the data associated with the second logical channel will be transmitted without using the uplink transmission license.

7. The WTRU of claim 6, wherein the processor is further configured to send a scheduling request (SR) to the base station in response to determining that the data associated with the second logical channel will be transmitted without using the uplink transmission license.

8. The WTRU of claim 7, wherein the SR is transmitted to the base station using one or more SR resources configured for the second logical channel.

9. The WTRU of claim 8, wherein the processor is further configured to receive configuration information indicating the one or more SR resources configured for the second logical channel.

10. The WTRU of claim 1, wherein the information indicating the uplink transmission grant and the priority associated with the uplink transmission grant is received via a downlink control channel.

11. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Receive information indicating uplink transmission grants for the WTRU and the priority associated with the uplink transmission grants, wherein the uplink transmission grants are associated with subcarrier spacing; Determine that the data associated with the first logical channel is available for transmission; Based at least on the priority associated with the uplink transmission license, the subcarrier spacing associated with the uplink transmission license, the subcarrier spacing associated with the first logical channel, and the priority associated with the first logical channel, it is determined that the data associated with the first logical channel will be transmitted using the uplink transmission license; as well as The uplink transmission license is used to transmit the data associated with the first logical channel.

12. The method of claim 11, further comprising: Receive configuration information indicating the priority associated with the first logical channel.

13. The method according to claim 11, wherein, The determination that the data associated with the first logical channel will be transmitted using the uplink transmission license is made by matching the priority associated with the uplink transmission license with the priority associated with the first logical channel.

14. The method according to claim 11, wherein, The determination to use the uplink transmission license to transmit the data associated with the first logical channel is further based on the spectrum operating mode (SOM) associated with the uplink transmission license, wherein the SOM is characterized by the subcarrier spacing associated with the uplink transmission license.

15. The method according to claim 11, wherein, The determination that the data associated with the first logical channel will be transmitted using the uplink transmission license is further based on the transmission timing parameters associated with the uplink transmission license.

16. The method of claim 11, further comprising: It is determined that the data associated with the second logical channel is available for transmission, and it is determined, at least based on the priority associated with the uplink transmission license and the priority associated with the second logical channel, that the data associated with the second logical channel will not be transmitted using the uplink transmission license.

17. The method of claim 16, further comprising: In response to determining that the data associated with the second logical channel will not be transmitted using the uplink transmission license, a scheduling request (SR) is sent to the base station.

18. The method according to claim 17, wherein, The SR is transmitted to the base station using one or more SR resources configured for the second logical channel.

19. The method of claim 18, further comprising: Receive configuration information indicating that the one or more SR resources are configured for the second logical channel.

20. The method according to claim 11, wherein, The information indicating the uplink transmission grant and the priority associated with the uplink transmission grant is received via the downlink control channel.

Images