User plane processing in a wireless system

Abstract

To provide systems, methods, and instrumentalities for handling a user plane in a wireless communication system.SOLUTION: Wireless communication systems may be characterized by a flexible radio interface. One aspect of a flexible air interface is that transmissions by wireless transmit / receive units (WTRUs) in the system may have different quality of service (QoS) requirements, such as different delay requirements. The WTRU may adjust its behavior based on the QoS requirements, for example, by utilizing preconfigured resources, resource requests, self-scheduling, and / or the like, such that transmissions may be performed according to their respective QoS requirements.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to user plane processing in wireless systems. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 315,373, filed March 30, 2016, the entire disclosure of which is incorporated herein by reference.

[0003] Mobile communications is in a constant state of evolution and is already on the threshold of its fifth incarnation – 5G. 5G networks can be built on flexible radio access technologies. Summary of the Invention [Problem to be solved by the invention]

[0004] As these new technologies emerge, problems arise in determining how to support a wide variety of use cases with different characteristics. [Means for solving the problem]

[0005] Disclosed herein are systems, methods, and means for transmitting uplink data from a wireless transmit / receive unit (WTRU) to a network. The uplink data may include uplink data units (e.g., uplink data packets), and the transmission of the uplink data units may be performed to meet certain quality of service (QoS) requirements. The QoS requirement may be a timing requirement. For example, the QoS requirement may be that the uplink data units be transmitted with relatively low latency.

[0006] The WTRU may maintain a time-to-live (TTL) parameter to monitor transmission delays of uplink data units. For example, the value of the TTL parameter may reflect the amount of time that has elapsed since the uplink data unit became available for transmission and / or the amount of time remaining before successful transmission of the uplink data unit is deemed likely. The WTRU may determine a threshold value for the TTL parameter based on QoS requirements, attempt to transmit the uplink data unit using a first transmission mode, and determine that the value of the TTL parameter has reached the threshold value before successful transmission can be achieved. The WTRU may then attempt to transmit the uplink data unit using a second transmission mode, for example, until the TTL parameter expires.

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

[0008] The WTRU may receive the pre-configured resources when it first registers with the network. Alternatively, or additionally, the WTRU may receive the pre-configured resources via dedicated signaling from the network (e.g., after the WTRU has already registered with the network). The WTRU may obtain access to the pre-configured set of resources via an uplink transmission to the network. The uplink transmission may, for example, indicate the time the WTRU desires to use the pre-configured resources. The WTRU may receive an acknowledgment from the network in response to the uplink transmission.

[0009] The WTRU may send uplink control information (UCI) to the network in the second transmission mode. The UCI may include a request for resources. The UCI may indicate QoS requirements associated with the uplink data unit or a numerology for the uplink data unit. The WTRU may receive a grant from the network in response to the UCI. The grant may indicate which resources the WTRU may use in the second transmission mode. Additionally or alternatively, the grant may specify a spectrum operation mode (SOM) or transport channel that the WTRU may use in the second transmission mode. For example, the grant may specify a numerology and / or a waveform that the WTRU may use in the second transmission mode.

[0010] The WTRU can interrupt existing Hybrid Automatic Repeat Request (HARQ) to transmit uplink data units in the second transmission mode. A more detailed understanding may be obtained from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0011] [Figure 1A]FIG. 1 is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A. [Figure 1C] 1B is a system diagram of an example radio access network and an example core network that may be used within the communication system shown in FIG. 1A. [Figure 1D] 1B is a system diagram of another example radio access network and an example core network that may be used within the communication system shown in FIG. 1A. [Figure 1E] 1B is a system diagram of another example radio access network and an example core network that may be used within the communication system shown in FIG. 1A. [Figure 2] FIG. 1 illustrates an example of bandwidth flexibility. [Figure 3] FIG. 1 illustrates an example of flexible spectrum allocation. [Figure 4A] FIG. 1 illustrates an example of timing relationships for TDD duplexing. [Figure 4B] FIG. 1 illustrates an example of timing relationships for FDD duplexing. [Figure 5] FIG. 1 illustrates an example of prioritized transmissions. DETAILED DESCRIPTION OF THE INVENTION

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

[0013] The following abbreviations and acronyms are used in the description of the exemplary embodiments:

[0014] Δf subcarrier spacing 5gFlex 5G Flexible Radio Access Technology 5gNB 5GFlex Node B ACK Acknowledgment BLER Block Error Rate BTI Basic TI (one or more integer multiples of the symbol duration) CB contention-based (e.g., access, channel, resource) CoMP multipoint coordinated transmission and reception CP cyclic prefix CP-OFDM Conventional OFDM (relies on cyclic prefix) CQI Channel Quality Indicator CN Core Network (e.g., LTE Packet Core) CRC Cyclic Redundancy Check CSI Channel State Information CSG Limited Subscriber Group D2D Device-to-Device Transmission (e.g., LTE Sidelink) DCI Downlink Control Information DL Downlink DM-RS demodulation reference signal DRB Data Radio Bearer EMBB Enhanced Mobile Broadband EPC Evolved Packet Core FBMC Filter Band Multi-Carrier FBMC / OQAM: FBMC technique using offset quadrature amplitude modulation FDD Frequency Division Duplex FDM frequency division multiplexing FEC Forward Error Correction ICC Industrial Control Communication ICIC Inter-cell interference cancellation IP Internet Protocol LAA License Assisted Access LBT Listen Before Talk LCH Logical Channel LCG Logical Channel Group LCP Logical Channel Priority LLC low latency communication LTE Long Term Evolution, e.g., 3GPP LTE From R8 and above MAC Media Access Control NACK Negative ACK MBB Massive Broadband Communications MC Multi-Carrier MCS Modulation and Coding Scheme MIMO Multiple Input Multiple Output MTC Machine Type Communication NAS non-access layer OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OOB Out of Band (radiated) PBR Priority Bitrate P cmax Total available UE power at a given TI PHY Physical Layer PRACH Physical Random Access Channel PDU Protocol Data Unit PER Packet Error Rate PL propagation loss (estimated) PLMN Public Land Mobile Network PLR Packet Loss Rate PSS Primary Synchronization Signal QoS Quality of Service (Physical Layer Perspective) RAB Radio Access Bearer RACH Random Access Channel (or Procedure) RF Radio Front End RNTI Radio Network Identifier RRC Radio Resource Control RRM Radio Resource Management RS reference signal RTT Round Trip Time SCMA Single Carrier Multiple Access SDU Service Data Unit SOM Spectral Operation Mode SS Sync Signal SSS Secondary Synchronization Signal SRB Signaling Radio Bearer SWG Switching Gap (in self-contained subframe) TB Transport Block TBS Transport Block Size TDD time division duplex TDM time division multiplexing TI time interval (in multiples of one or more BTIs) TTI Transmission Time Interval (one or more multiples of TI) TRP Transmit / Receive Point TRx Transceiver UFMC Universal Filter Multi-Carrier UF-OFDM Universal Filter OFDM UL Uplink URC Ultra Reliable Communications URLLC Ultra-reliable low latency communication V2V vehicle-to-vehicle communication V2X vehicle communications WLAN Wireless Local Area Network and related technologies (IE EE802.xx field) WTRU Radio Transmit / Receive Unit

[0015] 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 enables the multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDM) single-carrier FDMA (SC-FDMA), orthogonal frequency division multiplexing with offset quadrature amplitude modulation (OFDM-OQAM), universal filter orthogonal frequency division multiplexing (UF-OFDM), and the like.

[0016] As shown in FIG. 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (which may be collectively or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, networks, and / or network elements.

[0017] The communications system 100 may also include several base stations, such as, for example, base station 114a and base station 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d and facilitate access to one or more communications networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a site controller, an Access Point (AP), a wireless router, and the like. While the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0019] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

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

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

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

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

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

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

[0026] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that can use cellular-based wireless technology and with a base station 114b that can use IEEE 802 wireless technology.

[0027] 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRUs 102a, 102b, 102c, 102d may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0028] The processor 118 of the WTRU 102 may 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), field programmable gate array (FPGA) circuitry, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that both the processor 118 and the transceiver 120 may be integrated into an electronic package or chip.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0057] The example communications systems described herein may support air interfaces that enable one or more of the following: improved broadband performance (IBB), industrial control and communications (ICC), vehicular applications (V2X), and massive machine-to-everything (mMTC). The air interfaces may support ultra-low latency communications (LLC), ultra-reliable communications (URC), and / or MTC operation (e.g., including narrowband operation). For LLC, one or more of the following may be supported: low air interface latency (e.g., 1 ms RTT), short TTI (e.g., between 100 μs and 250 μs), ultra-low access latency (e.g., access latency may be related to the amount of time from initial system access to the completion of transmission of the first user plane data unit), and / or low end-to-end (e2e) latency (e.g., less than 10 ms for ICC and / or V2X). For URC, the reliability of transmission / communication can reach, for example, 99.999% transmission success and / or service availability. Mobility for speeds ranging from 0 to 500 km / h should be desirable. Packet loss rate should be 10 -6 For MTC operation, the air interface may support narrowband operation (e.g., using less than 200 kHz), extended battery life (e.g., up to 15 years autonomously), and / or reduced communication overhead (e.g., at least for small and / or infrequent data transmissions, such as at data rates in the 1-100 kbps range and / or with access latencies of a few seconds to a few hours).

[0058] The exemplary communication systems described herein may utilize OFDM as a waveform (at least in the downlink). OFDM may be the basic signal format for data transmission in LTE and / or IEEE 802.11. With OFDM, the spectrum may be divided into multiple parallel orthogonal subbands. The subcarriers may be shaped using a rectangular window in the time domain, which may result in sinc-shaped subcarriers in the frequency domain. OFDMA may be designed to attempt to achieve a high level of frequency synchronization and / or uplink timing alignment within the duration of the cyclic prefix (e.g., maintaining orthogonality between signals and / or minimizing inter-carrier interference). The synchronization requirements of OFDM (e.g., conventional OFDM or CP-OFDM) are challenging to meet in exemplary communication systems designed to achieve the other design goals mentioned above (e.g., because a WTRU may be connected to multiple access points simultaneously). Further power reduction may be applied to uplink transmissions to comply with spectral emission requirements into adjacent bands (e.g., in the presence of aggregation of fragmented spectrum for WTRU transmissions). Considering these challenges, the exemplary communication systems described herein may impose more stringent RF requirements on CP-OFDM (e.g., a large amount of contiguous spectrum that does not rely on aggregation is used, etc.). When used, CP-OFDM-based transmission schemes can result in a downlink physical layer similar to that of legacy systems (e.g., with modifications to pilot signal density and location).

[0059] The exemplary communication systems described herein may utilize other waveforms. For example, the downlink transmission scheme in the exemplary communication system may be based on a multi-carrier (MC) waveform. The MC waveform may be characterized, for example, by high spectral suppression (e.g., low sidelobes and / or low OOB emissions). The MC waveform may divide a channel into subchannels and modulate data symbols on subcarriers in these subchannels. An exemplary MC waveform is OFDM-OQAM. With OFDM-OQAM, a filter may be applied to the OFDM signal in the time domain (e.g., per subcarrier) to, for example, reduce OOB. OFDM-OQAM may produce low interference to adjacent bands, may not require large guard bands, and may not utilize a cyclic prefix. OFDM-OQAM may be a suitable FBMC technique. However, it should be noted that in some exemplary systems, OFDM-OQAM is susceptible to multipath effects and high delay spread in terms of orthogonality. Equalization and channel estimation with OFDM-OQAM can be complex.

[0060] Another exemplary MC waveform that can be used is UFMC (UF-OFDM). With UFMC (UF-OFDM), a filter can be applied to the OFDM signal in the time domain (e.g., to reduce OOB). In an example, filtering can be applied per subband so that spectrum fragments can be used (to reduce implementation complexity). If some spectrum fragments in a band are unused, OOB emissions in these fragments may remain high (e.g., as may be the case with conventional OFDM). For at least this reason, UF-OFDM may be a suitable waveform for use at least at the edges of the filtered spectrum.

[0061] It should be noted that the waveforms described herein are examples and, therefore, are not the only waveforms with which the embodiments described herein may be implemented. The exemplary waveforms can enable multiplexing of signals having at least non-orthogonal properties (e.g., signals with different subcarrier spacings, etc.). The exemplary waveforms can enable coexistence of asynchronous signals (e.g., without requiring complex interference-canceling receivers). The exemplary waveforms can facilitate aggregation of fragmented spectrum, for example, in baseband processing, as a low-cost alternative to aggregating fragmented spectrum as part of RF processing.

[0062] In an exemplary communications system, different waveforms may coexist within the same band (e.g., to support at least mMTC narrowband operation, which may use SCMA). Different combinations of waveforms, such as CP-OFDM, OFDM-OQAM, and / or UF-OFDM, may be supported for some or all aspects of operation and / or for either or both downlink and uplink transmissions. Waveform coexistence may include, for example, transmissions using different types of waveforms between different WTRUs or transmissions from the same WTRU (e.g., transmissions may occur simultaneously, with some overlap, or consecutively in the time domain).

[0063] Other coexistence aspects may include, for example, support for hybrid-type waveforms (e.g., waveforms and / or transmissions supporting at least a variable CP duration, such as one that varies from transmission to transmission), support for a combination of CP and low-power tail (e.g., zero tail), support for forms of hybrid guard interval (e.g., using a low-power CP and / or an adaptive low-power tail), and / or the like. Exemplary waveforms may support dynamic variation and / or control of one or more other aspects, such as filtering. For example, one or more of the following may be dynamically varied and / or controlled: whether filtering should be applied at the edge of the spectrum used to receive transmissions of a given carrier frequency, whether filtering should be applied at the edge of the spectrum used to receive transmissions associated with a particular SOM, whether filtering should be applied per subband or per group, and / or the like. In general, waveforms / waveform types may be considered examples of transmission parameters that can be varied to achieve different types of transmission schemes. Thus, a first transmission scheme may utilize a first type of waveform (e.g., CP-OFDM), while a second transmission scheme may utilize a different waveform (e.g., OFDM-OQAM), which may be associated with different transmission characteristics, such as different possible throughputs, different delay characteristics, different overhead requirements, etc.

[0064] The uplink transmission scheme may use the same waveform as in the downlink transmission scheme or a different waveform. The multiplexing of transmissions between different WTRUs in the same cell may be based on FDMA and / or TDMA.

[0065] The example communications designs described herein can be characterized by a high degree of spectrum flexibility. Such spectrum flexibility can support (e.g., enable) deployment in different frequency bands with different characteristics, including, for example, different duplex configurations and / or different sizes of available spectrum (e.g., including contiguous and non-contiguous spectrum allocations in the same band or in different bands). Spectral flexibility can support variable timing aspects, including, for example, support for multiple TTI lengths and / or support for asynchronous transmission.

[0066] The exemplary communication systems described herein can be characterized by flexibility in duplex configuration. For example, the exemplary communication systems can support both TDD and FDD duplexing schemes. For FDD operation, spectrum aggregation can be used to support supplemental downlink operation. Both full-duplex FDD and half-duplex FDD operation can be supported. For TDD operation, the DL / UL allocation can be dynamic. For example, the allocation can be set for each transmission opportunity, with the length of the DL or UL transmission interval rather than based on a fixed DL / UL frame configuration.

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

[0068] FIG. 2 illustrates an exemplary transmission bandwidth that may be supported by an exemplary communications system. The system bandwidth referred to herein may relate to the maximum portion of spectrum that may be managed by a given carrier network. For such a carrier, the portion of spectrum that a WTRU can support (e.g., minimally support) for cell acquisition, measurements, and initial access to the network may correspond to the nominal system bandwidth. A WTRU may be configured with a channel bandwidth that falls within the entire system bandwidth. The WTRU's configured channel bandwidth may or may not include the nominal portion of the system bandwidth.

[0069] One example reason that bandwidth flexibility can be achieved in the example communications systems described herein is that some or all of the applicable RF requirements for a given operating bandwidth (e.g., maximum operating bandwidth) can be met without introducing additional allowable channel bandwidth for that operating band. This can be done, for example, by efficiently supporting baseband filtering of the associated frequency-domain waveform. The embodiments described herein can utilize techniques for configuring, reconfiguring, and / or dynamically changing the channel bandwidth of a WTRU for single-carrier operation. The embodiments described herein can allocate spectrum within the nominal system bandwidth, the system bandwidth, or a configured channel bandwidth for narrowband transmissions. The physical layer of the example communications system may be bandwidth independent. The physical layer can support operation in licensed bands (e.g., below 5 GHz) as well as unlicensed bands (e.g., in the range of 5-6 GHz or higher). For operation in unlicensed bands, an LBT Cat4-based channel access framework (e.g., a channel access framework similar to the LTE LAA) can be supported. The embodiments described herein may utilize techniques for scaling and / or managing cell-specific and / or WTRU-specific channel bandwidths for different spectrum block sizes. These techniques may be related to, for example, scheduling, resource addressing, signal broadcasting, measurements, etc. The spectrum block size may be any size.

[0070] The example communication systems described herein can be characterized by flexibility in spectrum allocation. Downlink control channels and signals can support FDM operation. A WTRU can acquire a downlink carrier, for example, by receiving transmissions over (e.g., only) a nominal portion of the system bandwidth. For example, a WTRU may not initially be configured to receive transmissions over the entire bandwidth managed by the involved carrier network.

[0071] The downlink data channel can be allocated over a bandwidth that may or may not correspond to the nominal system bandwidth. The allocation should be without any restrictions other than being within the WTRU's configured channel bandwidth, for example. For example, a carrier may operate over a 12 MHz system bandwidth with a 5 MHz nominal bandwidth. Such a configuration allows devices supporting a maximum RF bandwidth of 5 MHz to acquire and access the system, but can allocate carrier frequencies from +10 to -10 MHz to other WTRUs supporting channel bandwidths up to 20 MHz equivalent.

[0072] FIG. 3 illustrates an example of a spectrum allocation in which different subcarriers may be assigned (e.g., at least conceptually) to different SOMs. The different SOMs can be used to meet different requirements for different transmissions. The SOMs can include / be defined based on one or more of subcarrier spacing, TTI length, or reliability aspects (e.g., HARQ processing aspects). The SOMs can comprise secondary control channels. For example, the SOMs can include a separate control channel (e.g., separate from the primary control channel) that an associated WTRU can be configured to monitor. The SOMs can be used to refer to a particular waveform or can be associated with processing aspects, such as, for example, supporting coexistence of different waveforms on the same carrier using FDM and / or TDM, or supporting coexistence of FDD and TDD (e.g., implementing FDD operation in a TDD band, as in TDM).

[0073] The WTRU may be configured to perform transmissions according to one or more SOMs. For example, the SOM may correspond to transmissions 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 over a specific RAT (e.g., legacy LTE or 5G transmission techniques may be used). The SOM may correspond to a QoS level and / or related aspects such as a maximum / target delay, a maximum / target BLER, and / or the like. The SOM may correspond to a spectrum region and / or a specific control channel or aspect thereof (e.g., search space, DCI type, etc.). For example, the WTRU may be configured with an SOM for one or more of URC-type services, LLC-type services, or MBB-type services. The WTRU may have an SOM configuration for system access and / or for transmission / reception of L3 control signaling (e.g., RRC) (e.g., the WTRU may receive). For example, a WTRU may be configured to send and / or receive L3 control signaling using a portion of the system spectrum, such as the nominal system bandwidth described herein.

[0074] The resources of a given SOM may be defined or described in terms of a particular computation scheme for that SOM. For example, a first SOM may use a first computation scheme (e.g., a first subcarrier spacing, a first symbol length, a first TTI length, a first bandwidth, a first waveform type, etc.), and a second SOM may use a second computation scheme (e.g., a second subcarrier spacing, a second symbol length, a second TTI length, a second bandwidth, a second waveform type, etc.). The terms SOM and computation scheme may be referred to interchangeably herein.

[0075] A WTRU in the example communication systems described herein may be configured to switch to a different transmission scheme if the WTRU determines that it cannot successfully complete a transmission using the original transmission scheme. As described herein, a transmission scheme may encompass resources, transmission techniques, transmission parameters, and / or other operational aspects associated with the performance of a transmission. For example, different transmission schemes may utilize different SOMs and / or different calculation schemes. Thus, the SOMs and / or calculation schemes may be examples of operational aspects that may change for different types of transmission schemes.

[0076] The example communication systems described herein may support spectrum aggregation (e.g., at least for single-carrier operation). For example, spectrum aggregation may be supported in situations where a WTRU may transmit and / or receive multiple transport blocks over contiguous and / or non-contiguous sets of physical resource blocks (PRBs) within the same operating band. Transport blocks may be mapped to separate sets of PRBs. Transmissions associated with different SOMs may occur simultaneously.

[0077] The example communications systems described herein may support multi-carrier operation. Such support may be provided, for example, by using contiguous and / or non-contiguous blocks of spectrum within the same operating band or across two or more operating bands. The example communications systems may support aggregation of spectrum blocks. For example, spectrum blocks may be aggregated using different modes, such as FDD and / or TDD, and / or using different channel access techniques, such as licensed and unlicensed band operation below 6 MHz. The multi-carrier aggregation operation of the WTRU may be configured, reconfigured, and / or dynamically changed by the network and / or the WTRU.

[0078] Downlink and / or uplink transmissions can be organized into radio frames. A radio frame can be characterized by some fixed aspects (e.g., the location of downlink control information) and / or some variable aspects (e.g., transmission timing and / or supported transmission types). A basic time interval (BTI) can be represented by one or more numbers of symbols (e.g., an integer). The symbol duration can correspond to a subcarrier spacing applicable to the time-frequency resource. At least for FDD, the subcarrier spacing is determined by the uplink carrier frequency f for a given frame. UL and the downlink carrier frequency f DL The transmission time interval (TTI) may be the minimum time supported by the system between successive transmissions. One or more (e.g., each) of the successive transmissions may be in the downlink (TTI DL ) and / or uplink (UL TRx). Preambles for the downlink and / or uplink (if applicable) may be excluded from the TTI determination. Control information (e.g., DCI for the downlink or UCI for the uplink) may be included in the TTI determination. A TTI may be represented by a number (e.g., an integer) of one or more BTIs. A BTI may be specific and / or associated with a given SOM and / or calculation scheme.

[0079] The exemplary communication systems described herein can support various frame durations, including, for example, 100 μs, 125 μs (1 / 8 ms), 142.85 μs (e.g., 1 / 7 ms or 2 nCP LTE OFDM symbols), and / or 1 ms. The frame duration can be configured to align with the legacy LTE timing structure. The frames are timed based on the associated carrier frequency (e.g., f for TDD). UL+DL , and f for FDD DL) for a fixed time period t preceding a downlink data transmission (DL TRx). dci In the case of TDD duplexing (e.g., in the case of only TDD duplexing), the frame may include a downlink portion (e.g., DCI and / or DL ​​TRx) and / or an uplink portion (e.g., UL TRx). A switching gap ("swg"), if present, may precede (e.g., always precede) the uplink portion of the frame. In the case of FDD duplexing (e.g., in the case of only FDD duplexing), the frame may include a downlink reference TTI and one or more TTIs for the uplink. The start of the uplink TTI is determined by an applied offset (t) from the start of the downlink reference frame, which may overlap with the start of the uplink frame. offset ) The duplex mode (e.g., TDD vs. FDD) may be an example of an operating aspect that may vary for different types of transmission schemes.

[0080] The exemplary communication system described herein may support D2D / V2x / sidelink operation in a frame. The exemplary communication system may utilize various configurations / techniques to provide D2D / V2x / sidelink support. In an example (e.g., when TDD is used), the exemplary communication system may include downlink control and forward transmissions, respectively, in the DCI+DL TRx portion of the frame (e.g., when semi-static resource allocation is used) or in the DL TRx portion of the frame (e.g., when dynamic resource allocation is used). Additionally or alternatively, the exemplary communication system may include each reverse transmission in the UL TRx portion of the frame. In an example (e.g., when FDD is used), the exemplary communication system may support D2D / V2x / sidelink operation in the UL TRx portion of the frame, e.g., by including downlink control, forward, and reverse transmissions, respectively, in the UL TRx portion of the frame. Furthermore, the resources associated with each transmission may be dynamically assigned.

[0081] Figure 4A shows an example TDD frame structure, and Figure 4B shows an example FDD frame structure.

[0082] The example communications systems described herein may use various scheduling and / or rate control techniques, including, for example, a scheduling function at the MAC layer, a network-based scheduling mode, and / or a WTRU-based scheduling mode. The network-based scheduling mode may be strict, for example, with respect to resources, timing, and / or transmission parameters of downlink and / or uplink transmissions. The WTRU-based scheduling mode may be flexible, for example, with respect to timing and / or transmission parameters. For one or more of the scheduling techniques (e.g., scheduling modes), scheduling information may be valid for a single TTI or for multiple TTIs. The scheduling techniques (e.g., scheduling modes) may be examples of operational aspects that may vary for different types of transmission schemes.

[0083] Network-based scheduling allows the network to tightly manage radio resources allocated to different WTRUs (e.g., to optimize sharing of such resources). In at least some cases, the network may perform scheduling dynamically. WTRU-based scheduling allows the WTRU to access (e.g., opportunistically access) uplink resources with minimal latency as needed and / or included in a set of shared or dedicated uplink resources allocated by the network. The shared or dedicated uplink resources may be assigned dynamically or statically. The WTRU may be configured to perform synchronized and / or unsynchronized opportunistic transmissions. The WTRU may be configured to perform contention-based and / or non-contention-based transmissions. For example, the WTRU may be configured to perform opportunistic transmissions (e.g., scheduled or unscheduled) to meet ultra-low latency requirements (e.g., for 5G) and / or power saving requirements (e.g., in examples using mMTC).

[0084] The exemplary communication systems described herein may prioritize logical channels. For example, the exemplary communication systems may be configured to associate data and resources (e.g., for uplink transmissions). The exemplary communication systems may multiplex data having different QoS requirements within the same transport block, as long as, for example, such multiplexing does not negatively impact the QoS requirements of the services or unnecessarily consume system resources. Prioritization of logical channels may be an example of an operational aspect that may vary for different types of transmission schemes.

[0085] The example communication systems described herein can encode transmissions using different encoding techniques. Different encoding techniques can have different characteristics. The encoding techniques can generate a sequence of 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, an error in the transmission of a first block should not impair the ability of a receiving device to successfully decode a second block, e.g., if the second block is error-free and / or if sufficient redundancy can be found in the second block or in a different block that is at least partially successfully decoded.

[0086] An exemplary encoding technique may include a raptor / fountain code, whereby a transmission may include a sequence of N raptor codes. One or more such codes may be mapped in time to one or more transmit symbols. A transmit symbol may correspond to one or more sets of information bits (e.g., one or more 8-bit bytes). Using such an encoding technique, FEC may be added to the transmission, whereby a transmission may use N+1 or N+2 raptor codes or symbols, assuming a one-per-symbol relationship. In this way, the transmission may be resilient to symbol loss due to, for example, interference from another transmission that overlaps in time and / or puncturing. The encoding / decoding technique may be an example of an operational aspect that may vary for different types of transmission schemes.

[0087] A WTRU may be configured to receive and / or detect one or more system signatures. The system signature may comprise a signal structure that uses a sequence. The signal may be similar to a synchronization signal. The system signature may be specific to a particular node or TRP in a given area (e.g., may uniquely identify the node or TRP), or it may be common to multiple such nodes or TRPs in the area. One or more of the aforementioned aspects may be unknown and / or irrelevant to the WTRU. The WTRU may determine and / or detect a system signature sequence and may further determine one or more parameters associated with the system. For example, the WTRU may derive and use an index to obtain the relevant parameters (e.g., the WTRU may obtain the parameters from a table such as an access table described herein). The WTRU may use the received power associated with the system signature for open-loop power control (e.g., set an initial transmit power if the WTRU determines that it can access and / or transmit using applicable resources of the system). For example, if the WTRU determines that it can access and / or transmit using applicable resources of the system, it may use the timing of the received signature sequence to set the timing of the transmission (e.g., preamble on PRACH resources). Different signal structures may be associated with different SOMs and / or different calculation schemes. Thus, the signal structure may be an example of an operational aspect that may vary for different types of transmission schemes.

[0088] A WTRU may be configured with a list of entries (e.g., operational parameters), which may be referred to as an access table. While referred to as an access table, it should be noted that the list of entries may be stored in any suitable type of structure, including a table structure. The list of entries, or access table, may be indexed such that an entry (e.g., each entry) is associated with a system signature and / or its sequence. The list or access table may provide initial access parameters for one or more areas. For example, an entry (e.g., each entry) in the list may provide one or more parameters associated with making an initial access to the system. Such parameters may include one or more random access parameters, such as, for example, applicable physical layer resources (e.g., PRACH resources) in time and / or frequency, initial power level, and / or physical layer resources for response reception. Such parameters may include access restrictions, such as PLMN identification and / or CSG information. Such parameters may include information related to routing, such as applicable routing areas. An entry (e.g., each entry) may be associated with and / or indexed by a system signature. An entry (e.g., each entry) may be common to multiple nodes or TRPs. The WTRU may receive such a list or access table by transmission over dedicated resources (e.g., RRC configuration) and / or by transmission using broadcast resources. In at least the latter case, the periodicity of the access table transmissions may be long (e.g., up to 10240 ms). For example, the periodicity of the access table transmissions may be longer than the periodicity of the signature transmissions (e.g., it may be in the range of 100 ms). The access tables described above may be examples of operational aspects that may vary for different types of transmission schemes.

[0089] The example communication systems described herein can support a variety of use cases. Each use case may include a different set of QoS requirements. There may be differentiation among these use cases with respect to applicable radio resources and / or transmission techniques. For example, use cases may differ with respect to TTI duration, reliability, diversity applied to transmission, maximum delay, etc. QoS differentiation can be introduced for different data packets, data flows, and / or data bearers (or equivalent forms thereof). Differentiation can relate to maximum guaranteed delay budgets, packet error rates, data rates, and / or the like. The MAC layer can process one or more of the functions described herein to address all or a subset of the following aspects:

[0090] Given different possible radio resources and / or transmission techniques with different characteristics, 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 different possible resource allocations (e.g., on the uplink and / or downlink) with different characteristics, the WTRU can be configured to exercise control (e.g., control grants and / or resource allocations) over downlink and uplink transmissions (e.g., determine and process one or more types of allocations separately). Given different characteristics associated with different transport blocks, the WTRU can be configured to multiplex and / or assemble MAC PDUs that meet the applicable QoS requirements. For example, the WTRU can allocate data associated with different bearers, different logical connections, and / or the like according to an expanded set of rules (e.g., by taking into account the QoS characteristics of the associated data and / or of the SOMs associated with the involved TBs). Given the use cases and transmission techniques described herein, the WTRU may be configured to meet one or more a priori requirements for uplink transmission (e.g., the a priori requirements may include UL TA, positioning, WTRU velocity, PL estimation, etc.). For example, the WTRU may manage and / or determine whether it has sufficient a priori requirements to perform a given type of transmission.

[0091] An exemplary communications system may perform scheduling and / or scheduling-related operations based on QoS requirements. A network scheduler alone cannot enforce all types of QoS requirements for all types of data at all times. For example, a network-based scheduling function may not have timely information and / or accurate knowledge of QoS requirements associated with data applicable to uplink transmissions in a WTRU's buffer. A WTRU may be configured to enable services with stringent reliability and / or delay requirements (e.g., these behaviors enable a WTRU to receive URLLC services). A WTRU may influence how / which data it transmits (through further parameters). For example, a WTRU may be configured with one or more parameters associated with a characterization regarding how data is transmitted. The characterization may represent constraints and / or requirements that the WTRU is expected to meet and / or enforce when transmitting data. Based on the characterization, the WTRU may perform different operations and / or adjust its behavior, for example, based on (e.g., depending on) the status and / or characteristics of the data.

[0092] The example communications systems described herein may include one or more of the following time-related QoS requirements (e.g., time-related characteristics): These time-related QoS requirements may be useful, for example, when a network scheduler is unable to enforce timing / delay requirements alone (e.g., for at least a subset of the data applicable to the transmission). A WTRU may be configured to transmit data associated with one or more particular time-related QoS requirements. In response to these time-related QoS requirements, the WTRU may vary one or more operational aspects of a given transmission scheme used to transmit the data. For example, if the WTRU is near the end of a transmission using a first transmission scheme without successfully transmitting the data (e.g., without satisfying one or more time-based QoS requirements), the WTRU may vary one or more operational aspects of the first transmission scheme and switch to a second transmission scheme in order to attempt a successful data transmission before the time-based QoS requirements expire.

[0093] The time-based QoS requirements described herein may include a maximum time allowed for realizing one or more aspects of a data transmission (e.g., an uplink data transmission). The WTRU may determine whether such maximum time has been reached or exceeded based on observation and / or estimation. The time-based QoS requirements may include a maximum amount of time allowed for acquiring resources suitable for data transmission. The WTRU may determine the time associated with acquiring suitable resources by monitoring a control channel. For example, the WTRU may determine such time in response to a grant received over the control channel, in response to parameters signaled on the control channel, and / or the like. The WTRU may determine the time associated with acquiring suitable resources by monitoring a SOM associated with resource acquisition. The WTRU may determine the time associated with acquiring suitable resources by monitoring one or more states of the WTRU. Such states may include, for example, whether the WTRU is synchronized or asynchronous, whether a scheduling request is in progress, or the like.

[0094] Time-based QoS requirements may include a maximum time that data may remain in a WTRU's transmit buffer. The WTRU may be configured to determine such maximum time based on the timing of the first transmission of the data. For example, the WTRU may 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 entered the transmit buffer until the first transmission of the data begins.

[0095] Time-based QoS requirements may include a maximum amount of time for a data transmission to reach a HARQ operating point. As an example, with the xth transmission of a PDU containing associated data, the time for the WTRU to reach a HARQ operating point may be determined as the time it takes the WTRU to perform xth-1 retransmission of the PDU.

[0096] The time-based QoS requirements may include a maximum amount of time allowed to successfully complete a data transmission or to receive feedback for the transmission of a PDU containing data. The WTRU may determine such time based on when the WTRU receives HARQ feedback, such as a HARQ ACK, for the corresponding transport block.

[0097] Time-based QoS requirements may include a maximum value for a time-to-live (TTL) parameter associated with the data. Such a TTL parameter may be associated, for example, with the transmission of a data packet or any other action taken by the WTRU with respect to the data packet. For example, the WTRU may maintain (or be configured with) a TTL parameter having a certain threshold (e.g., N milliseconds) associated with the transmission of a data packet. The WTRU may monitor the elapsed time since the data packet became available for transmission (e.g., after the WTRU received the data packet in its buffer). If the threshold is reached without successfully transmitting the data packet, the WTRU may determine that the TTL has expired. The WTRU may take different actions based on the amount of TTL remaining. For example, the WTRU may switch to a different transmission scheme when it determines that the TTL has reached a threshold.

[0098] Time-based QoS requirements may include, for example, a maximum amount of time that a logical grouping of data can be completed based on a radio bearer. Time-based QoS requirements may include a maximum amount of time that a worst-case or head-of-queue delay can be tolerated. The WTRU may be configured to determine such a delay based, for example, on the data that spends the longest time in the WTRU's buffer.

[0099] Time-based QoS requirements may include an average time or a punctual time associated with one or more aspects of a data transmission. The WTRU may determine such an average time or a punctual time based on observation and / or estimation. For example, the time-based QoS requirements may include an average amount of time data may remain in the WTRU's transmit buffer (associated with the same logical channel, group, and / or SOM). The WTRU may be configured to determine such an average time based, for example, on the time period between when the data becomes available for transmission and when the data is transmitted. The WTRU may determine the time when such data becomes available for transmission based on when it initiates a procedure to request and / or acquire transmission resources and / or when it signals the result. The WTRU may determine the time when such data is transmitted based, for example, on when it first transmits the data or when it receives an ACK for the transmission of the data. The averages referred to herein may be a moving average (e.g., within a window of a particular length), an average per burst associated with the data, an average since the WTRU last requested resources for such data, or an average since the WTRU first obtained resources for the transmission of such data.

[0100] Time-based QoS requirements may include an allowable variation from an average time. The variation may correspond, for example, to a decrease or increase relative to the average. Using the buffer time mentioned above as an example, the timing requirement may ensure that the amount of time data can remain in the WTRU's transmit buffer can exceed the average time by only a certain amount.

[0101] The time-based QoS requirements may include an average time or a precise time by which the data in the WTRU's buffer can be reduced. For example, such an average time or precise time may be associated with reducing the amount of data in the WTRU's buffer to a certain level (e.g., the level may be configurable). The level may correspond to other time-related characteristics described herein, such as the maximum time allowed to successfully complete a transmission. The WTRU may determine such an average time based on estimation or observation.

[0102] The time-based QoS requirements may include a worst-case delay or an average or exact time for head-of-queue delay. The WTRU may be configured to determine such an average or exact time based on multiple occurrences of the worst-case delay.

[0103] Time-based QoS requirements may include average or exact times at which logical groupings of data (eg, based on radio bearers and / or the like) can be performed.

[0104] The time-based QoS requirements may be related to an HARQ entity, an HARQ process type, and / or an ongoing HARQ process.

[0105] The WTRU may determine that a transmission of an uplink data unit (e.g., an uplink data packet) has QoS requirements. The QoS requirements may be time-related QoS requirements associated with one or more aspects of the uplink transmission, as described herein. The WTRU may attempt to transmit the uplink data unit using a first transmission scheme. The WTRU may determine, for example, whether the QoS requirements can be met using the first transmission scheme for at least a subset of data available for transmission. For example, based on the QoS requirements, the WTRU may determine that a TTL parameter that the WTRU maintains for the uplink data unit should not exceed a certain threshold. The TTL parameter may, for example, 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 may monitor the TTL parameter, and if it determines that the TTL has reached the threshold before the uplink data unit can be successfully transmitted using the first transmission scheme, the WTRU may select a second transmission scheme to transmit the uplink data unit. The second transmission scheme may differ from the first transmission scheme in at least one operational aspect, as described in more detail herein.

[0106] The example communications systems described herein may include one or more of the following transmission rate-related requirements (e.g., transmission rate-related characteristics): As described herein, a network scheduler may not always be able to enforce transmission rate-related requirements by itself (e.g., for at least a subset of data available for transmission at a WTRU). The WTRU may be configured with a grouping of data to be associated with a transmission rate-related requirement. Such a grouping may include a logical association between data packets and / or PDUs, such as an LCH, an LCG, an association of data with a SOM and / or one or more aspects thereof, an association of data with a radio bearer, and / or the like. For example, the WTRU may be configured with a transmission rate for such data (e.g., a prioritized bit rate, etc.). The WTRU may use the transmission rate to determine how much data to include in a transmission (e.g., by performing a logical channel prioritization operation). The transmission rate-related requirement may be associated with a HARQ entity, an HARQ process type, and / or an ongoing HARQ process. The WTRU may observe and / or estimate (e.g., using similar metrics as described herein for timing-related aspects) the rate of transmission for at least a subset of the data. The WTRU may determine whether it can meet the relevant transmission rate-related requirements and may take different actions based on the determination (e.g., switching to a different transmission scheme, etc.).

[0107] For illustrative purposes, a WTRU may attempt to transmit an uplink data unit using a first transmission scheme. The WTRU may determine whether transmission rate-related requirements, or more generally, QoS requirements associated with the uplink transmission, can be met using the first transmission scheme (e.g., for at least a subset of the data). If the WTRU determines that the transmission rate-related requirements cannot be met using the first transmission scheme, the WTRU may decide to switch to a second transmission scheme to meet the relevant transmission rate-related requirements. The second transmission scheme may differ from the first transmission scheme in at least one operational aspect, as described in more detail herein.

[0108] Example communications systems described herein may include one or more of the following configuration-related requirements (e.g., configuration-related characteristics, etc.): For example, a WTRU may be configured to give certain data a transmission priority (e.g., absolute priority) that supersedes one or more other QoS requirements. In an example, a WTRU may be configured by higher layers to transmit packets with the highest priority, regardless of other timing-, rate-, or efficiency-related QoS requirements, for example.

[0109] The example communications systems described herein may enable and / or permit other WTRU behaviors including, for example, random access to TRPs, control channel modification and / or monitoring, authorization and / or transmission parameter selection, SR method selection, and / or the like.

[0110] As described herein, a WTRU may be configured to determine that one or more QoS requirements associated with a transmission (e.g., an uplink transmission) may not be met. Such QoS requirements may, for example, be timing- and / or rate-related (e.g., as described herein). Failure to meet a QoS requirement may result in, for example, a change in applicable procedures, a change in the transmission scheme, and / or a change to other transmission-related behavior. For example, the WTRU may attempt an uplink transmission using a first transmission scheme. The WTRU may determine whether a QoS requirement, such as a timing-related or transmission rate-related requirement described herein, is met using the first transmission scheme (e.g., for at least a subset of data available for transmission). If the WTRU determines that a QoS requirement cannot be met using the first transmission scheme, the WTRU may adjust its operation to meet the QoS requirement. For example, the WTRU may autonomously adjust the transmission scheme used for the transmission. The adjustment, which may include an increase, change, or decrease in the resources used for transmission, may result in changing one or more operating aspects of the transmission scheme (e.g., changing one or more transmission parameters).

[0111] When changing the transmission scheme, the WTRU's connection to the network may be affected / changed. Thus, the connection type may be an example of an operational aspect that may change between different transmission schemes. For example, changing the connection type may cause the WTRU to initiate an access procedure with the network and / or request a reconfiguration procedure (e.g., L3 reconfiguration). In an example, the WTRU may initiate an RRC procedure requesting a reconfiguration of its connection. The request may include one or more of the following: The request may include an identification of the applicable logical data grouping (e.g., LCH, LCG, SOM, and / or the like). The request may include information related to the QoS aspect that triggered the request for a change in the connection (e.g., amount, rate, or timing of resource adjustment for improvement, etc.). The request may include information related to the data to be transmitted (e.g., head of queue delay or average delay, outstanding data, etc.). The WTRU may include measurements in the request.

[0112] The WTRU may initiate TRP access and / or random access. For example, the WTRU may initiate access to the system to increase the amount of available resources, change the type of resources, modify the amount of associated TRPs, and / or the like. The WTRU may determine (from measurements of reference signals such as signatures) that one or more TRPs are within range of the WTRU. The WTRU may determine appropriate random access resources (e.g., using information contained in an access table). The WTRU may initiate transmission of a preamble on such resources. The above operations should result in a different set of resources applicable to the WTRU (e.g., resources may increase or decrease, and / or there may be a different set of control channels to monitor). For example, the WTRU may initiate an increase in the set of available resources, which may result in more physical layer resources, more carriers, additional TRPs, and / or aggregation of a Uu interface with a network entity (the network entity may include an eNB and / or TRP, the interface may be via dual connectivity or similar techniques, etc.).

[0113] When changing transmission schemes, the WTRU may expand or modify the identity and / or number of control channels that it is monitoring. Thus, the set of one or more control channels monitored by the WTRU may be an example of an operational aspect that may change for different transmission modes. For example, the WTRU may determine that different and / or additional control channels are available for scheduling transmissions. The WTRU may request and / or activate these control channels. The WTRU may make that decision following transmission of a signal (e.g., to the network). The signal may indicate a request to activate such control channels. In an example, the WTRU may make the decision in a similar manner as it performs access to the system (but for the same signature and / or cell). The WTRU may switch and / or add control channels. For example, the WTRU may switch to and / or add control channels associated with a different SOM (e.g., the control channels may be associated with different physical layer resources, different physical data channels, and / or different computational schemes).

[0114] When changing the transmission scheme, the WTRU may expand and / or modify the available resources. Thus, the set of available resources may be an example of an operational aspect that may change for different transmission modes. The WTRU may determine that a different set of resources is available. The WTRU may switch to a different set of DCIs and / or DCI types. For example, the WTRU may determine that it can attempt to decode a different set of DCIs on the control channel. Such DCIs may be associated with a different SOM, a different calculation scheme, a different set of PRBs, and / or the like. The WTRU may update its control channel monitoring behavior (e.g., update DRX). For example, the WTRU may change its monitoring frequency or intensity for the control channel (e.g., to begin decoding more vigorously). The WTRU may enter an active mode for the control channel if more resources are desired. The WTRU may select a scheme for scheduling requests based on (e.g., in response to) QoS requirements. For example, the WTRU may select a particular scheme for obtaining transmission resources based on (e.g., in response to) QoS requirements associated with the data to be transmitted. If the WTRU determines that the applicable QoS requirements for the data can be met, the WTRU may use a contention-based transmission scheme. If the WTRU determines that the applicable QoS requirements for the data cannot be met, the WTRU may use a dedicated SR resource for transmission. If the WTRU determines that multiple resources and / or requested scheduling schemes are available, the WTRU may select the requested scheduling scheme and / or resources associated with the SOM if that scheme and / or resource can perform a transmission that meets the applicable transmission requirements.

[0115] When changing the transmission scheme, the WTRU may modify and / or select a particular transmission parameter or grant. Thus, the transmission parameters and / or grants may be examples of operational aspects that may change for different transmission modes. For example, the WTRU may determine that a different set of transmission parameters is applicable and / or usable for the data transmission. The WTRU may select a grant from among multiple grants such that one or more characteristics of the data transmission may be modified. Such characteristics may include reliability, HARQ operating point, diversity applied to the transmission, transmit power, etc.

[0116] When changing the transmission scheme, the WTRU may modify the multiplexing, assembly, and / or segmentation techniques and / or rules associated with the data transmission. Thus, multiplexing, assembly, and segmentation may be examples of operational aspects that may change for different transmission modes. For example, the WTRU may change the multiplexing rules, assembly and / or segmentation rules, and / or the like when creating a MAC PDU for transmission of data. For example, the WTRU may skip packet segmentation at the MAC layer when processing data for which QoS requirements may not be met.

[0117] The WTRU may be configured to maintain and / or react to delay-related characteristics or criteria (e.g., time-related QoS requirements) for a first subset of data but not a second subset of data. The first subset of data may be associated with a first logical channel, a first flow, a first service, a first data type, and / or the like. The second subset of data may be associated with a second logical channel, a second flow, a second service, a second data type, and / or the like. In an example, a rate-related criterion may be associated with a particular set of one or more logical channels but not with other logical channels. In an example, QoS requirements may be provided with packets in any logical channel or flow from a higher layer. The QoS requirements may be provided as needed.

[0118] When changing the transmission scheme, the WTRU may provide the network with information associated with the uplink data that the WTRU intends to transmit. For example, the WTRU may transmit information related to QoS. The WTRU may transmit the information related to QoS along with the associated data packet, SDU, and / or byte collection (e.g., in a MAC PDU). For example, the WTRU may transmit a TTL along with the associated packet, SDU, and / or byte collection. The TTL (or absolute time) may be expressed in units of time (e.g., milliseconds). The TTL may account for at least a significant portion of the absolute time (e.g., to allow a receiver to determine what the absolute time is).

[0119] The QoS-related information can be attached to the associated data. The receiving entity of the data with which the QoS-related information is sent can be a network node (e.g., a base station) or the receiving WTRU. The receiving entity can be involved in data operations such as relaying and / or forwarding, such as, for example, an eNB configured to enable V2V communication (e.g., by forwarding the UL transmission directly to the destination). The receiving entity can use the QoS-related information to decide how to process the received data. The receiving entity (e.g., a base station) can determine and / or modify the best or preferred route, resources, TTI, SOM, and / or the like associated with transmitting 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 enforcement of resource reception priority (e.g., in the presence of RF or baseband limitations). The receiving entity can modify the resources, RAT, and / or mechanism (e.g., SC-PTM vs. unicast vs. eMBMS) used to relay the received data. The receiving entity can select a path for the relevant cell or network to forward the data, for example, the receiving entity can determine whether the data should come to an application server in the network or whether the data should be sent to a proxy application service located in the cell or TRP.

[0120] Time-related requirements (e.g., delay-related, etc.) may have various representations in the WTRU. The WTRU may use the time-based requirements as criteria for determining when the WTRU should switch from a first transmission scheme to a second transmission scheme. For example, the WTRU may maintain delay requirements. The WTRU may obtain transmission delay requirements, for example, from higher layers. The WTRU may use such requirements, for example, to make scheduling decisions and / or resource usage decisions, to guide aspects related to resource requesting, to perform multiplexing / demultiplexing, and / or to control transmission. For example, the WTRU may maintain and / or monitor a TTL parameter, which may represent the time elapsed from the reception of a data packet until the successful transmission of the data packet. The WTRU may utilize the TTL parameter during the transmission phase (e.g., at each transmission phase) to adjust behaviors, procedures, and / or the like to meet the time-related QoS requirements. The WTRU may maintain TTLs for packets, SDUs, collections of bytes, and / or the like. The TTL may relate to the amount of time allotted for a successful transmission over the air interface.

[0121] The WTRU may take certain actions (e.g., within its transmit stack) to change its behavior when the TTL reaches a certain value or exceeds a certain range. For example, the WTRU MAC may decide to initiate autonomous transmission using one or more of the techniques described herein (e.g., using contention-based resources) when the TTL associated with a MAC PDU reaches a certain threshold.

[0122] The MAC may decide to utilize one HARQ instead of another, one TTI instead of another, one transport channel instead of another, and / or one coding rate instead of another, for example, when the TTL associated with a MAC PDU reaches a certain threshold. Thus, TTI length, transport channel identification, coding rate, etc. may be examples of operational aspects that may change when the WTRU changes transmission schemes. The WTRU may decide to trigger a specific request for resources from the network (e.g., in a specific SOM) or to issue such a request using a different mechanism when the TTL reaches a certain threshold.

[0123] It should be noted that the concept of TTL as used herein is not limited to any one particular definition. For example, the concept of TTL can encompass any mechanism for defining and representing one or more QoS requirements. Thus, although some examples may be described with respect to using TTL to determine when to switch transmission schemes and / or change transmission parameters, other information indicative of one or more QoS requirements may also be used as criteria for determining when to switch transmission schemes and / or change transmission parameters.

[0124] The example communication systems described herein can be characterized by at least functionality related to requesting, determining, and accessing appropriate transmission resources. For example, these functions can relate to scheduling and / or determining one or more applicable control channels (e.g., SOM-specific control channels).

[0125] The example communication systems described herein can be characterized by specific mechanisms for requesting network access (e.g., access to appropriate resources) to meet specific QoS requirements (e.g., time-related QoS requirements). In one example embodiment, a WTRU can send a resource request (RR) to the network. The RR can include a request for new or modified resources and / or indicate buffer status. The RR can include a request for a connection change to the network. The RR can include a request for a resource change. The RR can include a request for a control channel to be monitored or configured. The RR can include a request for a TRP change. The RR can include a request for a SOM change. The RR can include a request for other aspect changes described herein.

[0126] The RR may indicate parameters related to QoS and / or provide an indication of failure or possible failure to meet QoS requirements. To satisfy QoS-related requests, different resource request mechanisms and / or formats may be defined and used for different services, logical channels, logical channel groups, and / or QoS groups. The type of RR may be determined based on one or more QoS parameters reaching a certain threshold. The RR may be sent based on one or more QoS parameters reaching a certain threshold (e.g., TTL reaching a threshold).

[0127] A RR may be characterized by the type of transport format used, the type of resource on which the RR is transmitted, the information provided in the RR, the TTI length used for RR transmission, the SOM, and / or the like. The WTRU may determine which RR to use based on one or more QoS characteristics.

[0128] Information transmitted in an RR may include, for example, a request for resources, a request for modification of allocated resources, an indication of buffer status, and / or an indication of the inability or possible inability to meet certain QoS requirements. An RR may include an indication of intent to transmit on upcoming resources and / or on resources that the RR plans to use. An RR may include an indication that resources are being requested to meet certain QoS requirements associated with the data for which the RR was triggered. In some examples, such an indication may be the only information provided in an RR. In other examples, more information may be provided in an RR, such as information about the transmission and / or the transmitting WTRU.

[0129] In the RR, the WTRU can identify one or more of the particular service, SOM, and / or LCG to which the RR applies. In an example, the indication included in the RR can signal a request to allocate more resources for the SOM / transport channel on which the RR is being transmitted (e.g., assuming separate physical resources are used for different SOMs / transport channels). The WTRU can transmit multiple RRs in a single SOM (e.g., one for resources associated with each SOM). An RR (e.g., each of multiple RRs) can signal a request for resources associated with a different SOM. The association between the RR and the SOM on which the RR is being sent can be based on a tag (e.g., a tag may be included in the RR), based on resources used (e.g., bit position in time and / or frequency), based on other physical characteristics of the RR transmission (e.g., transmit power / energy, modulation scheme, etc.), based on the format of the RR, based on the size of the RR, based on the timing of the RR (e.g., when the RR is sent by the WTRU), and / or the like.

[0130] The indication in the RR may have a fixed value. For example, the indication may take one of two possible values ​​(e.g., a 1-bit value). The indication may take the first value if, for at least one PDU, the expected time for successful completion of transmission exceeds the current time plus the PDU's TTL. Otherwise, the indication may take the second value. In another example, the indication in the RR may take one of four possible values ​​(e.g., a 2-bit value). For each PDU, the WTRU may determine the difference between the expected time of successful completion and the sum of the current time and the PDU's TTL. The WTRU may set the value of the indication based on the highest such difference across all transmitted PDUs. The indication can be set to a first value if the difference exceeds a first threshold, a second value if the difference exceeds a second threshold (but does not exceed the first threshold), a third value if the difference exceeds a third threshold (but does not exceed the second threshold), and a fourth value otherwise. The threshold values ​​can be predefined or signaled by higher layers. Increasing the number of possible values ​​for the indication can allow for faster or more accurate adjustment of allocated resources.

[0131] The indication in the RR may have a fixed value. For example, the indication may take one of two possible values ​​(e.g., a 1-bit value). The indication may take a first value if, for at least one PDU, the expected time for successful completion of transmission exceeds the current time plus the PDU's TTL. Otherwise, the indication may take a second value. In another example, the indication in the RR may take one of four possible values ​​(e.g., a 2-bit value). For each PDU, the WTRU may determine the difference between the expected time of successful completion and the sum of the current time and the PDU's TTL. The WTRU may set the value of the indication based on the highest such difference across all transmitted PDUs. The indication may be set to a first value if the difference exceeds a first threshold, a second value if the difference exceeds a second threshold (but does not exceed the first threshold), a third value if the difference exceeds a third threshold (but does not exceed the second threshold), and a fourth value otherwise. The threshold value may be predefined or signaled by a higher layer. Increasing the number of possible values ​​for the indication may allow for faster or more accurate adjustment of allocated resources.

[0132] In some options, or for some RR types, the RR may include information derived from QoS-related scheduling information, as described herein. For example, the WTRU may transmit delay-related or any QoS-related information to the receiving node. The information may be transmitted in the RR, in a MAC PDU, or in an RRC signaling message. The information may be used by the network to, for example, schedule resources and / or prioritize among different WTRUs needing resources. The information that may be included in the RR (e.g., by the WTRU) may take or correspond to one or more of the following forms:

[0133] The WTRU may include information associated with the TTL in the RR. For example, the WTRU may include the minimum TTL for packets, PDUs, or TTLs currently in the WTRU's queue for transmission. The WTRU may maintain multiple transmission queues with tight delay constraints. The WTRU may transmit the TTL for the head of each of the multiple transmission queues.

[0134] The WTRU may include information associated with buffer sizes in the RR. For example, the WTRU may include buffer sizes for data configured with TTL requirements, buffer sizes for data that may be multiplexed for the service that triggered the request, or all buffer sizes for data at the WTRU (e.g., along with their associated priorities and / or requirements).

[0135] The WTRU may include information in the RR associated with timing ranges for particular packets, PDUs, etc., and / or their respective buffer sizes. For example, the WTRU may transmit minimum and maximum values ​​for an acceptable delay range for a PDU or set of data.

[0136] The WTRU may include in the RR information associated with an absolute time for transmitting / receiving a packet or amount of data over the air, or an absolute time range for an acceptable delay. The WTRU may include in the RR information associated with a QoS class or absolute priority of the data, rate-related information, and / or an expected time to successfully complete transmission of at least one PDU (e.g., with currently allocated resources). The expected time may then depend on one or more of the following: The expected time may depend on an expected time that a PDU may be included in a transport block originally submitted to the physical layer under a given set of prioritization rules. The expected time may depend on an expected time for a retransmission. One or more of the parameters described herein may be set to predefined values ​​or signaled by higher layers.

[0137] The WTRU may include information in the RR associated with a particular TTI (e.g., 2 symbols, or 0.5 ms) that the WTRU may use for resources, 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 may be located (e.g., in a particular narrow bandwidth supported by the WTRU or preferred by the WTRU due to its radio characteristics).

[0138] The WTRU may indicate (e.g., implicitly indicate) information related to a particular RR by selecting resources, timing, encoding, power, and / or the like associated with transmission on PHY resources. For example, the WTRU may indicate the amount of additional resources to be allocated to the WTRU based on the time / frequency resources used to transmit the RR. The information related to the RR may be indicated by the format and / or transport mechanism used in the RR transmission. The RR may be transmitted, for example, at the PHY layer (e.g., on a specific PHY control channel or piggybacked with data) and / or at the MAC layer (e.g., using MAC CE and / or the like). The RR may be transmitted entirely at the PHY layer. If transmitted at the PHY layer, the RR may be transmitted via one or more of the following:

[0139] The RR may be transmitted using a single OFDM symbol associated with the WTRU's uplink transmission (e.g., at a predefined or configured location) or using a single symbol in one of the resource blocks. In an example, the RR may be transmitted in the last symbol (e.g., the last symbol in time) of the OFDM subcarrier with the highest index. The RR may be transmitted using an uplink control channel or as part of the WTRU's autonomous scheduling information, which may be transmitted on the uplink control channel.

[0140] The RR may be transmitted using a dedicated PHY resource, the location of which may be provided to the WTRU via signaling in the network (e.g., RRC signaling) or may be obtained by information contained in an access table sent to the WTRU. The RR may be transmitted using (e.g., in conjunction with) identification or timing related information (e.g., to derive the location of the PHY resource).

[0141] The RR can be transmitted using contention-based resources, such as RACH or similar signaling. The contention-based resources can be spread over PHY resources utilized by other WTRUs to minimize overall interference with these WTRUs (e.g., using CDMA or puncturing to use only a few interfered resource elements associated with a particular WTRU). For the example of LTE-assisted 5Gflex strict interconnection, the WTRU can be configured to transmit the RR over the LTE PUCCH. The PUCCH SR is extended to carry information that the request is related to QoS characteristics that can be satisfied by the 5G system. More specifically, the SR can indicate that the WTRU is requesting 5G resources. This can be enabled, for example, by modifying the SR format to include additional bits, by reserving special resources where the SR-triggered 5G request is sent, and / or the like.

[0142] A WTRU may have access to multiple sets of resources or mechanisms for transmitting an RR. For example, for different services, an RR may be defined with different characteristics including, for example, a different format or type, a different value of the time to transmit (e.g., the time from triggering the request over the air to transmitting), a different symbol, a different signaling mechanism, a different transport format, and / or the like. The WTRU may be able to select from these different mechanisms based on one or more of the following: The WTRU may select a mechanism for transmitting an RR based on the delay characteristics of the queued data or data to be transmitted (e.g., the data may be delay-constrained or not). The WTRU may select a mechanism for transmitting an RR based on the TTL of one or more packets or data to be sent (e.g., the TTL may or may not be relative to a threshold). The WTRU may select a mechanism for transmitting an RR based on the priority of the data or service type. The WTRU may select a mechanism for transmitting an RR based on one or more QoS requirements (e.g., time-based or rate-based QoS requirements) described herein. For example, the WTRU may send RRs for services (e.g., ULLRC or eMBB) in the PHY using different TTIs depending, for example, on the time criticality, priority, and / or timing requirements of the data in the buffer for which the RR is sent / triggered.

[0143] The RR for a SOM (e.g., for each SOM), a given service, or a logical channel may have different characteristics related to how the RR is transmitted at the PHY layer. In an example, the RR may be transmitted over different transport channels with different coding schemes, using different TTIs and diversity / reliability, using dedicated (e.g., shared / contention-based) resources, and / or other mechanisms / techniques. A WTRU may utilize different RR mechanisms depending on the SOM or the included services. For example, a WTRU configured with ULL services may request resources for the ULL service using a 1-bit PHY layer RR mechanism, but the WTRU may use MAC layer RR if the buffer status for the RR at the PHY layer indicates a request for an IBB-type service.

[0144] The WTRU may trigger an RR based on one or more of the following: The WTRU may trigger an RR based on a QoS requirement (e.g., a QoS-related event) as described herein. For example, the WTRU may trigger an RR based on a delay-related event. Such a delay-related event may include, for example, the arrival of a time-critical packet at the MAC layer or higher layers. The WTRU may trigger an RR based on the TTL of one or more packets or data dropping below a threshold. The WTRU may trigger an RR based on the initiation, configuration, or reconfiguration of a service, TRP, logical channel, SOM, and / or the like at the WTRU. The WTRU may trigger an RR based on the arrival of a packet having a different QoS class than the ongoing transmission. The WTRU may trigger an RR based on data not meeting rate-related QoS requirements, and / or the like.

[0145] The WTRU may trigger an RR based on one or more of the following: The WTRU may trigger an RR based on an indication from the application layer. The WTRU may trigger an RR based on the periodic expiration of a timer. The WTRU may trigger an RR based on an indication that a buffer is no longer empty (or other buffer occupancy information). The WTRU may trigger an RR based on one or more HARQ entities indicating that a retransmission should be performed upon recovery from sleep, DRX, and / or the like. The WTRU may trigger an RR based on service initiation, configuration, or reconfiguration. The WTRU may trigger an RR based on the creation of a logical channel (e.g., a logical channel requiring low-latency communication). The WTRU may trigger an RR based on the WTRU attaching to the network. Regarding recent example triggering events, if the network is an LTE-supported network and new data arrives with requirements that cannot be met by the LTE service, the WTRU may trigger a 5G Flex RR.

[0146] The WTRU may trigger an RR for a service or logical channel while a data transmission on resources serving another service or another logical channel is ongoing or has started. In this scenario, the WTRU may perform one or more of the following actions, for example, based on a priority determination, resource amount, and / or data amount to send (in absolute terms or based on the current QoS characteristics for each service): The WTRU may add RR information to the ongoing data transmission, or the WTRU may delay transmitting the RR until the ongoing data transmission is complete. However, for time-sensitive transmissions, the RR delay may not occur if the WTRU delays transmitting the RR or if the added information is decoded by the network at the end of the TTI. The WTRU may immediately send the RR to the network. The WTRU may avoid transmitting the RR and use resource prioritization to accommodate the new service that triggered the RR using existing resources.

[0147] For illustrative purposes, a WTRU may have an ongoing web browsing session and may have resources available for transmission. If the WTRU then receives data with less stringent QoS requirements (e.g., time-related QoS requirements), the WTRU may transmit resource request information along with the data (e.g., using a MAC PDU or incorporating RR into the PHY layer). If the received data has stringent QoS requirements or if delay requirements are not met, the WTRU may trigger transmission of an RR using RR characteristics associated with the service (e.g., the RR characteristics used for transmitting the RR may implicitly indicate the service to which the RR applies; the RR characteristics may reflect a calculation scheme, timing, resources, transmission technique, and / or the like). In such a case, the WTRU may transmit the RR in parallel with the ongoing data transmission (e.g., on different resources), or the WTRU may delay transmitting the data and transmit the RR. For example, if data arrives in the middle of an ongoing transmission and an RR is triggered, the WTRU may transmit the data on the first available resource (e.g., transmit immediately). If the next available resource occurs on the air interface at a time later than the time for transmitting the corresponding RR, the WTRU may transmit the RR during an ongoing transmission. Mechanisms are described herein for transmitting RRs while a long TTI transmission is in progress and / or while RR-specific resources are limited or unavailable.

[0148] In the example communication system described herein, a WTRU may obtain access to resources through a grant from the network. Whether or not the WTRU uses the granted resources may be an example of an operational aspect that may change when the WTRU switches transmission schemes. The WTRU may receive one or more of the following in the grant: The WTRU may receive information (e.g., an indication) regarding resources the WTRU can access. The resources may be specified, for example, as preconfigured resource indexes or may be explicitly signaled in the grant. The WTRU may receive information regarding the SOM or transport channels for which the grant is valid. For example, the information may indicate the calculation schemes, TTIs, and / or waveforms that the WTRU can use. The WTRU may receive information regarding logical channels, service types, priorities, and / or the like that the WTRU can use for a given grant. The information may include identifiers or values ​​commonly understood between the WTRU and the network. The WTRU may receive information regarding the transport format of the grant (e.g., MCS, block size, start time, etc.). The WTRU may receive information regarding the TTI length. The WTRU may receive information regarding the validity of the grant. For example, the information may indicate the TTI or range of TTIs that the WTRU can use for the grant, the duration, etc. The WTRU may receive information regarding the range of logical channels, priorities, and / or services that can be used with or excluded from the grant. The range may be above or below a certain priority value (e.g., it may be indicated by the network in the grant).

[0149] The WTRU may prioritize the transmission of logical channels. Such prioritization of logical channel transmissions may be an example of an operational aspect that may change when the WTRU switches transmission schemes. For example, the WTRU may use a grant to transmit logical channels (e.g., any logical channel) that have priority values ​​less than, greater than, or within a certain range (e.g., from a minimum value to a maximum value) signaled in the grant. Within the range of allowable priority values, the WTRU may exclude certain priority levels.

[0150] The WTRU may be configured to prioritize the use of granted resources. The prioritization of granted resources among various services may be an example of an operational aspect that may change when the WTRU switches transmission schemes. For example, the priority range of 5G services may include 10 different priority levels associated with the scheduling and use of granted resources, with level 10 being the highest priority that may be associated with a ULLC service type. The WTRU may be configured to reserve resources first for higher priority services (e.g., when these higher priority services have data to transmit). For example, the WTRU may receive a grant assigned to priority level 5. Thus, the WTRU may be configured to utilize the grant (e.g., resources associated with the grant) for transport blocks tagged with a priority level of 5 or greater, or for the transport block with the highest priority if the highest priority is less than 5. Upon receiving an indication of a grant from the PHY layer, the MAC layer may select a packet in its transmit buffer with a priority level of 5 or greater, or with the highest priority if the highest priority is less than 5, and may send the packet to the PHY layer for transmission.

[0151] The WTRU may be configured to bind resource prioritization to a particular type of resource at the PHY layer. Binding resource prioritization to a resource type may be an example of an operational aspect that may change when the WTRU switches transmission schemes. For example, the WTRU may be configured to use a particular SOM only for logical channels of a particular priority. Illustratively, the WTRU may receive a grant assigned to a priority level of 5. The WTRU may be configured to utilize the grant (e.g., resources associated with the grant) for transport blocks tagged with a priority level of 5 or less. Thus, the WTRU may be prevented from utilizing resources associated with grants for higher priority data (e.g., data having a priority level greater than 5) because these resources may not be configured to accommodate data of a higher priority level (e.g., in terms of reliability or timeliness).

[0152] The WTRU may be configured to exclude certain priority levels from the range of priority levels for which it can use granted resources. Excluding certain priority levels may be an example of an operational aspect that may change when the WTRU switches transmission schemes. The particular levels that may be excluded by the WTRU may be defined by a specification or may be signaled to the WTRU. For example, priority level 10 may be excluded because that level may be associated with (e.g., always associated with) the highest form of ultra-low latency communication and therefore may require special types of resources that may be granted separately (e.g., by indicating a special priority level or by a different mechanism).

[0153] A WTRU may be configured to autonomously access resources (e.g., pre-configured resources). Autonomous access of resources may be an example of an operational aspect that may change when a WTRU switches transmission schemes. A WTRU may be pre-configured with a set of transmissions that the WTRU can perform autonomously. Such a capability may be desirable, for example, in IoT applications, industrial applications, vehicular communications, and / or the like. In one or more of these scenarios, a WTRU may move from a state with few or no uplink transmissions for an extended period of time to a state with regular (e.g., periodic) transmissions with very low latency. To initiate regular transmissions with low latency, the WTRU may be configured with a set of pre-configured resources. The WTRU may transmit data with certain QoS requirements using one or more of these pre-configured resources. For example, a WTRU may be configured with resources for the UL, DL, sidelink, etc. Such a configuration would not necessarily have to reserve resources for the WTRU, but may indicate to the WTRU which resources are available for the WTRU to use if needed.

[0154] Pre-configured resources may include a static configuration of one or more overlapping or non-overlapping time-frequency resources. The resources may last for a finite period of time and / or may exist with a certain periodicity. For example, one pre-configured resource may include a single resource block located in a particular frame or subframe number. Upon registering and / or connecting to the network, a WTRU may receive or request modifications to the pre-configured resources via dedicated signaling from the network (e.g., similar to RRC signaling), via 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, logical channels, and / or the like for which such pre-configured resources may be required.

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

[0156] Upon sending a request (e.g., an RR as described herein), the WTRU may begin monitoring one or more control channels associated with the service or QoS class that triggered the request. For example, if a low-latency data transmission is requested, the WTRU may begin monitoring one or more control channels associated with the low-latency service or the corresponding SOM. The WTRU may receive a timely confirmation (e.g., in a manner similar to that described herein). The WTRU may receive a response from the network after sending a short uplink transmission as described herein. From the response, the WTRU may receive one or both of the following: information related to the index and / or timing that may be in the short uplink transmission, or an acknowledgment for the use of resources. For example, the WTRU may make a short UL transmission indicating a request for resources for a particular service or SOM. The network may respond with an index to the pre-configured resources. Depending on the pre-configuration conditions and / or the requested service type, the pre-configured resources may be used for at least one transmission.

[0157] The WTRU may be provided with pre-configured resources in the downlink (DL). For example, the provisioning may be done using a response mechanism described herein (e.g., the provisioning may be included in a response from the network). The WTRU may disable the pre-configured resources (e.g., similar to how the pre-configured resources may be enabled). For example, the WTRU may disable (e.g., implicitly) the pre-configured resource transmission by sending an RR, e.g., when the amount of delay-bounded data in the buffer is below a threshold. The request for the pre-configured resources and / or their availability / availability are examples of operational aspects that may change when the WTRU switches transmission schemes.

[0158] The WTRU may, for example, perform autonomous uplink transmissions using available resources not necessarily allocated to the WTRU. For such transmissions, the WTRU may enable the use of pre-configured resources and / or may indicate to the network that such resources are being utilized by the WTRU. Additionally or alternatively, the WTRU may perform uplink transmissions on a low-latency uplink control channel or via low-latency data transmissions (e.g., including short TTIs) assigned to the WTRU or dedicated to one or more WTRUs. Autonomous uplink transmissions are an example of an operational aspect that the WTRU may change when switching transmission schemes.

[0159] The WTRU may perform UL transmissions to enable pre-configured resources via MAC CE or other similar control messages via resources scheduled for uplink transmission. The WTRU may perform the foregoing instead of sending UL transmissions autonomously. Using scheduled resources to enable pre-configured resources may be an example of an operational aspect that may change when the WTRU switches transmission schemes.

[0160] The WTRU may send a request for pre-configured resources or an indication to use pre-configured resources via any suitable technique described herein. For example, the WTRU may send the request or indication in a manner similar to sending an RR. For example, the WTRU may enable pre-configured resources via an RR (e.g., based on the contents of the RR). The WTRU may explicitly enable pre-configured resources, for example, by sending an RR to indicate a desired resource configuration. The WTRU may implicitly enable pre-configured resources, for example, by including QoS-related parameters in the RR, which may be interpreted as an automatic request for a particular type of resource configuration. The WTRU may be enabled to use pre-configured resources implicitly upon the transmission of an RR containing certain trigger conditions. Such conditions may be part of the initial pre-configuration of the pre-configured resources themselves. For example, the WTRU may be configured to utilize pre-configured resources upon the transmission of an RR indicating an amount of delay-bound data above a certain threshold.

[0161] A WTRU may be configured to perform the uplink transmissions described herein using one or more of the following mechanisms: The WTRU may be configured to perform the uplink transmissions using a short PHY layer signal reserved for one or more WTRUs to signal to the network. The WTRU may be configured to perform the uplink transmissions using a CDMA-like signal or a punctured signal sent over a channel shared among multiple WTRUs. The WTRU may be configured to perform the uplink transmissions using a RACH-like uplink transmission performed at a specific, well-defined time instance. The WTRU may be configured to perform the uplink transmission with an initial transmission on one of the resources associated with the preconfigured resources. Network transmissions in the downlink (e.g., which may include an ACK or indication) may be performed using a low-latency control channel, a data channel with a short TTI, or another suitable DL channel.

[0162] A WTRU may be allocated resources for transmitting data for one or more services. The WTRU may dynamically schedule (e.g., by self-scheduling) data transmissions using all or a subset of the allocated resources. The allocated resources may be constrained within one or more specific windows in the time domain (e.g., such time windows may have a duration from a few milliseconds to several milliseconds). In some embodiments, the one or more time windows may repeat periodically (e.g., substantially periodically). The allocated resources may be constrained within a certain range in the frequency domain. The range of frequencies may vary over time (e.g., to provide frequency diversity). The allocated resources may be used by at least one uplink physical channel (UPCH) over which the WTRU may transmit data and control information. The allocated resources may be used by one or more sidelink physical channels (SPCH). Resources may be allocated based on service type (e.g., for each type of service), such that some resources may be reserved for a particular type of service.

[0163] The WTRU may be allocated resources to transmit scheduling information (SI), other uplink control information (UCI), and / or sidelink control information (SCI). These may include, for example, HARQ-ACK and / or CSI feedback. Note that discussions herein regarding SI are applicable to resource requests (RRs) (e.g., RRs may be considered a type of SI and may be referred to interchangeably with SIs; e.g., examples discussed with respect to SIs are also applicable to RRs, and vice versa). Similarly, discussions herein regarding RRs are applicable to SIs. For example, while the foregoing discusses resource allocation for transmitting SIs, those skilled in the art will understand that the mechanisms are also applicable to transmitting RRs. The resources allocated for transmitting SIs and / or other UCIs / SCIs may be part of a block of resources allocated for self-scheduling operations or may be allocated separately. In some embodiments, resources may be made available for transmitting data, and transmission of SI and / or other UCI / SCI may occur on a particular physical control channel (e.g., an uplink or sidelink physical control channel). SI and / or other UCI / SCI may be encoded and multiplexed (e.g., in-band) on the uplink or sidelink physical channel (e.g., along with data).

[0164] Resource allocation for transmission of SI and / or other UCI / SCI may be configured to occur at regular intervals, such as every shortest applicable TTI, to provide frequent opportunities for transmission. The resources used for transmitting a single instance of SI may occupy the entire frequency domain range of the allocation. In this manner, the number of time symbols configured to transmit one instance of SI may be reduced (e.g., minimized). SI may be encoded together with other UCI / SCI. SI and / or other UCI / SCI may be encoded separately and multiplexed (e.g., concatenated) before modulation, layer mapping, and / or resource element mapping. The coding rate, coding scheme, and / or modulation may be determined using one or more of the techniques described herein.

[0165] The WTRU may transmit information regarding parameters associated with the transmission of the SI and / or UCI / SCI. Such information may help a receiving node, such as a network node or another WTRU, decode the SI and / or UCI / SCI. For example, the WTRU may specify the number of information bits, the modulation and coding scheme, and / or resource information (e.g., the number of time symbols) associated with the SI and / or other UCI / SCI. Such information may be encoded separately from the SI and / or UCI / SCI and / or may be mapped to a known portion of the allocated resources. The WTRU may include an indication of whether the next time symbol contains SI and / or UCI / SCI (e.g., for each time symbol containing SI and / or UCI / SCI).

[0166] A WTRU may transmit data in one or more TTIs. The WTRU may transmit data to one or more services, one or more logical or transport channels, and / or one or more receiving devices (e.g., a network node or another WTRU). The WTRU may include information associated with the data in an SI (e.g., an instance of an SI) to aid one or more receiving devices in decoding the data. The instance of an SI may be transmitted prior to data transmission in one or more TTIs. The transmission of the SI may be performed according to a fixed timing relationship.

[0167] The WTRU may indicate in the SI whether a transmission of data is occurring within the TTI. For example, the SI may indicate one or more of the following regarding the TTI or regarding the applicable type of transmission within the TTI: The SI may indicate whether data is being transmitted within the TTI. The SI may indicate the type of data, service, or logical channel included in the transmission. The SI may include a timing indication of the TTI (e.g., the number of time units from the SI instance, etc.). The SI may indicate the duration of the TTI. The SI may indicate an identifier for the WTRU (e.g., the RNTI, etc.). The SI may include an indication of a destination node (e.g., a network node (TRP), another WTRU, etc.). The SI may indicate a cyclic redundancy check (CRC), such as a CRC combined with or masked with another field, such as the WTRU's identifier. The SI may indicate the number of codewords. The SI may indicate power-related information (e.g., power headroom, etc.). The SI may indicate scheduling requests and / or buffer status reports, HARQ-ACK or CSI feedback, and / or other control information such as transmit power control commands.

[0168] The WTRU may indicate in the SI a description of how information is transmitted relative to the codeword. The description may then include one or more of the following: The description may include the transport channel type. The description may include the coding type, such as convolutional or turbo. The description may include the modulation and coding scheme (MCS). The description may include HARQ information, such as new data indication (NDI), process identification, and / or retransmission sequence number. The description may include frequency / time allocation within the allocated resources or within the TTI. The description may include spatial processing information, such as transmit diversity or spatial multiplexing scheme, and / or number of transmission layers. The description may include antenna port and / or reference signal information.

[0169] The WTRU may use a single field to convey or indicate multiple ones of the parameters described herein, e.g., to reduce overhead. For example, the field may indicate a combination of MCS and coding type or transport channel type. The mapping between the combination value and the value of the corresponding parameter may be predefined or configured by higher layers. The WTRU may use one or more of the following techniques to schedule a transmission and / or set parameters for the transmission:

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

[0171] Available resources may be divided in the frequency domain. The WTRU may allocate an amount of frequency resources as needed to high-priority data and use the remaining resources to transmit lower-priority data. The WTRU may determine the frequency allocation for transmissions (e.g., for each transmission) according to a predefined rule. For example, the WTRU may allocate either the highest or lowest frequency first. The allocation may be based on frequency-selective channel quality feedback from the receiving device and / or based on the priority of the transmission. The WTRU may allocate frequency portions with higher channel quality to higher-priority transmissions first. For example, the WTRU may have received an indication from a network node that a first portion of a frequency range allocated for self-scheduling operation has higher quality than a second portion. In such a case, the WTRU may perform the higher-priority transmissions using at least the first portion of the frequency range.

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

[0173] The WTRU may select a transmit power, MCS, and / or spatial transmission scheme according to one or more adaptation principles. For example, the WTRU may configure and reconfigure (e.g., adjust) its transmit power. Such transmit power may be expressed, for example, as a ratio of a maximum transmit power. The WTRU may configure and reconfigure (e.g., adjust) its transmit power based on physical layer signaling, higher layer signaling, or a combination thereof. To aid in its configuration and reconfiguration (e.g., adjustment), the WTRU may transmit a reference signal at a configured power level or using a power level signaled by the network. The WTRU may use the same transmit power for one or more resource blocks (e.g., for each resource block). The transmit power may be configured on a resource block basis, such that the total transmit power may depend on the number of resource blocks over which transmissions occur.

[0174] The WTRU may receive an indication of an MCS and / or coding type to use for a particular data type. For example, the WTRU may receive an indication of a first coding type (e.g., convolutional coding), a first modulation and coding scheme (e.g., QPSK and rate ⅓), and / or a first spatial transmission scheme (e.g., transmit diversity such as SFBC) to use for a first type of service (e.g., URLLC). The WTRU may receive an indication of a second coding type (e.g., turbo), a second modulation and coding scheme (e.g., 16-QAM and rate ½), and / or a second spatial transmission scheme (e.g., rank-2 spatial multiplexing) to use for a second type of service (e.g., eMBB).

[0175] The WTRU may select an MCS and / or coding type depending on channel quality feedback from the receiving device and / or depending on the type of data to be transmitted. For example, for a given value of channel quality feedback from the receiving device, the WTRU may 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 first type of service (e.g., URLLC). The WTRU may select a second coding type, a second modulation and coding scheme, and / or a second spatial transmission scheme if the data to be transmitted corresponds to a second type of service (e.g., eMBB). The mapping between channel quality feedback values ​​and MSCs and / or coding types to use for a particular type of service may be configured by higher layers.

[0176] The WTRU may receive an indication of the channel quality, MCS, and / or code type via physical layer signaling. For example, the indication may be signaled in downlink control information along with other parameters allocating resources for self-scheduling operations. The indication may be signaled regularly (e.g., at intervals that may be on the order of several TTIs).

[0177] The WTRU can adjust its selection of MCS, transmission scheme, and / or transmit power based on a dynamic indication applicable to the TTI. The WTRU can receive such an indication from the network via physical layer signaling. For example, the WTRU can select a more conservative MCS level and / or transmission scheme if the indication is set to a first value, and can apply a less conservative MCS and / or transmission scheme if the indication is set to a second value. Using the indication, the network can adjust the robustness of the transmission based on, for example, whether another WTRU is expected to use the same resources in that TTI (e.g., in the case of multi-user MIMO). Using the indication, the network can increase the robustness of the transmission after a certain number of HARQ retransmissions. The WTRU can map various indications to MCS / transmission scheme combinations. The MCS and transmission scheme combinations can be ranked from least conservative to most conservative. For example, the WTRU may store such rankings in a table and may map the indication to an offset that links to one or more entries in the table. The offset may be configured by higher layers and / or may depend on the service type or transport channel.

[0178] The WTRU may adjust its selection of MCS, coding type, and / or transmit power based on the number of retransmissions performed, the delay since the initial data transmission, and / or the TTL of the data. For example, the WTRU may apply a more conservative MCS level and / or transmission scheme when the TTL of the data carried by the transmission falls below a threshold. The adjustment may include an offset applied to the MCS and / or transmission scheme table. The adjustment may allocate a larger portion of the allocated resources to the transmission, but may increase the robustness of the transmission and the likelihood of successful completion. The WTRU may increase the transmit power by the offset when the TTL of the data falls below a threshold.

[0179] A WTRU may be configured to transmit to multiple receiving devices (e.g., using multiple MAC instances and / or at the same time). In an 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 an example, the first MAC instance may correspond to a transmission to a network node, and the second MAC instance may correspond to a transmission to another WTRU. The MCS and / or coding type applicable to the transmissions (e.g., for each transmission) may depend on channel quality feedback and / or other indications provided by the receiving device.

[0180] Resources may be configured for self-scheduling operation. For one or more types of services (e.g., for each type of service), 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, etc.). 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, etc.). Resources for self-scheduling may include parameters for link adaptation (e.g., transmit power, offsets for adjusting further power, MCS, and / or transmission scheme, etc.). Resources for self-scheduling may be configured by higher layers or by a combination of physical layer signaling and higher layer signaling. For example, the WTRU may receive a field that may be mapped to a set of parameters associated with the configuration of resources for self-scheduling, such as via downlink control signaling from a physical control channel. Such mapping may be configured by higher layers.

[0181] A WTRU may have access to resources dedicated to a particular type of service (e.g., URLLC, etc.). Such resources may be common to (e.g., shared by) multiple WTRUs. Multiple WTRUs may transmit URLLC data (at least occasionally). Dedicated resources may include specific time / frequency resources, such as specific resource blocks or subcarriers. Resources may be used for a given set of frames or subframes, or over a long period of time. A WTRU may determine the resources dedicated to a particular service (e.g., for URLLC) based on, for example, broadcast or dedicated signaling by the network, or by an access table.

[0182] The WTRU may transmit autonomously on dedicated PHY resources. For example, the WTRU may be configured to do so if dedicated PHY resources are reserved for the WTRU (e.g., only for that WTRU). The WTRU may receive an ACK from the network via a low-latency downlink control channel. For example, the ACK may be sent via the control channel. The ACK may be sent in the same subframe as the indication and / or by using a shortened TTI. The ACK may include an indication of which resources to use. The ACK may be sent via dedicated symbols in a certain time-frequency space (e.g., a time-frequency space may be reserved for this specific purpose). For example, a set of symbols may be reserved for the WTRU (e.g., each WTRU) to receive downlink ACKs. Such symbols may serve other purposes (e.g., the symbols may serve as reference symbols), for example, on subframes or TTIs where the WTRU does not expect a response from an indication.

[0183] The WTRU may be configured with resources at the PHY layer that can be used (e.g., specifically reserved) to transmit with a shortened TTI. For example, specific time / frequency resources (e.g., x resource blocks for each y frames) may be reserved for the WTRU for shortened TTI transmission (e.g., 2 OFDM symbols). The WTRU may determine the resources reserved for the shortened TTI using one or more of the following example techniques: The resources may be statically defined for the WTRU. The resources may be signaled by the network via dedicated signaling or in an access table. The resources may be defined / created (e.g., implicitly) based on the WTRU's device type, based on the service type, and / or based on the type of traffic currently managed by the WTRU. The WTRU may be configured to autonomously select resources.

[0184] Some types of transmissions can be prioritized relative to others. Figure 5 shows an example of prioritized transmissions. Such transmission prioritization can be applied to various use cases, including URLLC transmissions, differentiated QoS eMBB transmissions, non-multiplexed URLLC transmissions, and / or the like. Transmission prioritization can be achieved, for example, based on one or more of the following: Transmission prioritization can be achieved through differentiated requests; Transmission prioritization can be achieved through transport channel selection; Transmission prioritization can be achieved through high priority HARQ and / or reassociation of transmission resources to different transport channels. Prioritized transmissions can indicate and / or utilize a particular calculation scheme. A prioritized transmission can include a PDU configured with a maximum time allowed for successful completion of the transmission (e.g., for URLLC transmissions or differentiated QoS eMBB transmissions). A prioritized transmission can include a PDU associated with a particular logical channel (e.g., for non-multiplexed URLLC transmissions).

[0185] As described herein, an example communication system may support low-latency communications. A WTRU may be configured at the MAC / PHY layer to transmit low-latency packets immediately or with a processing delay (e.g., the smallest possible delay). A WTRU may be configured to delay transmissions already in progress, canceled transmissions, and / or terminated transmissions to give priority to low-latency packets. In an example scheme for prioritizing low-latency communications, a WTRU attempting to perform a scheduled uplink transmission may autonomously decide to delay the scheduled transmission to utilize resources allocated to the scheduled transmission and transmit or retransmit a transmission with low-latency requirements.

[0186] Examples of transmissions that may be delayed by the WTRU may include dynamically scheduled uplink transmissions, semi-persistent transmissions, or static uplink granted transmissions, scheduled retransmissions, and / or the like. In an example, a WTRU with multiple ongoing HARQ processes may suspend one of the HARQ processes to allow for transmission of low-latency data. In an example, the WTRU may suspend a transport block or transmission to be retransmitted and perform an initial transmission of the transport block or data with low-latency requirements utilizing the resources intended for the retransmission. In an example, the WTRU may receive a grant associated with a particular priority transmission, logical channel, and / or service, and the WTRU may determine to transmit a low-latency packet utilizing the resources intended for the granted transmission. For example, the low-latency packet may reach 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 for a non-low-latency transmission for which resources are currently reserved and for a different service, priority, or logical channel for which the WTRU intends to use the resources instead. The indication may be transmitted using the formats and / or techniques described herein.

[0187] When the WTRU determines to delay a transmission, such as a non-low-latency transmission, it may send an indication to the network that the transmission has been delayed in favor of another transmission (e.g., a low-latency transmission). The indication may indicate that a grant or resource allocation has been overwritten. 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 the new data. The indication may indicate resources, locations, and / or procedures that can be used to retransmit the delayed data. The indication may be provided in the UCI / SCI, SI, and / or RR described herein. The indication may include the type of data being delayed or to be transmitted. For example, the WTRU may indicate that the transmission is a low-latency transmission and should be processed accordingly. The WTRU may indicate the transport format (e.g., MCS, coding, etc.) of the data being transmitted and / or the PHY layer parameters (e.g., TTI parameters) used to transmit the data over the same resources. Upon receiving the indication, the network may suspend HARQ processing for the particular HARQ process that was interrupted. The network may resume the HARQ process after the transmission of the low latency transport block has been successfully completed.

[0188] Prioritizing a new transmission (e.g., a low-latency transmission) over the original transmission may cause the WTRU to utilize the same modulation and / or coding technique for the new transmission as intended for the original transmission. Alternatively, the WTRU may select a new TTI, modulation and / or coding technique for the new transmission, allowing the WTRU to transmit the new transmission within the same resources or within a portion of the same resources.

[0189] The WTRU may send the above-mentioned indication to the network using a subset of resources allocated to the WTRU. For example, the WTRU may send the indication in a transport block, a set of resource elements, or a set of subcarriers. The subset of resources may be predefined for such purposes. For illustration, the WTRU may send the indication using the first N subcarriers of the first transport block. The WTRU may further transmit a predefined sequence to signal the presence of the indication to the network. Such a technique allows the network to first decode the dedicated resource elements to determine the presence of the predefined sequence, the abort indication, physical layer parameters, and / or the like.

[0190] Additionally or alternatively, the WTRU may send the above-mentioned indication on a separate control channel, such as the control channel used for UL low-latency control communications. The WTRU may send the indication on a different set of resources with a shortened TTI. The network may be configured to blindly decode the information transmitted by the WTRU. The WTRU may use the UCI / SCI, UL control channel, SI, or RR to convey new scheduling information and / or indicate new HARQ information, new physical layer parameters, a new SOM, and / or a new TTI. The WTRU may transmit the relevant information and / or select the relevant parameters using one or more of the techniques described herein.

[0191] The WTRU may be configured to transmit RR, SI, and / or low-latency data while another transmission is in progress. If RR is triggered while another transmission is in progress, the WTRU may transmit the RR in the middle of the ongoing transmission. Within a TTI, some symbols and / or resources may be reserved for transmitting RR for time-critical data. The WTRU may transmit RR and / or SI using CDMA-like signaling. The WTRU may puncture the time-critical data and embed an RR request in the data signal or channel. The receiving entity of the data may receive notification that the data has been punctured.

[0192] When a data transmission is interrupted by RR and / or time-critical data, some bits (e.g., all bits following the interruption) may be dropped. The WTRU may incorporate information into the signaling to indicate to the receiving entity that the data from the previous transmission has been dropped and a new transmission has started, or that RR / SI is being sent. The WTRU may notify the receiving entity (e.g., the network) that the data (all data following the interruption) has been dropped. To process time-critical data, the WTRU may drop packets from its transmit buffer or drop packets received from higher layers before they are processed by the RAN. The WTRU may be configured to drop packets at any layer. For example, a packet may be dropped when it is received from higher layers. As another example, a particular layer in the WTRU may drop SDUs received by the WTRU from higher layers.

[0193] When dropping a packet, the WTRU may perform one or more actions. The WTRU may readjust the sequence numbering so that the dropped packet and / or SDU does not occupy a particular sequence number. The WTRU may send a particular indication (e.g., a MAC CE or similar control message) along with the transmission to provide an indication of the dropped packet to the network. Exemplary conditions under which a packet may be dropped include one or more of the following: The WTRU may drop a packet or SDU when it arrives later than its expected delivery time. For example, the expected delivery time may have already expired when the packet or SDU arrives. The WTRU may drop a packet or SDU if the expected processing time (e.g., as expected by the current layer and / or lower layers) of the packet or SDU causes the expected delivery time of the packet or SDU to expire prior to transmission. The WTRU may drop a packet or SDU when the packet or SDU is associated with a logical channel, flow, and / or service that allows packet dropping. The associated logical channel, flow, and / or service may be configured at initiation to allow packet dropping. The WTRU may drop a packet or SDU when it is multiplexed with other packets that have time-sensitive delay requirements, and when the packet or SDU itself does not have time-sensitive delay requirements.

[0194] The WTRU may be configured to send an indication to a lower layer, a higher layer, or an application layer that a packet has been dropped. For example, the WTRU may be configured to send an indication to the PHY layer to increase the amount of resources available for transmission. For example, the WTRU may be configured to notify the application layer regarding possible incorrect operation.

[0195] The example communication system described herein may utilize several MAC CE or MAC layer control messages for MAC layer control signaling. One example of such a message may be associated with a TRP modification, including, for example, a TRP handover, switching, addition, activation, and / or deactivation. The network may be configured to send such a message to instruct a WTRU to move from Tx / Rx on one TRP to Tx / Rx on another TRP. The message may instruct the WTRU to initiate 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 alignment. The WTRU may be configured with the target TRP configuration in advance and may receive an index and / or subset of the configuration for accessing the TRP.

[0196] Another exemplary MAC CE or MAC layer control message may be associated with a TRP connection request. A WTRU may be configured to send such a request to request a connection to a particular TRP. The message may include a WTRU identity, a list of logical channels and / or services, a reason for the connection request, and / or the like.

[0197] Another exemplary MAC CE or MAC layer control message may be associated with a TRP measurement list (e.g., the message may include the TRP measurement list). The network may be configured to provide the WTRU with a list of TRPs that the WTRU should measure. For example, the WTRU may be instructed to measure DL quality associated with the list of TRPs. The network may be configured to provide the WTRU with a list of TRPs that the WTRU should measure positioning reference signals (PRSs) for (e.g., to determine the WTRU's location). The network may be configured to provide the WTRU with a list of TRPs that the WTRU should maintain UL timing alignment for at a given time. A message including a TRP measurement list may include one or more of the following fields: a message type, a list of TRP identifications (e.g., an index or similar identifier for each TRP), and / or a threshold value associated with the TRP (e.g., for every TRP). In an example, information associated with the TRP measurement list may be provided as part of the RR and / or SI information.

[0198] Another exemplary MAC CE or MAC layer control message may be associated with cross-TRP scheduling configuration. The network may be configured to send such a message to the WTRU, for example, to configure a semi-static cross-TRP scheduling configuration. The message may include one or more of the following fields: source TRP identification, target / destination TRP identification, and / or resource mapping between source and destination resources.

[0199] Another exemplary MAC CE or MAC layer control message may be associated with the location of the TRP. The network may be configured to send such a message to the WTRU providing the locations of TRPs in the WTRU's vicinity. The message may include one or more of the following fields: identification of the TRPs in the WTRU's vicinity, a system signature used by the TRPs, and / or the locations of the TRPs.

[0200] Another exemplary MAC CE or MAC layer control message may be associated with a timing alignment request. The WTRU may be configured to send such a message to the network to request the network to provide UL timing alignment to the WTRU and / or to initiate a timing alignment procedure. The message may include one or more of the following fields: a request to enable / disable timing alignment, and a SOM for which timing alignment is requested.

[0201] Another exemplary MAC CE or MAC layer control message can be associated with improved timing advance. The message can include one or more of the following fields: identifiers of TRPs, timing offsets associated with each TRP, timing offsets associated with each SOM, and / or indications of allowed / not allowed techniques for uplink timing alignment.

[0202] Another exemplary MAC CE or MAC layer control message can be associated with an improved buffer status report. The message can include one or more of the following: a logical channel ID or logical channel group ID, the number of bytes in the queue, the priority of the data, a QoS class, one or more pieces of information associated with the RR, a transport channel type, the number of bytes in the queue with a TTL lower than a first threshold, and / or the number of bytes in the queue with a TTL above a threshold but below a second threshold. Different MAC CEs can be defined for different RR types. The MAC CE can include a header indicating which RR type the MAC CE corresponds to.

[0203] Another exemplary MAC CE or MAC layer control message may be associated with the dropped packet indication. Such a message may be sent by the WTRU to the network or by the network to the WTRU to inform an SDU ordering entity in the WTRU or network scheduler of the dropped packet in 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 (e.g., or the index of the range of dropped packets).

[0204] Another exemplary MAC CE or MAC layer control message may be associated with SPS configuration. The network may send such a message to the WTRU to configure and / or reconfigure semi-persistently scheduled resources (which may be pre-configured) at the WTRU. The message may include one or more of the following fields: resource identification (e.g., time, frequency, duration, periodicity, etc.), usage limits, an identifier for the resource or an identifier for a collection of resources (e.g., several resources may be configured), and / or a SOM associated with the resource or collection of resources.

[0205] Another exemplary MAC CE or MAC layer control message may be associated with enabling or disabling SPS resources. The WTRU may be configured to send such a message to the network to enable or disable a pre-configured SPS resource or collection of SPS resources. The message may include one or more of the following fields: an indication to enable or disable SPS and / or an identifier for the resource or collection of resources.

[0206] Another example MAC CE or MAC layer control message may be associated with a resource request, a resource increase or decrease, and / or a resource indication. The WTRU may be configured to send such a message to the network to indicate a request for a particular type of resource (e.g., short TTI resources), to request an increase or decrease in the amount of such allocated resources over time, and / or to indicate to the network that the WTRU is currently utilizing or intends to utilize a particular resource. The message may include one or more of the following fields: message type, SOM identification, increase / decrease amount, amount of resource requested, and / or type of resource and / or limit.

[0207] Another exemplary MAC CE or MAC layer control message may be associated with connection reconfiguration. The network may send such a message to the WTRU to configure it to reconfigure a particular connection to the TRP. The message may include one or more of the following (e.g., for each SOM connected to the TRP): a new radio configuration, a resource configuration, a power configuration, a timer configuration, and / or the like.

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

Claims

1. 1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory, the processor and the memory comprising: determining latency information associated with one or more packets; determining that a remaining time to live of at least a first packet of the one or more packets is less than a threshold; transmitting a Medium Access Control (MAC) Control Element (CE) based on determining that a remaining time to live of the at least first packet is less than a threshold, the MAC CE including an indication of a remaining time to live of the at least first packet; and a WTRU configured to perform

2. The WTRU of claim 1 , wherein the latency information comprises a total time-to-live of the one or more packets.

3. The WTRU of claim 1 , wherein the MAC CE includes an indication of a logical channel group associated with the first packet.

4. The WTRU of claim 1 , wherein the MAC CE corresponds to a resource request (RR).

5. The WTRU of claim 2 , wherein the total time-to-live of the one or more packets corresponds to a maximum time that the one or more packets are maintained in a buffer of the WTRU.

6. The WTRU of claim 1 , wherein the MAC CE includes an indication of buffer status information associated with the one or more packets.

7. The WTRU of claim 1 , wherein the remaining time to live is determined based on when the first packet becomes available for transmission.

8. The processor and memory receiving an uplink grant, the uplink grant being associated with a priority; determining that a priority associated with a logical channel of the first packet matches a priority associated with the uplink grant; transmitting the first packet using the uplink grant based on determining that a priority associated with a logical channel of the first packet matches a priority associated with the uplink grant; The WTRU of claim 1 configured to perform:

9. The WTRU of claim 6 , wherein the buffer status information includes information indicating an amount of data associated with the one or more packets having a remaining time to live less than the threshold.

10. The WTRU of claim 1 , wherein the processor and memory are configured to receive information indicative of a value of the threshold.

11. 1. A method performed by a wireless transmit / receive unit (WTRU), comprising: determining latency information associated with one or more packets; determining that a remaining time to live of at least a first packet of the one or more packets is less than a threshold; transmitting a Medium Access Control (MAC) Control Element (CE) based on determining that a remaining time to live of the at least first packet is less than a threshold, the MAC CE including an indication of a remaining time to live of the at least first packet; and A method comprising:

12. The method of claim 11 , wherein the latency information comprises a total time-to-live of the one or more packets.

13. The method of claim 11 , wherein the MAC CE includes an indication of a logical channel group associated with the first packet.

14. The method of claim 11 , wherein the MAC CE corresponds to a resource request (RR).

15. The method of claim 12 , wherein the total time-to-live of the one or more packets corresponds to a maximum time that the one or more packets are maintained in a buffer of a WTRU.

16. The method of claim 11 , wherein the MAC CE includes an indication of buffer status information associated with the one or more packets.

17. The method of claim 11 , wherein the remaining time to live is determined based on when the first packet becomes available for transmission.

18. receiving an uplink grant, the uplink grant being associated with a priority; determining that a priority associated with a logical channel of the first packet matches a priority associated with the uplink grant; transmitting the first packet using the uplink grant based on determining that a priority associated with a logical channel of the first packet matches a priority associated with the uplink grant; The method of claim 11 further comprising:

19. The method of claim 16 , wherein the buffer status information includes information indicative of an amount of data associated with the one or more packets having a remaining time to live that is less than the threshold.

20. The method of claim 11 , further comprising receiving information indicative of a value of the threshold.

Images