Apparatus, system, method, and computer-readable medium for performing control to handle inter-UE prioritization for NR V2X

Abstract

An electronic device configured to schedule transmission of data to at least one other electronic device via sidelink resources in a wireless communication network; identify that the transmission of the scheduled data is preempted by another transmission occurring within at least a portion of the sidelink resources; and control the transmission of the data to the at least one other electronic device based on the identification.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 825,374, filed on March 28, 2019, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to wireless communications, and more particularly to wireless communications systems, devices, methods, and computer-readable media having computer-executable instructions for executing control to handle: inter-UE collisions between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low latency or high priority downlink (DL) or uplink (UL) transmissions, or inter-UE collisions between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low latency or high priority sidelink transmissions, or inter-UE prioritization for New Radio (NR) Vehicle-to-Everything (V2X) communications. Background Art

[0004] The "background" description provided herein is intended to generally present the context of the present disclosure. To the extent described in this background section, the work of the presently named inventors, as well as aspects of the description that may not constitute prior art at the time of filing this application, are not admitted, either explicitly or implicitly, to be prior art against the present invention.

[0005] For New Radio (NR) Vehicle-to-Everything (V2X) Mode 1 shared carrier scenarios, the gNB can use dynamic scheduling, Type 1 Configuration Grant (CG), or Type 2 Configuration Grant (CG) to allocate sidelink transmissions on a shared carrier with downlink (DL) and / or uplink (UL) transmissions over the Uu interface. For example, the gNB may schedule a very low-latency or high-priority DL data transmission over the Uu interface for a UE, which may overlap with a sidelink transmission already scheduled or configured for another UE. In this case, both transmissions may be degraded or even fail. Therefore, mechanisms are disclosed herein for handling inter-UE contention between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low-latency or high-priority DL or UL transmissions.

[0006] For NR V2X Mode 1, the gNB can use dynamic scheduling, Type 1 configuration grants, or Type 2 configuration grants to allocate sidelink transmissions. For example, the gNB may schedule a very low-latency or high-priority data transmission on the sidelink for a UE, which may overlap with a sidelink transmission already scheduled or configured for another UE. In this case, both transmissions may be degraded or even fail. Therefore, mechanisms are disclosed herein for handling inter-UE conflicts between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low-latency or high-priority sidelink transmissions. Summary of the Invention

[0007] The present disclosure relates generally to wireless communications, and more particularly to wireless communication systems, devices, methods, and computer-readable media having computer-executable instructions for executing control to handle: inter-user equipment (UE) conflicts between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low latency or high priority downlink (DL) or uplink (UL) transmissions, or inter-UE conflicts between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low latency or high priority sidelink transmissions, or inter-UE prioritization for New Radio (NR) Vehicle-to-Everything (V2X) communications.

[0008] This Summary is provided to introduce in simplified form some of the concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages mentioned in any section of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The scope of the present disclosure may be better understood from the following detailed description of example embodiments when read in conjunction with the accompanying drawings, in which:

[0010] Figure 1A is a system diagram illustrating an example 3GPP architecture;

[0011] Figure 1B is a system diagram of an example apparatus or device configured for wireless communication;

[0012] Figure 1C is a system diagram illustrating examples of a radio access network (RAN) architecture and a core network architecture;

[0013] Figure 1D is a system diagram showing examples of a radio access network (RAN) architecture and a core network architecture;

[0014] Figure 1Eis a system diagram illustrating examples of a radio access network (RAN) architecture and a core network architecture;

[0015] Figure 1F is a system diagram illustrating an example of a computing system for use in a communication network;

[0016] Figure 1G is a system diagram illustrating an example 3GPP architecture;

[0017] Figure 2 shows sidelink transmissions preempted by dynamically scheduled Uu transmissions according to an exemplary embodiment;

[0018] Figure 3 It is shown that a UE according to an exemplary embodiment detects an explicit preemption indication and performs a retransmission;

[0019] Figure 4 UE detection of signaling jointly indicating explicit preemption indication and retransmission scheduling according to an exemplary embodiment is shown;

[0020] Figure 5 1. It shows that a UE detects an implicit preemption indication via a retransmission scheduling DCI according to an exemplary embodiment;

[0021] Figure 6 A method for detecting preemption of Uu transmissions and retransmitting a broadcast signal on a sidelink according to an exemplary embodiment is shown;

[0022] Figure 7 shows a joint indication of power reduction and retransmission for a preempted sidelink according to an exemplary embodiment;

[0023] Figure 8 shows separate indications of power reduction and retransmission for preempted sidelink transmissions according to an exemplary embodiment;

[0024] Figure 9 A method for detecting a power reduction indicator for a broadcast sidelink UE having an inter-UE collision with a scheduled Uu transmission according to an exemplary embodiment is shown;

[0025] Figure 10 A method of detecting a cancelling indication for a broadcast sidelink UE having an inter-UE conflict with a scheduled Uu transmission according to an exemplary embodiment is shown;

[0026] Figure 11 A method according to an exemplary embodiment is shown for a transmitting UE to detect preemption by a unicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0027] Figure 12 A process is shown according to an exemplary embodiment for a receiving UE to detect preemption by a unicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0028] Figure 13 A method according to an exemplary embodiment is shown for a transmitting UE to detect a power reduction indicator of a unicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0029] Figure 14 A process is shown according to an exemplary embodiment for a receiving UE to detect a power reduction indicator of a unicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0030] Figure 15 A method according to an exemplary embodiment is shown for a transmitting UE to detect a cancellation indication of a unicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0031] Figure 16 A process is shown according to an exemplary embodiment for a receiving UE to detect a cancellation indication of a unicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0032] Figure 17 A method according to an exemplary embodiment is shown for a transmitting UE to detect preemption by a multicast side link UE that has an inter-UE conflict with a scheduled Uu transmission;

[0033] Figure 18 A process is shown according to an exemplary embodiment for a receiving UE to detect preemption of a multicast sidelink UE that has an inter-UE conflict with a scheduled Uu transmission;

[0034] Figure 19 A method according to an exemplary embodiment is shown for a transmitting UE to detect a power reduction indicator of a multicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0035] Figure 20A process is shown according to an exemplary embodiment for a receiving UE to detect a power reduction indicator of a multicast sidelink UE that has an inter-UE collision with a scheduled Uu transmission;

[0036] Figure 21 A process is shown according to an exemplary embodiment for a transmitting UE to detect a cancellation indication from a multicast sidelink UE that has an inter-UE conflict with a scheduled Uu transmission;

[0037] Figure 22 A process is shown according to an exemplary embodiment for a receiving UE to detect a cancellation indication of a multicast side link UE that has an inter-UE conflict with a scheduled Uu transmission;

[0038] Figure 23 A procedure for cancelling an indicator for a UE having a configured grant side link that has an inter-UE conflict with a scheduled Uu transmission is shown;

[0039] Figure 24 A process for detecting a cancellation indicator for a UE having a configured grant side link that has an inter-UE conflict with a scheduled Uu transmission is shown;

[0040] Figure 25 An alternative procedure for detecting preemption of a UE with a configured grant side link that has an inter-UE conflict with a scheduled Uu transmission is shown;

[0041] Figure 26 An example of a sidelink transmission with 3 repetitions scheduled by a gNB in NR V2X Mode 1 is shown;

[0042] Figure 27 An example of a sidelink transmission being preempted during a repetition is shown;

[0043] Figure 28 An example of a sidelink transmission with a first-stage SCI and a second-stage SCI sent simultaneously is shown;

[0044] Figure 29 An inter-UE collision between two dynamically scheduled sidelink transmissions is shown;

[0045] Figure 30 An inter-UE conflict between dynamically scheduled sidelink transmissions and sidelink based on configured grants is shown.

[0046] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of example embodiments is for illustration only and is therefore not necessarily intended to limit the scope of the present disclosure. DETAILED DESCRIPTION

[0047] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities—including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced, and New Radio (NR), also known as "5G." Development of the 3GPP NR standard is expected to continue and include the definition of next-generation radio access technologies (New RATs), which are expected to include new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backwards-compatible radio access in new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include centimeter wave (cmWave) and millimeter wave (mmWave) spectrum, which will provide opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0048] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and any of vehicle-to-other-entities communications. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car eCall, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, the tactile internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases, and others, are contemplated herein.

[0049] The following is a list of acronyms related to service levels and core network technologies that may appear in the following descriptions. Unless otherwise noted, acronyms used in this article refer to the corresponding terms listed below.

[0050] LIST OF ABBREVIATIONS

[0051]

[0052]

[0053] Example Communication Systems and Networks

[0054] Figure 1A An example communication system 100 is shown in which the systems, methods, and apparatus described and claimed herein may be employed. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, generally or collectively referred to as one or more WTRUs 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, a V2X server, V2X functions, a ProSe server, ProSe functions, IoT services, video streaming, and / or edge computing.

[0055] It should be appreciated that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 1A In the example of Figures 1A-1E , depicted as a handheld wireless communication device. It will be appreciated that for the various use cases contemplated for wireless communication, each WTRU may comprise or be included in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device such as a smartwatch or smart clothing, a medical or e-health device, a robot, an industrial device, a drone, a vehicle such as a car, bus, or truck, a train, or an airplane, etc.

[0056] The communication system 100 may also include a base station 114a and a base station 114b. Figure 1AIn the example shown, each base station 114a and 114b is depicted as a single element. In practice, the base stations 114a and 114b may include any number of interconnected base stations and / or network elements. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. Similarly, the base station 114b may be any type of device configured to interface with remote radio heads (RRHs) 118a, 118b, transmission and reception points (TRPs) 119a, 119b, and / or roadside units (RSUs) 120a and 120b via wired and / or wireless communication to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112.

[0057] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node-Bs, eNode Bs, Home Node Bs, Home eNode Bs, next generation Node Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, and the like.

[0058] Base station 114a may be part of the RAN 103 / 104 / 105 and may also 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. Similarly, base station 114b may be part of the RAN 103b / 104b / 105b and may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, relay nodes, etc. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Cells may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, for example, base station 114a may include three transceivers, e.g., one for each sector of the cell. For example, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0059] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g 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, centimeter wave, millimeter wave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0060] The base station 114b can communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b can be established using any suitable RAT.

[0061] The RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over the air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0062] The WTRUs 102 may communicate with each other via a direct air interface 115 d / 116 d / 117 d , such as a sidelink communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115 d / 116 d / 117 d may be established using any suitable RAT.

[0063] The communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively, 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).

[0064] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RAN 103 / 104 / 105 or the RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b and the WTRUs 102c and 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved-UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications, etc.). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0065] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RAN 103 / 104 / 105 or the RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0066] For example, Figure 1AThe base station 114c in the example may be a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a place of business, a home, a vehicle, a train, an antenna, a satellite, a factory, a campus, and the like. The base station 114c and the WTRU 102 (e.g., WTRU 102e) may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102 (e.g., WRTU 102e) may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a microcell or a femtocell. Figure 1A As shown, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0067] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0068] Although not in Figure 1A Although not shown in the figures, it will be appreciated that the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM or NR radio technology.

[0069] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone (POTS) service. The Internet 110 may include a global system and device of interconnected computer networks that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) of the TCP / IP Internet protocol suite. Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include any type of packet data network (e.g., IEEE 802.3 Ethernet) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0070] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102g shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0071] Although not in Figure 1A 109. It is not shown in FIG. 10A , but it should be understood that the user equipment may make a wired connection to the gateway. The gateway may be a residential gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It should be understood that many aspects contained herein are equally applicable to a UE that is a WTRU and a UE that connects to the network using a wired connection. For example, aspects applicable to wireless interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to a wired connection.

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

[0073] like Figure 1B As shown, Node-Bs 140a and 140b can communicate with RNC 142a. Additionally, Node-B 140c can communicate with RNC 142b. Node-Bs 140a, 140b, and 140c can communicate with respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b can communicate with each other via an Iur interface. Each of RNCs 142a and 142b can be configured to control the respective Node-B 140a, 140b, and 140c to which it is connected. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0074] Figure 1B The core network 106 shown in FIG 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. While each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

[0077] The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0078] Figure 1C 1 is a system diagram of an example RAN 104 and the core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0079] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be appreciated that the RAN 104 may include any number of eNode-Bs. 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. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0080] Each of the eNode-Bs 160a, 160b, and 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 in the uplink and / or downlink, etc. Figure 1C As shown, eNode-Bs 160a, 160b, and 160c may communicate with one another via an X2 interface.

[0081] Figure 1C The core network 107 shown in FIG may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

[0083] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 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, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data may be available for the WTRUs 102a, 102b, and 102c, managing and storing the context of the WTRUs 102a, 102b, and 102c, and the like.

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

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

[0086] Figure 1D1 is a system diagram of an example RAN 105 and core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. The Non-3GPP Interworking Function (N3IWF 199) may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

[0087] The RAN 105 may include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of gNode-Bs. Each gNode-B 180a and 180b may include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When integrated access and backhaul connectivity is used, the same air interface may be used between the WTRUs and the gNode-Bs, which may be the core network 109 via one or more gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, for example, the gNode-B 180a may use multiple antennas to transmit and receive wireless signals to and from the WTRU 102a. It will be appreciated that the RAN 105 may employ other types of base stations, such as eNode-Bs. It will also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may employ both eNode-Bs and gNode-Bs.

[0088] The N3IWF 199 may include a non-3GPP access point 180c. It should be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using the 802.11 protocol.

[0089] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in uplink and / or downlink, etc. Figure 1D As shown, for example, gNode-Bs 180a and 180b may communicate with each other via an Xn interface.

[0090] Figure 1DThe core network 109 shown in the figure may be a 5G core network (5GC). The core network 109 may provide many communication services to customers interconnected by a radio access network. The core network 109 includes some entities that perform core network functions. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be understood that such a core network entity may be a logical entity implemented in the form of computer executable instructions (software) stored in a device or computer system (such as a 5G network system) configured for wireless and / or network communications. Figure 1G 90) in a memory and executed on a processor thereof.

[0091] exist Figure 1D In the example of FIG, the 5G core network 109 may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, a user plane function (UPF) 176a and 176b, a user data management function (UDM) 197, an authentication server function (AUSF) 190, a network exposure function (NEF) 196, a policy control function (PCF) 184, a non-3GPP interworking function (N3IWF) 199, and a user data repository (UDR) 178. Although each of the foregoing elements is depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Figure 1D The network functions are shown connected directly to each other, however, it should be understood that they may communicate via a routing agent such as a Diameter routing agent or a message bus.

[0092] exist Figure 1D In the example of , the connection between network functions is achieved via a set of interfaces or reference points. It should be understood that network functions can be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. The invocation of network function services can be achieved via direct connections between network functions, the exchange of messages on a message bus, calling software functions, etc.

[0093] The AMF 172 may be connected to the RAN 105 via the N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is Figure 1D Not shown in the figure.

[0094] The SMF 174 may be connected to the AMF 172 via the N11 interface. Similarly, the SMF may be connected to the PCF 184 via the N7 interface and to the UPFs 176a and 176b via the N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0095] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be Ethernet or any other type of network that switches data packets. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to the packet data network by connecting to the packet data network using the N6 interface or by connecting to each other and to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF 176 may also be responsible for packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic, and downlink packet buffering.

[0096] For example, via the N2 interface, the AMF 172 may also be connected to the N3IWF 199. For example, via a wireless interfacing technology not defined by 3GPP, the N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0097] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not Figure 1D . The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, allowing the control plane nodes to enforce these rules. The PCF 184 may send policies for the WTRUs 102a, 102b, and 102c to the AMF 172 so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0098] The UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can connect to network functions so that they can add, read, and modify data in the repository. For example, the UDR 178 can connect to the PCF 184 via the N36 interface. Similarly, the UDR 178 can connect to the NEF 196 via the N37 interface, and the UDR 178 can connect to the UDM 197 via the N35 interface.

[0099] The UDM 197 can serve as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can connect to the AMF 172 via the N8 interface, and the UDM 197 can connect to the SMF 174 via the N10 interface. Similarly, the UDM 197 can connect to the AUSF 190 via the N13 interface. The UDR 178 and the UDM 197 can be tightly integrated.

[0100] The AUSF 190 performs authentication related operations and is connected to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0101] NEF 196 opens the capabilities and services in the 5G core network 109 to the application function (AF) 188. The opening can occur on the N33 API interface. NEF can connect to AF 188 via the N33 interface and it can connect to other network functions to open the capabilities and services of the 5G core network 109.

[0102] The application function 188 may interact with the network functions in the 5G core network 109. The interaction between the application function 188 and the network functions may occur via a direct interface or may occur via the NEF 196. The application function 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise that has a business relationship with a mobile network operator.

[0103] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create networks that are customized to provide optimized solutions for different market scenarios that require different requirements, such as in terms of functionality, performance, and isolation.

[0104] 3GPP has designed the 5G core network to support network slicing. Network slicing is a powerful tool that network operators can use to support diverse 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband), which have very different and sometimes extreme requirements. Without network slicing, the network architecture may not be flexible and scalable enough to effectively support a wider range of use case requirements, as each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, the introduction of new network services should be more efficient.

[0105] Reference again Figure 1D In a network slicing scenario, the WTRU 102a, 102b, or 102c may connect to the AMF 172 via the N1 interface. The AMF may logically be part of one or more slices. The AMF may coordinate the connection or communication between the WTRU 102a, 102b, or 102c and one or more UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other because they may utilize different computing resources, security credentials, etc.

[0106] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include or may communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include or may communicate with a Short Message Service (SMS) service center that facilitates communications via the Short Message Service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and the server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0107] This article describes and Figure 1A 、 1C The core network entities shown in 1D and 1E are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that these entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in future specifications released by 3GPP (including future 3GPP NR specifications). Figure 1A 、 1B The specific network entities and functions described and illustrated in , 1C, 1D and 1E are provided as examples only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system (whether currently defined or defined in the future).

[0108] Figure 1E An example communication system 111 is shown in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, and F, a gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, gNBs, V2X networks, and / or other network elements. One, some, or all of the WTRUs A, B, C, D, E, and F may be outside of access network coverage 122. WTRUs A, B, and C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members.

[0109] If WTRU A, B, C, D, E, F are under access network coverage ( Figure 1E 129b), WTRUs A, B, C, D, E, and F may communicate with each other via the gNB 121 over the Uu interface 129b. If WTRUs A, B, C, D, E, and F are in or out of access network coverage (e.g., in Figure 1E In the figure, A, C, D and E are shown outside the network coverage), the WTRUA, B, C, D, E, F can communicate directly with each other via the side link (PC5 or NR PC5) interfaces 125a, 125b, 128.

[0110] WTRUs A, B, C, D, E, and F may communicate with the RSU 123a or 123b via the vehicle-to-network (V2N) interface 126 or the sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with the V2X server 124 via the vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via the vehicle-to-pedestrian (V2P) interface 128.

[0111] Figure 1F is an example apparatus or device WTRU 102 (such as Figure 1A 、 1B , 1C, 1D or 1E). Figure 1F As shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements. In addition, the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver (BTS), a Node-B, a site controller, an access point (AP), a Home Node-B, an evolved Home Node-B (eNodeB), a Home evolved Node-B (HeNB), a Home evolved Node-B gateway, a next generation Node-B (gNode-B), and a proxy node, etc.), may include Figure 1F Some or all of the elements depicted in and described herein.

[0112] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. 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. Although Figure 1F The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0113] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (e.g., Figure 1A The transmit / receive element 122 may be configured to transmit and / or receive signals from a base station 114a) or to transmit and / or receive signals to or from another UE via the air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. For example, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. The transmit / receive element 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0114] Furthermore, although the send / receive element 122 Figure 1F Although depicted as a single element in FIG. 1 , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0115] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate with different RRHs, TRPs, RSUs, or nodes via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or using the same RAT via multiple beams.

[0116] The processor 118 of the WTRU 102 may be coupled to and receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a 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. 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 hosted in the cloud or in an edge computing platform or in a home computer (not shown).

[0117] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0118] The processor 118 may also be coupled to the GPS chipset 136, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location-determination method.

[0119] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0120] The WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0121] Figure 1G is a block diagram of an exemplary computing system 90 in which Figure 1A 、 1C , 1D, and 1E, such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, other network 112, or network service 113. Computing system 90 may comprise a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within processor 91 to cause computing system 90 to operate. Processor 91 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), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, or the like. Processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables computing system 90 to operate in a wireless environment. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0122] In operation, processor 91 retrieves, decodes, and executes instructions, and transfers information to and from other resources via the computing system's primary data transfer path system (bus 80). Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0123] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or changed by processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts virtual addresses into physical addresses when instructions are executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; it cannot access memory within the virtual address space of another process unless memory sharing between processes has been established.

[0124] Additionally, computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from processor 91 to peripheral devices, such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

[0125] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0126] Additionally, computing system 90 may contain communications circuitry, such as, for example, a wireless or wired network adapter 97, which may be used to connect computing system 90 to external communications networks or devices, such as Figure 1A 、 1B , RAN 103 / 104 / 105 of 1C, 1D, and 1E, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other network 112 to enable computing system 90 to communicate with other nodes or functional entities of those networks. Communication circuitry, alone or in combination with processor 91, may be used to perform the sending and receiving steps of certain devices, nodes, or functional entities described herein.

[0127] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communications. Computer-readable storage media include volatile and non-volatile, removable, and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

[0128] 5G V2X use cases

[0129] As vehicle-to-everything (V2X) applications make significant progress, the transmission of short messages about the vehicle's own status data for basic safety purposes can be expanded with the transmission of larger messages containing raw sensor data, vehicle intent data, coordination, confirmation of future maneuvers, etc. For these advanced applications, the expected requirements for meeting the required data rate, latency, reliability, communication range, and speed are even more stringent.

[0130] For enhanced V2X (eV2X) services, 3GPP has identified 25 use cases and related requirements in TR 22.886.

[0131] A set of normative requirements is specified in TS 22.186, and these use cases are categorized into four use case groups: vehicle platooning, extended sensors, advanced driving, and remote driving.

[0132] A detailed description of the performance requirements for each use case group is specified in TS 22.186.

[0133] Uu-based sidelink control for V2X in NR

[0134] In NR V2X, sidelink resource allocation modes 1 and 2 are agreed. In mode 1, the base station schedules the sidelink resources for the UE to use for sidelink transmission. The UE can use the allocated resources to perform broadcast, multicast, or unicast on the sidelink. In mode 2, the UE determines the sidelink resources for sidelink transmission within the sidelink resources configured by the base station or pre-configured sidelink resources.

[0135] Mode 1 supports the gNB allocating sidelink resources between Uu transmissions and sidelink transmissions over the Uu interface for both dedicated sidelink carriers and shared licensed carriers. When a carrier is shared between Uu transmissions and sidelink transmissions, the Uu transmissions and sidelink transmissions can occur in the same frame but in different timeslots, or they can occur in the same timeslot. In the following sections, the carrier on which Uu transmissions and sidelink transmissions are multiplexed is referred to as a shared carrier.

[0136] In Mode 1, the gNB may dynamically allocate resources for sidelink transmission, or the gNB may allocate resources for sidelink transmission via Type 1 configuration grant or via Type 2 configuration grant.

[0137] Inter-UE multiplexing in NR

[0138] Downlink transmissions collide when some of the time and frequency resources of two or more downlink transmissions overlap. The gNB schedules this in some scenarios (for example, if there is urgent data that needs to be sent with very low latency and no unscheduled resources are available). In NR, when this happens, the gNB discards the lower-priority transmission and sends the higher-priority data. The gNB then sends a preemption indication to instruct the preempted UE(s) to flush their buffer(s).

[0139] DCI format 2_1 is used to inform the UE of the (one or more) PRBs and (one or more) OFDM symbols within a time slot for which the UE can assume that there is no transmission intended for the UE. Within one DCI, it can carry multiple preemption indicators, where each preemption indicator is 14 bits. The interpretation of the bitmap is configurable. For example, each bit represents a full bandwidth part and one OFDM symbol in the time domain, or a half bandwidth part and two OFDM symbols in the time domain.

[0140] Similar to the downlink, in some scenarios, two scheduled uplink transmissions may collide. When an uplink transmission collision occurs, the scheduled low-priority uplink transmission may impact the performance of the scheduled high-priority uplink transmission. To address this issue, the gNB can send a cancellation indicator to cancel the scheduled low-priority uplink transmission, or the gNB can use a power-based mechanism to reduce the impact of the scheduled low-priority uplink transmission.

[0141] For NR V2X Mode 1 shared carrier scenarios, the gNB can use dynamic scheduling, Type 1 configuration grants, or Type 2 configuration grants to allocate sidelink transmissions on a shared carrier with downlink (DL) and / or uplink (UL) transmissions on the Uu interface. For example, the gNB might schedule a very low-latency or high-priority DL data transmission on the Uu interface for a UE, which could overlap with a sidelink transmission already scheduled or configured for another UE. In this case, both transmissions could be degraded or even fail. Therefore, mechanisms are needed to handle inter-UE contention between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low-latency or high-priority DL or UL transmissions.

[0142] For NR V2X Mode 1, the gNB can use dynamic scheduling, Type 1 configuration grants, or Type 2 configuration grants to allocate sidelink transmissions. For example, the gNB might schedule a very low-latency or high-priority data transmission on the sidelink for a UE, which could overlap with a sidelink transmission already scheduled or configured for another UE. In this case, both transmissions could be degraded or even fail. Therefore, mechanisms are needed to handle inter-UE conflicts between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low-latency or high-priority sidelink transmissions.

[0143] Public options include:

[0144] This disclosure includes solutions for handling inter-UE contention in NR V2X for the following use cases:

[0145] • Inter-UE collisions between dynamically scheduled broadcast sidelink and dynamically scheduled Uu transmissions.

[0146] • Inter-UE collisions between dynamically scheduled unicast sidelink and dynamically scheduled Uu transmissions.

[0147] • Inter-UE collisions between dynamically scheduled multicast sidelinks and dynamically scheduled Uu transmissions.

[0148] • Inter-UE collisions between the broadcast sidelink based on configured grants and dynamically scheduled Uu transmissions.

[0149] • Inter-UE collisions between unicast sidelink based on configured grants and dynamically scheduled Uu transmissions.

[0150] • Inter-UE collisions between the multicast sidelink based on configuration grants and dynamically scheduled Uu transmissions.

[0151] • Inter-UE collision between a dynamically scheduled sidelink and another dynamically scheduled sidelink.

[0152] • Inter-UE collisions between configured grant-based sidelinks and dynamically scheduled sidelinks.

[0153] Public inter-UE conflict handling mechanisms include:

[0154] Reduce the transmit power of the preempted transmission.

[0155] • Reduce the sender and / or receiver antenna gain of the preempted transmission.

[0156] • Increase the transmit power of transmissions that are to preempt other transmissions.

[0157] • Increasing the sender and / or receiver antenna gain of transmissions that are to preempt other transmissions.

[0158] Preempt the antenna panel of the preempted transmission.

[0159] Cancel the sending of a preempted transmission.

[0160] This disclosure includes the following solutions:

[0161] Configuration and signaling for UE to monitor and decode Sidelink Cancellation Indication (SL-CI).

[0162] • Mechanisms to handle inter-UE collisions with duplicate sidelink transmissions.

[0163] Prioritization rules for simultaneous sidelink and uplink transmissions. Dynamically scheduled Uu transmissions preempt sidelink transmissions

[0164] In NR V2X Mode 1, the Uu interface and the sidelink may operate on a shared carrier. The gNB may schedule DL or UL transmissions on the Uu interface and transmissions on the sidelink based on the system state. In some scenarios, the resources scheduled for very low latency or high priority DL or UL transmissions on the Uu interface (e.g., PDSCH and / or PUSCH) may partially or completely overlap in time and / or frequency with the resources allocated to the sidelink transmissions, with the following implications: Figure 2 Alternative case shown.

[0165] • Case A: A dynamically scheduled downlink transmission (eg, PDSCH) on the Uu interface may overlap / collide with a dynamically scheduled sidelink transmission.

[0166] • Case B: Dynamically scheduled uplink transmissions (eg, PUSCH) on the Uu interface may overlap / collide with dynamically scheduled sidelink transmissions.

[0167] • Case C: Dynamically scheduled downlink transmissions on the Uu interface (eg, PDSCH) may overlap / collide with configured grant sidelink transmissions.

[0168] • Case D: Dynamically scheduled uplink transmissions on the Uu interface (e.g., PUSCH) may overlap / collide with configured granted sidelink transmissions.

[0169] Figure 2 The sidelink transmission shown in FIG can be broadcast, multicast, or unicast, or any combination thereof. In this example, the Uu transmission may have a higher priority or low latency requirement than the sidelink transmission. The sidelink transmission may be preempted to ensure that higher priority data is transmitted to or received from the Uu transmission.

[0170] Dynamically scheduled broadcast sidelink transmissions preempted by dynamically scheduled Uu transmissions

[0171] This section describes the scenario where a dynamically scheduled Uu transmission conflicts with a dynamically scheduled broadcast sidelink transmission. In the broadcast scenario, the Tx UE (transmitting UE) will not receive ACK / NACK feedback from (one or more) Rx UEs (receiving UEs). The Uu transmission herein can be either a downlink transmission or an uplink transmission.

[0172] Assume that UE1 is dynamically scheduled by the gNB to send a broadcast transmission on the sidelink; and assume that UE2 is dynamically scheduled by the gNB to have a transmission or reception on the Uu interface (e.g., PDSCH or PUSCH), where some or all of the resources allocated to UE2 overlap in time and frequency with the resources allocated to UE1. To handle inter-UE collisions, we disclose that this broadcast sidelink transmission can be preempted, with the following alternative cases:

[0173] Preemption of Uu transmissions using higher power

[0174] In the first alternative case, UE1 will perform broadcast sidelink transmission regardless of whether preemption is received or not.

[0175] To ensure that higher-priority data is transmitted and received to and from UE2, UU transmissions may be performed at a higher power level than would be used in a scenario without inter-UE contention. For example, if it is a downlink transmission, the gNB may increase transmit power and / or beamforming antenna gain; if it is an uplink transmission, UE2 may be instructed to increase transmit power. The Transmit Power Command (TPC) field in the scheduling DCI may be used to instruct UE2 to increase transmit power. Alternatively, a bit field in the scheduling DCI may be used to indicate to UE2 whether it is preempting other transmissions. Alternatively, the selection of a specific codeword in the codebook for codebook-based UL transmissions may indicate the increased transmit power. If preempting other transmissions, UE2 may transmit at maximum power or by applying a predefined / preconfigured transmit power offset. Alternatively, the scheduling DCI may indicate the priority level of the scheduled uplink transmission to UE2. Each priority level may be associated with a predefined / preconfigured transmit power level and / or offset, and UE2 will set the transmit power level accordingly based on the indicated priority level.

[0176] After UE1 performs a broadcast sidelink transmission, it can monitor the Uu downlink signal / channel (e.g., PDCCH) that potentially carries an indicator to determine whether UE1's transmission has been preempted before refreshing UE1's transmission buffer. Information about preemption monitoring opportunities, such as monitoring periodicity, can be configured to the UE by radio resource control (RRC) at symbol and / or time slot intervals. If UE1 does not detect that its transmission has been preempted, it will flush its buffer; if it detects that its transmission has been preempted, it can retain the buffer and prepare for retransmission.

[0177] If a preemption indication is detected, UE1 can detect that the transmission is preempted. The preemption indication can be UE-specific or group-specific. The indication can be carried in a sequence, or a preamble, or a reference signal, or a DCI. When a UE-specific indication is used, the UE will be configured with a UE-specific configuration. When a group-specific indication is used, the same group-specific configuration will be configured for multiple UEs. For a UE configured with a group-specific indication, if it is not scheduled to have a transmission between two monitoring occasions, the UE can skip the next monitoring occasion. UE1 can then receive a separate scheduled DCI to schedule the retransmission, such as Figure 3 Alternatively, UE1 may detect that the transmission is preempted by detecting signaling that jointly indicates preemption and resources for retransmission, such as Figure 4 Alternatively, the preemption indication may be implicitly indicated by the scheduling of the retransmission, for example, when UE1 receives the scheduling of the retransmission for the broadcast side link transmission, it determines that the initial broadcast side link transmission is preempted, as shown in FIG. Figure 5 The scheduling of retransmissions can be intra-slot scheduling as shown in the figure or can be cross-slot scheduling, depending on the delay requirements, for example.

[0178] For UEs receiving broadcast message retransmissions, the UE can soft-combine the retransmission(s) from multiple message receptions to increase the probability of successfully decoding the data. If a UE uses preempted transmissions for soft combining, it may degrade the decoding of the combination. Preemption indication(s) may be sent to the receiving UE to notify it not to soft-combine the preempted transmission with other transmission(s). For example, after detecting preemption from the gNB, UE1 may broadcast the preemption to the receiving UE, for example, via the Code Block Group Refresh Indicator (CBGFI) field in the Sidelink Control Information (SCI) for the retransmission. For example, for the preempted Code Block Group (CBG), UE1 may set a bit in the CBGFI bitmap to "1." Alternatively, this may be done via the New Data Indicator (NDI) field in the SCI for the retransmission. For example, if the retransmission is due to preemption, UE1 may toggle the value of the NDI field in the SCI for the retransmission. If the retransmission is not due to preemption, UE1 will not toggle the value of the NDI field. Alternatively, when UE1 performs a retransmission, it can use a different RV than the initial transmission (e.g., RV0 for the initial transmission and RV2 for the retransmission). Alternatively, when UE1 performs a retransmission, it can use a different HARQ ID (e.g., HARQ ID 1 for the initial transmission and HARQ ID 4 for the retransmission). By doing so, the Rx UE will treat the retransmission as a new transmission and will not attempt to combine it with the initial transmission.

[0179] The UE is preconfigured or instructed to know which transmissions can be soft combined. This document specifies example signaling for indicating such information. How the UE performs soft combining and whether the UE must perform soft combining depends on the specific UE implementation. Generally, the UE will perform combining whenever it is possible to improve performance.

[0180] When UE1 performs retransmission, it may retransmit the entire TB or it may retransmit only a subset of the TB, such as preempted symbols, physical resource blocks (PRBs), or CBGs.

[0181] An example of a public procedure for detecting preemption is given in Figure 66 is shown for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The UE receives a schedule for a broadcast sidelink transmission (601). The UE performs a broadcast sidelink transmission on the scheduled resources (602). In another case, the receiving UE may also receive a preemption indication from the gNB. The UE monitors for preemption indications for preemptions of Uu transmissions (603). When preemption is detected (604), the UE retransmits (605) the broadcast on the sidelink. When preemption is not detected, the UE flushes the buffer for the transmitted packets (606).

[0182] Use adjusted transmission control parameters to preempt low priority SL transmissions

[0183] In a second alternative scenario, UE1 can monitor before performing a broadcast sidelink transmission to detect whether it has been preempted. If preemption occurs, the gNB can send an indication instructing UE1 to adjust transmission control parameters, such as TX power, MCS, transmission layer configuration (such as diversity scheme), beamforming / MIMO scheme, CBG adaptation, etc. An example is that the UE can reduce the transmit power (even to zero) for the entire transmission or for part of the transmission (e.g., reducing the data REs but not the DMRS REs). For example, by detecting this indication, UE1 will overwrite the old TPC and send the scheduled broadcast sidelink transmission at the new transmit power.

[0184] The new transmit power level or offset may be dynamically indicated to the UE; alternatively, the UE may be instructed to switch to a preconfigured low power level or offset. The indication may be signaled via DCI, a reference signal, a preamble, or a sequence.

[0185] In one case, the UE can be instructed to reduce the power level of all allocated resources, regardless of whether they fully or partially overlap with the colliding Uu transmission. In this example, a value can be signaled to the UE to indicate the new transmit power. For example, the UE can be instructed to reduce the transmit power by an offset equal to a certain number of dB; alternatively, the UE can be instructed to indicate the absolute transmit power level to which it needs to change. For example, the UE can be configured with multiple sequences, each of which is associated with a value. The UE can determine the new transmit power based on which sequence and / or preamble was detected.

[0186] Alternatively, when reference signals such as DMRS and CSI-RS are used to indicate power reduction, the UE may be configured with different reference signal time and frequency configurations, where each configuration is associated with a value. The UE may determine the new transmit power based on the time and frequency resources on which the UE detects the reference signal.

[0187] Alternatively, the UE may be configured with one reference signal (DMRS or CSI-RS) time and frequency configuration but with different reference signal sequences. For example, the UE may be configured with four different sequence initializers for generating reference signal sequences, where each initializer is associated with a value as shown in Table 1. The UE may determine the indicated power control command based on the detected reference signal sequence.

[0188] Table 1 - Example initializer values for determining associated power control commands configured for a UE

[0189]

[0190] Alternatively, the gNB can instruct the UE using power control commands via UE-specific DCI or group-common DCI. Information about monitoring opportunities, such as the monitoring period, symbols and / or time slots to be monitored, can be configured for the UE via RRC. Alternatively, the UE can monitor only the time slots containing allocated resources.

[0191] In another case, the UE may be instructed to reduce the power level of a portion of the allocated resources, for example, to reduce the power level of some symbols and / or PRBs (e.g., overlapping symbols and / or PRBs). UE-specific DCI may be used to indicate a power control command and the time domain resources and / or frequency domain resources to which the UE needs to apply the power control command and, in some cases, to which timeslots these PSIs apply. For example, a new DCI format may be introduced having a CRC scrambled with a UE-specific RNTI (e.g., RNTIp). Such DCI may carry: a power control command field indicating power adjustment; a field for indicating the time domain resources to which the UE may consider these time domain resources to be preempted and to which power adjustment may be applied, for example, a 14-bit bitmap with each bit representing one symbol or a 7-bit bitmap with each bit representing two symbols in a timeslot; and / or a field indicating the frequency resources to which the UE may consider these frequency resources to be preempted and to which power adjustment may be applied, for example, via a bitmap. When the UE detects a DCI scrambled with the configured RNTIp during its monitoring opportunity, the UE can determine that it is preempted and determine the power adjustment, preempted time domain resources, and / or frequency domain resources. In addition to introducing a new DCI format, such indication can also be indicated through an existing DCI format (e.g., DCI format 0_1). When the UE detects DCI format 0_1 in which some fields are set to some predefined values, the UE can determine that this DCI is intended to indicate a power control command caused by an inter-UE conflict and determine the power to be adjusted and the preempted time and / or resources.

[0192] Alternatively, a group-common DCI may be used to indicate the power control command and the time domain resources and / or frequency domain resources to which the UE needs to apply the power control command. For example, a new DCI format may be introduced with a CRC scrambled using a group-specific RNTI (e.g., an RNTIpg that may be configured to a group of UEs). Such a DCI may carry: multiple power control command fields indicating power adjustment for each UE within the group; a field for indicating the time domain resources to which the UE may consider these time domain resources to be preempted and to which the power adjustment may be applied, e.g., a 14-bit bitmap with each bit representing one symbol or a 7-bit bitmap with each bit representing two symbols in a timeslot; and / or a field indicating the frequency resources to which the UE may consider these frequency domain resources to be preempted and to which the power adjustment may be applied, e.g., via a bitmap. When a group is formed, each UE may be configured with the power control command bit for that UE in the group-common DCI via an RRC message. When the UE detects the DCI scrambled with the configured RNTIpg during the UE's monitoring opportunity, the UE may determine that it is preempted and determine the power adjustment in the configured bits, the preempted time domain resources and / or frequency domain resources.

[0193] Alternatively, a sequence, preamble, or reference signal can be used to indicate a power control command and the time and / or frequency domain resources to which the UE should apply the power control command. Because more information needs to be carried, more sequences, preambles, or reference signal initializers can be configured for different hypotheses. The UE can perform blind cross-correlation for more possible scenarios to detect and determine the corresponding information.

[0194] After UE1 performs broadcast sidelink transmission at a reduced power level, UE1 may perform retransmission. UE1 may retransmit the entire TB, or the UE may retransmit only the portion to which the reduced power is applied, such as overlapping symbols, PRBs, or CBGs.

[0195] In one case, the scheduling of retransmissions may be indicated jointly with an indication for reducing power, e.g. Figure 7 As shown. For example, UE1 may receive a retransmission schedule (e.g., via DCI format 0_1) before it performs the scheduled initial transmission. In this case, UE1 may determine that the scheduled initial transmission is preempted. UE1 will send the preempted initial transmission using a reduced power level and perform the retransmission as scheduled.

[0196] Alternatively, in another case, the scheduling of retransmissions may be indicated separately from the indication for reducing power, such as Figure 8As shown. UE1 may first monitor to detect whether it is preempted. If the UE detects a power reduction indication (e.g., as disclosed in a sequence, preamble, reference signal, or DCI), the UE determines that it is preempted and reduces the transmission power. The UE may then monitor the retransmission schedule and perform the retransmission as scheduled.

[0197] In addition, an indication may be sent to the receiving UE to notify not to soft combine the data preempted in the initial transmission or all received data. The solution disclosed in the Uu transmission preemption using higher power may also be applied here.

[0198] Figure 9 An example of a disclosed process for detecting a power reduction indicator is shown for a sidelink UE that has an inter-UE conflict with a scheduled Uu transmission. The UE receives a schedule for a broadcast sidelink transmission (901). The UE monitors to detect whether a power reduction indication is sent (902). When the UE detects the power reduction indication (903), it performs a broadcast sidelink transmission at reduced power (904). If it does not detect the power reduction indication (903), it performs the broadcast sidelink transmission as scheduled (908). The UE determines whether a schedule for retransmission is detected together with the detection result of the power reduction indication (905). If so, the UE transmits at normal power (906). If not, the UE monitors the schedule for retransmission and retransmits at normal power (907).

[0199] Use the cancel indicator to preempt low-priority SL transfers

[0200] In a third alternative, UE1 can monitor before performing a broadcast sidelink transmission to detect whether it has been preempted. If preemption occurs, the gNB can send a cancellation indication, such as SL-CI (Sidelink Cancel Indication), instructing UE1 to cancel the scheduled transmission. By detecting this indication, UE1 will not perform all or part of the scheduled transmission. If a cancellation indication is detected, the PHY can send an indication to higher layers, such as a canceled MAC.

[0201] In one case, the UE may be instructed to cancel transmission on all allocated resources regardless of whether it fully overlaps or partially overlaps with the conflicting Uu transmission, for example, the UE may cancel transmission of an entire TB. Similar to detecting a power reduction indicator, the UE may detect the cancellation indication by: receiving a UE-specific DCI; or receiving a group-common DCI; or detecting a preconfigured reference signal; or detecting a preconfigured preamble; or detecting a preconfigured sequence, for example, a new reference signal carried by some REs from a physical signal. When multiple panels are used for transmission, the UE may be instructed to cancel transmission on one or more panels. For example, if the UE is scheduled to broadcast via a panel in the front bumper aiming at the front and a panel in the back bumper aiming at the back, the UE may be instructed not to broadcast using the panel in the front bumper because it is preempted, for example, the DCI indicating the power reduction indicator may carry a panel index field to indicate to the UE which panels are preempted.

[0202] In another case, the UE may be instructed to cancel transmissions on a portion of the allocated resources, e.g., cancel transmissions on overlapping symbols and / or PRBs, or cancel transmissions on CBGs that overlap with the canceled resources. Similar to the detection power reduction indication, a UE-specific DCI or a group-common DCI may be used. For example, a new DCI format may be introduced in which the CRC is scrambled with a group-specific RNTI, e.g., an RNTIpg that may be configured to a group of UEs. Such a DCI may carry fields indicating time domain resources on which the UEs may consider themselves preempted and cancel transmissions, e.g., a 14-bit bitmap with each bit representing one symbol or a 7-bit bitmap with each bit representing two symbols in a time slot; and / or fields indicating frequency resources on which the UEs may consider themselves preempted and cancel transmissions, e.g., via a bitmap.

[0203] When the UE detects the DCI scrambled with the configured RNTIpg during its monitoring opportunity, the UE may determine that it is preempted and cancel the transmission on the indicated time and / or frequency resources.

[0204] Alternatively, a sequence, a preamble, a reference signal can be used to indicate that the UE needs to cancel the time domain resources and / or frequency domain resources of the scheduled transmission. For example, k different sequence initializers can be configured for the UE via the RRC for generating the reference signal sequence, where each initializer is associated with some configurable time domain and / or frequency domain resources. An example is shown in Table 2, where each initializer represents a different time domain resource (assuming that symbol 0 is the first symbol in the time slot). The UE can be configured with all the initializers shown in the table, or the UE can be configured with a subset of the listed initializers. Based on the reference signal sequence detected by blind cross correlation, the UE can determine the time domain and / or frequency domain resources required for the UE to cancel its transmission.

[0205] Table 2 Different initializer values configured to the UE to determine the resources on which the transmission needs to be canceled

[0206]

[0207]

[0208] After UE1 cancels the scheduled broadcast sidelink transmission, UE1 may retransmit the entire TB or it may retransmit only the canceled portion, such as the overlapping symbols, PRBs or CBGs.

[0209] In such Figure 7 and Figure 8 Similar concepts disclosed in the power reduction indicator shown in can be applied here. The scheduling of retransmissions can be indicated jointly with the cancellation indication. Or the scheduling of retransmissions can be indicated separately from the cancellation indication. For example, the cancellation indication can be signaled by a group-common DCI (e.g., a DCI with a CRC scrambled with RNTIpg) before the scheduled transmission; and after the cancellation occurs, the retransmission can be scheduled by a UE-specific DCI (e.g., a DCI with a CRC scrambled with C-SL-RNTI).

[0210] In addition, an indication may be sent to the receiving UE to notify that the data preempted in the initial transmission or all received data is not to be soft combined.The solutions disclosed in the alternative case of preemption using higher power Uu transmissions may also be applied here.

[0211] Figure 10An example of a disclosed process for detecting a cancellation indication is shown for a sidelink UE that has an inter-UE conflict with a scheduled Uu transmission. The UE receives a schedule for a broadcast sidelink transmission (1001) and monitors whether a cancellation indication is sent (1002). The UE monitors the cancellation indication (1002) and determines whether it detects the cancellation indication (1003). If not, it performs the broadcast sidelink transmission as scheduled (1008). If the UE detects a cancellation indication, it cancels the transmission indicated in the cancellation indication (1004). The UE determines whether a schedule for a retransmission is detected together with the cancellation indication (1005), and if so, the UE retransmits (1006), and if not, the UE monitors the schedule for the retransmission and retransmits (1007).

[0212] Dynamically scheduled Uu transmission preempts dynamically scheduled unicast sidelink transmission

[0213] This section outlines the solution for the case where a dynamically scheduled Uu transmission collides with a dynamically scheduled unicast sidelink transmission. In the unicast scenario, the Tx UE will receive ACK / NACK feedback from the Rx UE. The Uu transmission in this article can be a downlink transmission or an uplink transmission.

[0214] Assume that UE1 is dynamically scheduled by the gNB to send unicast transmissions on the sidelink as a Tx UE; UE2 is a Rx UE that will receive the unicast sidelink from UE1; and assume that UE3 is dynamically scheduled by the gNB to have transmissions or receptions on the Uu interface (e.g., PDSCH or PUSCH), where some or all of the resources allocated to UE3 temporally overlap with the resources allocated to UE1. To handle inter-UE collisions, we disclose unicast sidelink transmissions that may be preempted in the following alternative scenarios.

[0215] Preemption of Uu transmissions using higher power

[0216] In the first alternative case, regardless of whether UE1 receives the preemption or not, it will perform unicast sidelink transmission.

[0217] To guarantee transmission / reception of UE3, using a similar scheme proposed in the dynamically scheduled broadcast sidelink case, Uu transmission may be performed at a higher power level than for a scenario without inter-UE contention.

[0218] For a Tx UE, after UE1 performs a unicast sidelink transmission, it monitors the feedback (e.g., ACK / NACK) sent by UE2 via the PSFCH. UE1 can also monitor the indication sent by the gNB to determine whether its transmission has been preempted. The monitoring timing can be configured by RRC.

[0219] In one case, UE1 may receive an ACK from UE2 and detect no preemption indication from the gNB. UE1 may then determine that the transmission was successful and it may flush its buffers.

[0220] In another scenario, UE1 may receive an ACK from UE2 and detect a preemption indication from the gNB. UE1 can then determine that although it was preempted, the transmission was successful and it can flush its buffers.

[0221] In yet another scenario, UE1 may receive a NACK from UE2 and detect a preemption indication from the gNB. UE1 may then determine that the transmission failed due to preemption. UE1 may retransmit and send preemption information to UE2, instructing UE2 to flush its buffer accordingly. The solutions disclosed in the alternative case of preemption using higher-power Uu transmissions in a broadcast scenario can also be applied here.

[0222] In yet another scenario, UE1 may receive a NACK from UE2 and detect a preemption indication from the gNB, where the gNB may send preemption indications to both the transmitting and receiving UEs. UE1 may then determine that the transmission failed due to preemption. UE1 may perform a retransmission without sending preemption information to UE2.

[0223] In yet another scenario, UE1 may receive a NACK and preemption information from UE2, for example, via the CBGFI field in the SFCI. For example, UE2 may receive a preemption indication from the gNB. It may flush its buffer accordingly. UE2 may send a bitmap in the SFCI to UE1 indicating the preempted resources. Upon receiving this information, UE1 may determine that the transmission failed due to preemption. UE1 may then perform a retransmission.

[0224] When an inter-UE collision occurs, the gNB can, on the one hand, allocate resources for retransmission to UE1 without receiving feedback from UE1. UE1 can determine whether to perform retransmission based on the feedback from the receiving UE. For example, if UE1 receives an ACK from UE2, it can ignore retransmission scheduling; or if it receives a NACK from UE2, it can perform retransmission using the allocated resources. Alternatively, the gNB can allocate resources for retransmission based on the feedback from UE1. Based on the feedback from the receiving UE, UE1 can send an indication to the gNB, such as an SR or BSR, to indicate whether retransmission scheduling is required. For example, if UE1 receives an ACK from UE2, it can indicate to the gNB that retransmission scheduling is not required. If UE1 receives a NACK from UE2, it can indicate to the gNB that retransmission scheduling is required. The indication may be explicit, for example, sending indication 'A' means retransmission is required, and sending indication 'B' means no retransmission is required; or the indication may be implicit, for example, sending indication 'C' means retransmission is required, and not sending indication 'C' means no retransmission is required.

[0225] When UE1 does perform a retransmission, it may retransmit the entire TB or it may retransmit only a subset of the TB, eg, the preempted symbols, PRBs, or CBGs.

[0226] Figure 11 An example of a disclosed process for a Tx UE to detect preemption is shown in FIG1 for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The UE receives a schedule for a unicast sidelink transmission (1101). The UE performs a unicast sidelink transmission on the scheduled resources (1102). The UE monitors for an ACK or NACK from the Rx UE (1103). The UE determines whether it has received an ACK or NACK from the Rx UE (1104). The UE monitors for a sent preemption indication (1105). The UE determines whether it has detected a preemption (1106). If a preemption is detected, the UE retransmits and sends the preemption information to the Rx UE (1108). If not, the Tx UE retransmits (1107). If the Tx UE does receive an ACK or NACK, it sends and flushes its buffer (1109).

[0227] For Rx UE, UE2 can try to decode the sent data and send feedback to UE1. When UE2 cannot decode the data, it can send NACK to UE1.

[0228] In one case, UE2 may receive the retransmission but not any preemption indication.For the same HARQ process ID, UE2 may soft-combine the received retransmission with the data in the buffer.

[0229] In another scenario, UE2 may receive a retransmission from UE1 and a preemption indication. UE2 may flush its buffer and decode the retransmission. If the initial transmission was partially preempted, the UE may flush its buffer only for the preempted portion. For example, the UE may soft-combine the retransmission with the first portion of the soft buffer but not with the second portion of the soft buffer, which may correspond to the preempted resources. Therefore, the UE may flush the second portion of the soft buffer.

[0230] In yet another case, UE2 may receive a retransmission from UE1 and a preemption indication from the gNB. UE2 may flush its buffer and decode the retransmission.

[0231] In yet another case, UE2 may receive a preemption indication from the gNB before sending HARQ feedback to UE1. UE2 may flush its buffer and send the preemption information along with the HARQ feedback.

[0232] Figure 12 An example of a disclosed process for an Rx UE to detect preemption is shown in FIG1 for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The Rx UE receives a schedule for unicast sidelink preemption (1201). The UE determines whether the received data was successfully decoded (1202). If so, the UE sends an ACK and flushes its buffer (1206). If not, the Rx UE determines whether preemption was detected (1203). If so, it flushes its buffer for the resources indicated as preempted and decodes the retransmission (1205). If not, the Rx UE decodes the retransmission via soft combining (1204).

[0233] For retransmission scheduling, such as Figure 3 、 Figure 4 、 Figure 5 The solutions disclosed for dynamically scheduled broadcasts can also be applied here.

[0234] Use adjusted transmission control parameters to preempt low priority SL transmissions

[0235] In the second alternative, the gNB can send an indication to instruct UE1 to adjust the transmission control parameters before UE1 performs the scheduled initial unicast transmission. The concepts disclosed for how to send the power reduction indicator for the dynamically scheduled broadcast sidelink can also be applied here. The gNB can send the power reduction indicator only to the Tx UE, or the gNB can send the power reduction indicator to both the Tx UE and the Rx UE. For the scheduling of retransmissions, such as Figure 7 and Figure 8 The solutions presented for dynamically scheduled broadcasts can also be applied here.

[0236] For Tx UE, after detecting the power reduction indicator, UE1 can rewrite the old TPC and send the scheduled unicast sidelink at the new transmit power. Then, it will monitor the feedback sent by UE2 via PSFCH, such as ACK / NACK.

[0237] The Tx UE behavior, retransmission allocation methods disclosed in the alternative case of Uu transmission preemption using higher power can also be applied here.

[0238] Figure 13 An example of a disclosed process for a Tx UE to detect a power reduction indicator is shown for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The UE receives a schedule for a unicast sidelink transmission (1301). The UE monitors whether a power reduction indication is sent (1302). The UE determines whether a power reduction indication is detected (1303). If so, the UE performs a unicast sidelink transmission at reduced power and receives feedback from the Rx UE (1304). The UE determines whether it receives an ACK (1305). If so, it sends and flushes its buffer (1307). If not, the UE retransmits and sends preemption information to the Rx UE (1306). If the Tx UE does not detect receiving a power reduction indication, it performs a unicast sidelink transmission as scheduled (1308).

[0239] For Rx UE, UE2 may attempt to decode the transmitted data and send feedback to UE 1. When UE2 fails to decode the data, it may send a NACK to UE 1.

[0240] The Rx UE behavior disclosed in the alternative case of Uu transmission preemption using higher power may also apply here.

[0241] Figure 14 An example of a disclosed process for an Rx UE to detect a power reduction indicator is shown in FIG1 for a sidelink UE having an inter-UE collision with a scheduled Uu transmission. The Rx UE receives a schedule for a unicast sidelink transmission (1401). The UE determines whether it detects a power reduction indication (1402). If so, it determines whether the received data is successfully decoded (1403). If so, it sends an ACK and flushes its buffer (1404). If not, it flushes the buffer of the preempted resource and decodes the retransmission (1405). If the UE does not detect a power reduction indication, the UE determines whether the received data is successfully decoded (1406). If so, it sends an ACK and flushes its buffer (1407). If not, the UE decodes the retransmission by soft combining (1408).

[0242] Use the cancel indicator to preempt low-priority SL transfers

[0243] In a third alternative, UE1 may monitor to detect whether it is preempted before performing a unicast sidelink transmission. If preemption occurs, the gNB may send a cancellation indication, instructing UE1 to cancel the scheduled transmission.

[0244] The scheme for sending cancellation indication disclosed for the dynamically scheduled broadcast sidelink can also be applied here. The gNB can send cancellation indication only to the Tx UE, or the gNB can send cancellation indication to both the Tx UE and the Rx UE. For the scheduling of retransmission, such as Figure 7 and Figure 8 The solutions presented for dynamically scheduled broadcasts can also be applied here.

[0245] For the Tx UE, upon detecting the cancellation indication, the UE1 will not perform all or part of the scheduled transmission as instructed and will retransmit later.

[0246] In one case, UE1 can retransmit and send preemption information to UE2 to instruct UE2 to flush the buffer accordingly.The solutions disclosed in the alternative case of preemption using higher power Uu transmission can also be applied here.

[0247] In another case, the gNB may send a cancellation indication to both the Tx UE and the Rx UE. UE1 may retransmit without sending preemption information.

[0248] In yet another case, if UE1 detects a cancellation indication before sending SCI (e.g., first phase) for the scheduled sidelink transmission, UE1 may not send SCI (e.g., both first phase SCI and second phase SCI) to UE2. Alternatively, if SCI (e.g., first phase SCI) has already been sent when the cancellation indication is detected, UE1 may send another indication to UE2 to ignore the sidelink transmission indicated by the previous SCI. This indication may be a reference signal, a preamble, a sequence, or an SCI, for example, using a preemption indication field in the second phase SCI.

[0249] The example provided for the above case can be applied when there is a time interval between the transmission of the first-stage SCI and the second-stage SCI. In another example, the first-stage SCI and the second-stage SCI can be transmitted without any time interval between them. For example, the first-stage SCI and the second-stage SCI can be frequency-division multiplexed (FDM) and transmitted together with the data; or the first-stage SCI and the second-stage SCI can be transmitted in consecutive symbols, etc. In this case, the Tx UE (e.g., UE1) cannot detect the cancellation indication of the initial transmission and cancel it. However, the Tx UE can monitor and detect the cancellation indication for the reserved retransmission (e.g., retransmission based on repetition or HARQ); or the cancellation indication for the reserved periodic transmission. UE1 can send another indication to UE2 to ignore the sidelink transmission indicated by the previous SCI, such as the reserved retransmission or the reserved periodic transmission. Such an indication (e.g., a preemption indication field) can be carried by the first-stage SCI or can be carried by the second-stage SCI.

[0250] For example, the preemption indication field in the second stage SCI may be a one-bit field, where '1' indicates that the scheduled sidelink transmission is preempted; and '0' indicates that the scheduled sidelink transmission is not preempted, and vice versa.

[0251] In one example, when a Tx UE detects that a scheduled sidelink transmission on the PSSCH is preempted by another transmission, the Tx UE may discard the PSSCH transmission. The Tx UE may only transmit the second-stage SCI (or a symbol carrying the second-stage SCI) and set the preemption indication field to "1." When the Rx UE decodes the received second-stage SCI and determines that the preemption indication field is set to "1," the Rx UE may determine that the associated PSSCH transmission is preempted and not soft-combine it with other transmissions on the same TB.

[0252] In another example, the Tx UE may discard both the transmission of the second-stage SCI and the transmission of the associated PSSCH. When the Rx UE fails to decode the second-stage SCI that should have been sent in the resources indicated by the first-stage SCI, the Rx UE will not be able to decode the associated PSSCH and will not soft-combine it with other transmissions of the same TB.

[0253] In yet another example, the Tx UE may discard both the transmission of the second-stage SCI and the transmission of the associated PSSCH, and use the resources indicated by the first-stage SCI where the second-stage SCI should have been transmitted to transmit an indication. The indication may be a preconfigured reference signal, a preconfigured preamble, or a preconfigured sequence. For example, the Rx UE may be configured with an initializer value, such as c init,CIWhen the Rx UE detects that the preconfigured reference signal / sequence is transmitted on the resource where the second stage SCI should have been transmitted, the Rx UE may determine that the associated PSSCH has failed and not soft combine it with other transmissions of the same TB.

[0254] When the Tx UE detects that the transmission of the second-stage SCI is preempted by other transmissions, the Tx UE may drop both the transmission of the second-stage SCI and the transmission of the associated PSSCH.

[0255] The solutions disclosed herein for unicast side link transmission may also be applied to broadcast side link transmission and multicast side link transmission.

[0256] When UE1 does perform a retransmission, it may retransmit the entire TB or it may retransmit only a subset of the TB, eg, the preempted symbols, PRBs and / or CBGs.

[0257] Figure 15 An example of a disclosed process for a Tx UE to detect a cancellation indication is shown for a sidelink UE that has an inter-UE conflict with a scheduled Uu transmission. The Tx UE receives a schedule for a unicast sidelink transmission (1501). The UE monitors for a cancellation indication (1502). The UE determines whether it has detected a cancellation indication (1503). If not, the UE performs the unicast sidelink transmission as scheduled (1506). If yes, the UE cancels the transmission indicated in the cancellation indication (1504). The UE retransmits without sending preemption information to the Rx UE (1505).

[0258] In one scenario, for an Rx UE, UE2 may receive a cancellation indication from the gNB. Depending on when the cancellation indication is received, UE2 may either ignore the scheduled sidelink transmission or flush the buffer for the cancelled resources when decoding retransmissions.

[0259] In another case, UE2 may receive a retransmission and a preemption indication from UE 1. UE2 may flush its buffer and decode the retransmission.

[0260] In yet another scenario, UE2 may receive an indication from UE1 to ignore a scheduled sidelink transmission because it has been canceled by the gNB. UE2 may ignore the previously received SCI and not attempt to decode the data. Alternatively, the indication from UE1 may indicate that some of the resources in the scheduled sidelink transmission are preempted. UE2 may flush its buffers and decode the retransmission.

[0261] Figure 16An example of a disclosed process for an Rx UE to detect a cancellation indication is shown for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The Rx UE receives a schedule for a unicast sidelink transmission (1601). The UE determines whether a cancellation indication is detected before the scheduled transmission occurs (1602). If not, the Rx UE determines whether the received data is successfully decoded (1603). If yes, the UE sends an ACK and flushes its buffer (1604). If not, the UE sends a NACK and receives a retransmission (1605). The UE then decodes the retransmission through soft combining (1607). If the cancellation indication is detected before the scheduled transmission occurs (1602), the Rx UE ignores the scheduled unicast sidelink reception (1608) and receives the retransmission (1609).

[0262] The dynamically scheduled Uu transmission preempts the dynamically scheduled multicast side link transmission

[0263] This section describes a solution for situations where a dynamically scheduled Uu transmission conflicts with a dynamically scheduled multicast sidelink transmission. In a multicast scenario, a Transmitter (TX) UE needs to send data to multiple Receiver (RX) UEs and receive ACK / NACKs from all or some of the RX UEs. Because the channels between the TX and RX UEs within a group may differ, some RX UEs may successfully decode a multicast transmission, while others may fail to do so. The Uu transmission described herein can be either a downlink transmission or a dual-link uplink transmission.

[0264] Assume that UE1 is dynamically scheduled by the gNB to send a multicast transmission on the sidelink as a Tx UE; UE2,1, UE2,2,…UE2,k are Rx UEs that will receive the multicast sidelink from UE1; and assume that UE3 is dynamically scheduled by the gNB to have a transmission or reception on the Uu interface (e.g., PDSCH or PUSCH), where some or all of the resources allocated to UE3 temporally overlap with the resources allocated to UE1. To handle inter-UE contention, the multicast sidelink transmission can be preempted in the following alternative scenarios.

[0265] Preemption of Uu transmissions using higher power

[0266] In the first alternative case, UE1 will perform multicast sidelink transmission regardless of whether it receives preemption.

[0267] To maintain the performance of transmitting / receiving higher priority data to / from UE3, Uu transmissions may be performed at a higher power level than for a scenario without inter-UE contention, using a similar scheme proposed in the dynamically scheduled broadcast sidelink case.

[0268] For a Tx UE, after UE1 performs a multicast sidelink transmission, it monitors the feedback (e.g., ACK / NACK) sent by the Rx UE via the PSFCH. UE1 can also monitor the indication sent by the gNB to determine whether its transmission has been preempted. The monitoring timing can be configured by RRC.

[0269] When UE1 sends a multicast message, one beam can be used to multicast the message to all Rx UEs.

[0270] The Tx UE behavior disclosed in the alternative case of preemption using higher power Uu transmissions can also be applied here together with the feedback sent by the scheduled Rx UE.

[0271] When UE1 sends a multicast message, multiple beams can be used to multicast the message to Rx UEs in different directions, where different beams are time-, frequency-, and / or spatially multiplexed. UE1 can monitor each beam separately and detect whether it is preempted through explicit or implicit signaling. For example, a bitmap can be used to indicate which beams are preempted. Alternatively, if the beams are time-division multiplexed (TDM) and / or frequency-division multiplexed (FDM), the UE can determine preemption based on the preempted time and frequency resources. The procedures and behaviors disclosed for multicast using one beam can also be applied here.

[0272] When UE1 performs retransmission, it can retransmit the entire TB or it can retransmit only a subset of the TB, such as the preempted symbols, PRBs, or CBGs. When multiple beams are used for multicast, UE1 can retransmit the multicast message on all beams or it can retransmit the multicast message on the preempted beams.

[0273] When an inter-UE collision occurs, the gNB can allocate resources for retransmission to UE1 without receiving feedback from UE1. Alternatively, the gNB can allocate resources for retransmission based on feedback from UE1. The same scheme proposed in the alternative case of detecting preemption after the initial transmission of unicast can also be applied here.

[0274] Figure 17An example of a disclosed process for a Tx UE to detect a preemption indication is shown in FIG1 for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The Tx UE receives a schedule for a multicast sidelink transmission (1701). The Tx UE performs a multicast sidelink transmission on the scheduled resources using beam 1, beam 2, and beam 3 (1702). The Tx UE receives feedback from the Rx UE (1703). The Tx UE determines whether the transmission on the three beams was successful (1704). If so, the Tx UE's transmission was successful and flushes its buffer (1708). If not, the Tx UE determines whether it detected a preemption (1705). If not, the Tx UE retransmits its transmission for the failed beam (1706). If yes, the Tx UE retransmits and sends preemption information about the failed beam (1707).

[0275] For an Rx UE that successfully decodes the multicast message, the Rx UE may ignore subsequent scheduling of retransmissions for failed UEs.

[0276] For an Rx UE that fails to decode the message, the disclosed Rx UE behavior for preemption of Uu transmission using higher power in unicast scenarios can also be applied here.

[0277] Figure 18 An example of a disclosed process for an Rx UE to detect preemption is shown in FIG1 for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The Rx UE receives a schedule for multicast sidelink reception (1801). The Rx UE determines whether the data it received was successfully decoded (1802). If yes, if the UE is scheduled to send feedback, it sends an ACK, flushes its buffer, and ignores the scheduling of retransmissions (1809). If no, the UE determines whether it detects preemption (1803). If no, if it is scheduled to send HARQ feedback, it sends preemption information along with the HARQ feedback and decodes the retransmissions via soft combining (1807). If the UE does detect preemption (1803), the UE determines whether it is scheduled to send HARQ feedback (1804). If yes, the Rx UE sends the preemption information along with the HARQ feedback, flushes its buffer, and decodes the retransmissions (1805). If the Rx UE determines that it is not scheduled to send HARQ feedback (1804), the Rx UE flushes its buffer and decodes the retransmission (1806).

[0278] For retransmission scheduling, such as Figure 3 、 Figure 4 、 Figure 5 The solutions presented for dynamically scheduled broadcasts can also be applied here.

[0279] Use adjusted transmission control parameters to preempt low priority SL transmissions

[0280] In the second alternative, the gNB can send an indication to UE1 to adjust the transmission control parameters before UE1 performs the scheduled initial multicast transmission. The scheme for sending the power reduction indicator disclosed for the dynamically scheduled broadcast sidelink can also be applied here. The gNB can send the power reduction indicator only to the Tx UE, or the gNB can send the power reduction indicator to both the Tx UE and the Rx UE. For the scheduling of retransmissions, such as Figure 7 and Figure 8 The solutions presented for dynamically scheduled broadcasts can also be applied here.

[0281] The Tx UE behavior disclosed in the alternative case of preemption of Uu transmissions using higher power in multicast scenarios can also be applied here.

[0282] When multiple beams are used to multicast messages to RX UEs in different directions, UE1 can monitor each beam separately to detect whether it is preempted. Assume that three beams are used for multicast. For example, if beam 1 is preempted but beams 2 and 3 are not, UE1 can reduce the transmission power of only beam 1. The procedures and behaviors disclosed for multicast using a single beam also apply here.

[0283] Figure 19 An example of a disclosed process for a Tx UE to detect a power reduction indicator is shown in FIG1 for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The Tx UE receives a schedule for multicast sidelink transmissions on beam 1, beam 2, and beam 3 (1901). The UE monitors whether a reduced power transmission is sent (1902). The UE determines whether it detects a reduced power indication (1903). If not, the UE performs the multicast sidelink transmission as scheduled (1908). If yes, and the UE detects that beam 1 is preempted, the UE reduces the power used for the transmission on beam 1 and transmits on beams 2 and beam 3 as scheduled (1904). The Tx UE determines whether the multicast on beam 1 is successful (1905). If yes, the UE sends the transmission and flushes its buffer (1907). If no, the UE retransmits and sends the preemption information to the Rx UE (1906).

[0284] The Rx UE behavior disclosed in the alternative case of preemption of Uu transmissions using higher power may also be applied here.

[0285] Figure 20An example of a disclosed process for an Rx UE to detect a power reduction indicator is shown in FIG. 2 for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The Rx UE receives a schedule for unicast sidelink transmission reception (2001). The UE determines whether it detects a reduced power indication (2002). If not, the UE determines whether its received data is successfully decoded (2003). If not, the UE decodes a retransmission via soft combining (2005). If yes, if the UE is scheduled to send an ACK, it sends an ACK, flushes its buffer, and ignores the scheduling of the retransmission (2004). If the Rx UE determines (2002) that no power reduction indication is detected, the Rx UE determines whether the received data is successfully decoded (2006). If yes, if the Rx UE is scheduled to send an ACK, it sends an ACK, flushes its buffer, and ignores the scheduling of the retransmission (2007). If not, the Rx UE flushes its buffer for the preempted resource and decodes the retransmission (2008).

[0286] Use the adjusted transmission control parameter cancel indicator to preempt low priority SL transmission

[0287] In a third alternative, UE1 may monitor to detect if it is preempted before performing a multicast sidelink transmission. If preemption occurs, the gNB may send an indication to instruct UE1 to cancel the scheduled transmission and, in some cases, also indicate the preemption to the UE receiving the SL.

[0288] The scheme for sending cancellation indication disclosed for the dynamically scheduled broadcast sidelink can also be applied here. The gNB can send cancellation indication only to the Tx UE, or the gNB can send cancellation indication to both the Tx UE and the Rx UE. For the scheduling of retransmission, such as Figure 7 and Figure 8 The solutions presented for dynamically scheduled broadcasts can also be applied here.

[0289] For the Tx UE, by detecting the cancellation indication, the UE1 will not perform all or part of the scheduled transmission as instructed and will retransmit later.

[0290] When UE1 sends a multicast message, one beam can be used to multicast the message to all Rx UEs.

[0291] The Tx UE behavior disclosed in the alternative case of preemption of Uu transmissions using higher power in multicast scenarios can also be applied here.

[0292] In addition to the disclosed Tx UE behavior, if UE1 detects a cancellation indication before sending the SCI for a scheduled sidelink transmission, UE1 must not send the SCI to the Rx UE. Alternatively, if the SCI has already been sent when the cancellation indication is detected, UE1 may send another indication to the receiving UE to ignore the sidelink transmission indicated by the previous SCI.

[0293] When UE1 sends a multicast message, multiple beams can be used to multicast the message to Rx UEs in different directions. UE1 can monitor each beam separately to detect whether it is preempted. Assume that three beams are used for multicast. For example, if beam 1 is preempted but beams 2 and 3 are not, UE1 can cancel the transmission on beam 1 only. The procedures and behaviors disclosed for multicast using a single beam also apply here.

[0294] Figure 21 An example of a disclosed process for a Tx UE to detect a cancellation indication is shown for a sidelink UE that has an inter-UE conflict with a scheduled Uu transmission. The Tx UE receives a schedule for a multicast sidelink transmission (2101). The UE monitors whether a cancellation indication has been sent (2102). The UE determines whether it detects the cancellation indication (2103). If not, the UE performs the multicast sidelink transmission as scheduled (2109). If yes, the UE cancels the transmission indicated in the cancellation indication (2104). The UE determines whether there is sufficient time to forward the cancellation indication to the Rx UE before the scheduled initial transmission (2105). If not, the Tx UE retransmits and sends preemption information to the Rx UE (2106). If yes, the Tx UE sends an indication to the Rx UE to ignore the scheduled multicast transmission (2107) and it retransmits (2108).

[0295] For Rx UE, in one case, the Rx UE may receive a cancellation indication from the gNB and may ignore the scheduled sidelink transmission or may flush the buffer of the cancelled resources when decoding the retransmission.

[0296] In another case, the Rx UE may receive a retransmission and a preemption indication from UE 1. The Rx UE may flush the buffer and decode the retransmission.

[0297] In yet another scenario, the Rx UE may receive an indication from UE1 to ignore a scheduled sidelink transmission because it was canceled by the gNB. The Rx UE may ignore the previously received SCI and not attempt to decode the data. Alternatively, the indication from UE1 may indicate that some of the resources in the scheduled sidelink transmission were preempted. The Rx UE may flush its buffer and decode the retransmission.

[0298] Figure 22 An example of a disclosed process for an Rx UE to detect a cancellation indication is shown in FIG2 for a sidelink UE that has an inter-UE collision with a scheduled Uu transmission. The Rx UE receives a schedule for unicast sidelink reception (2201). The UE determines whether its received data was successfully decoded (2202). If so, the UE sends an ACK and flushes its buffer (2207). If not, if the UE is scheduled to send feedback, the UE sends a NACK (2203). The UE determines whether it received preemption information along with a retransmission (2204). If not, the UE decodes the retransmission by soft combining (2205). If yes, the Rx UE flushes its buffer for the preempted resource and decodes the retransmission (2206).

[0299] Uu transmission preempts sidelink transmission based on configuration authorization

[0300] This section discloses a solution for the case where a sidelink transmission based on a configuration grant is preempted by a dynamically scheduled Uu transmission. The Uu transmission herein can be a downlink transmission or an uplink transmission.

[0301] When resources are allocated to a UE via a configured grant for sidelink transmission, the allocated resources can be dedicated to that UE. For example, time and frequency resources are allocated to only one UE as a configured grant. At the same time, the gNB will not schedule any other SL or Uu transmissions on these resources. Alternatively, the allocated resources can be shared with other UEs. For example, the gNB can schedule another high-priority Uu or SL transmission on these resources as needed. The same time and frequency resources can also be allocated to multiple UEs as a configured grant. If the allocated resources are dedicated to a single UE, the UE does not need to worry about inter-UE conflicts. However, when the allocated resources are shared with other UEs, the UE may experience inter-UE conflicts when performing sidelink transmissions using the configured grant resources.

[0302] For example, in configuration grant type 1, the RRC configuration in the configuration grant may carry an RRC parameter to indicate to the UE whether the configuration grant is shared with other UEs or dedicated to the UE itself. For example, the RRC parameter ConfiguredGrantShared with possible values of "yes" and "no" may be used; or the RRC parameter ConfiguredGrantSharingStatus with possible values of "shared" and "dedicated" may be used.

[0303] In configuring Grant Type 2, such an indication can be provided by RRC or Activation DCI. When using RRC, the same approach as for configuring Grant Type 1 also applies to configuring Grant Type 2. Alternatively, when using Activation DCI, a new field can be introduced in the Activation DCI for this purpose. An example of the Shared Status Indicator field is shown in Table 3. Alternatively, a single bit can be used in this field, where '0' indicates that the activated resources are dedicated to the UE, and '1' indicates that the activated resources are shared with other transmissions.

[0304] In various embodiments herein, sidelink configuration grant types 1 and 2 may be equivalent to Uu UL configuration grant types 1 and 2; or Uu UL configuration grant types 1 and 2 may be used as a baseline, but with potential enhancements.

[0305] Table 3 Activate the shared status indicator field in the DCI

[0306]

[0307] When a UE is configured / indicated with a dedicated configuration grant, when the UE has data to send, the UE can directly send on the configured CG resources. On the other hand, when a UE is configured / indicated with a shared configuration grant, when the UE has data to send on the configuration grant resources, the UE can apply the following proposed inter-UE conflict handling solution.

[0308] In an alternative scenario, whenever it schedules resources where some of them overlap with resources for a configured grant occasion (e.g., configured grant occasion k), the gNB may send an indication (e.g., a cancellation indicator) to indicate that there may be a potential inter-UE conflict. This indication may be a preemption indication as disclosed in the previous section, or a power reduction indicator, or a cancellation indication. Meanwhile, the UE configured with the configured grant may have data to send at the configured grant occasion k, or the UE may not have data to send.

[0309] If any UE determines to transmit data at a configured grant opportunity k, the UE can monitor and detect the indication sent by the gNB (e.g., before performing a sidelink transmission). The UE can then determine that it is preempted and handle this issue for broadcast, multicast, and unicast using the procedures disclosed for handling inter-UE conflicts between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions. In general, the solutions proposed for dynamically scheduled broadcast, multicast, and unicast can also be applied here.

[0310] In one example, when a Tx UE is configured to transmit multiple repetitions of the same TB on the sidelink using configured granted resources, and the Tx UE detects (e.g., by detecting and decoding a cancellation indicator) that one or some of these repetitions are preempted by other transmissions, the Tx UE cannot transmit the preempted repetition(s) (e.g., repetitions overlapping with the canceled resources) while still transmitting the non-preempted repetition(s). The Tx UE may then monitor feedback (e.g., ACK / NACK feedback) from the Rx UE to determine whether the transmission was successful. If the transmission failed, the Tx UE may send an indication to the gNB to request scheduling of a retransmission, for example, the indication may be NACK feedback.

[0311] When all repetitions are preempted, the UE may discard all repeated transmissions and send an indication to the gNB to request scheduling of retransmissions. An example of the disclosed procedure is Figure 23 As shown in FIG. 23 . The UE receives information about configured grant resources for sidelink transmission ( 2301 ). The UE determines whether the configured grant is dedicated to the UE ( 2302 ). If so, the UE uses the configured grant when the UE has data to transmit ( 2311 ). If not, the UE determines whether the UE has data to transmit at the next configured grant opportunity ( 2303 ). If so, the UE monitors and detects whether it is preempted ( 2304 ). The UE monitors to detect preemption ( 2304 ). The UE determines whether preemption is detected ( 2305 ). If not, the UE transmits data at the next configured grant opportunity ( 2310 ). If preemption is detected ( 2305 ), the UE determines whether all repetitions are preempted ( 2306 ). If so, the UE sends an indication to the gNB requesting resources for the transmission ( 2309 ). If not all repetitions are preempted ( 2306 ), the UE transmits the repetitions that were not preempted at the next configured grant opportunity ( 2307 ). The UE determines whether the Rx UE successfully received the transmission ( 2308 ). If not, the Tx UE sends an indication to the gNB to request resources for transmission (2309).

[0312] In another example, when the Tx UE detects that at least one repetition is preempted by other transmissions, the Tx UE may discard all repeated transmissions and may send an indication to the gNB to request scheduling of retransmissions.

[0313] Alternatively, the UE may monitor and detect that there is no preemption on the configured grant occasion k. The UE may then perform sidelink transmission using the resources in the configured grant occasion k.

[0314] The indication (e.g., NACK feedback) sent to the gNB to request scheduling of retransmissions on the sidelink may be sent on the PUCCH or PUSCH.

[0315] In order to enable the Rx UE to appropriately soft combine repetitions of the same TB, the Tx UE may send an indication to the Rx UE to indicate which repetition is preempted. Such an indication may be carried by the PSCCH associated with the PSSCH configured in the configuration grant. For example, an L-bit bitmap may be sent using the preemption indication field in the CG-SCI, where L is equal to the number of repetitions configured for the configuration grant. If the i-th bit (i=1, 2,…, L) in the bitmap is indicated as '0', the Rx UE may determine that the i-th repetition is sent and may soft combine it with other repetitions; if the i-th bit in the bitmap is indicated as '1', the Rx UE may determine that the i-th repetition is preempted and may not be soft combined with other repetitions, and vice versa.

[0316] In yet another example, a Tx UE may be configured with multiple configuration grants. When the Tx UE determines to transmit data on one configuration grant (e.g., configuration grant A) and detects that it is preempted by another transmission, it may discard the transmission on configuration grant A and perform a transmission on another configuration grant (e.g., configuration grant B). For example, configuration grant B may be the next available configuration grant among all configured CGs.

[0317] Alternatively, when the Tx UE determines to transmit data on a configured grant (e.g., configured grant A) and the Tx UE detects that it is preempted by another transmission, it cannot transmit the preempted repetition while transmitting the non-preempted repetition. If the Tx UE detects that the Rx does not receive the transmission, it can perform a retransmission on another configured grant (e.g., configured grant B). For example, configured grant B can be the next available configured grant in all configured CGs. In order to enable the Rx UE to soft-combine repetitions of the same TB in different configured grants, the Tx UE can indicate the same HARQ process ID, where the NDI field does not switch for transmissions in configured grant A and configured grant B. If no UE determines to transmit data on configured grant opportunity k, this indication can become an invalid message and no UE will monitor and detect it.

[0318] In this alternative case, the gNB does not know when the UE will transmit at the configured CG opportunity and therefore the gNB does not know whether to schedule a retransmission for the preempted sidelink transmission.

[0319] In one scenario (for example, when a UU UL transmission preempts a sidelink transmission), the gNB can monitor the received power level to determine whether another transmission is present in the channel. When the gNB detects the other transmission, although it cannot decode it, it can determine that an inter-UE collision has occurred. The gNB can then schedule a retransmission for the configured authorized UE. This approach can be applied to power-based inter-UE collision resolution.

[0320] In another case, when the V2X Tx UE has data to send in the CG opportunity and detects that it is preempted, the UE can send an indication to the gNB to request scheduling of retransmission instead of waiting for the next CG opportunity to retransmit. For example, the indication can be SR, BSR, NACK feedback, reference signal, preamble, or sequence. An example of the disclosed process is Figure 24 . The Tx UE receives a configured grant resource for sidelink transmission (2401). The UE determines whether the configured grant is dedicated to the UE (2402). If so, the UE uses the configured grant whenever the UE has data to transmit (2408). If not, the UE determines whether the UE has data to transmit at the next configured grant opportunity (2403). If so, the UE transmits the data at the next configured grant opportunity (2404). The UE monitors to detect whether it is preempted or receives a preemption indication (2405). The UE determines whether it detects preemption (2406). If so, the UE sends an indication to the gNB requesting resources for retransmission (2407).

[0321] In another alternative, when the UE determines to send data on a configured CG opportunity (e.g., CG opportunity k), the UE may send an indication to the gNB, notifying the gNB that it has data to send. For example, the indication may be an SR, a BSR, a reference signal, a preamble, or a sequence. The indication may be sent on a PUCCH resource preceding the configured grant resource. The time offset between the PUCCH and the configured grant opportunity may be fixed or configurable. Alternatively, the indication may be sent on a dedicated symbol(s) (e.g., the first symbol in the configured grant), or on some REs in the first symbol.

[0322] In this alternative scenario, if the gNB wishes to schedule an emergency transmission using the same resources, the gNB knows that there will be an inter-UE conflict. The gNB may send an indication to indicate this inter-UE conflict, where the indication may be a preemption indication, a power reduction indicator, or a cancellation indication, as disclosed in the previous section.

[0323] If the UE determines to transmit data at a configured grant opportunity k, the UE can monitor and detect whether it has been preempted. If the UE detects that it has been preempted, it can use the procedures disclosed for handling inter-UE conflicts between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle this issue for broadcast, multicast, and unicast. In general, the solutions proposed for dynamically scheduled broadcast, multicast, and unicast can also be applied here. If the UE does not detect that it has been preempted, the UE can transmit data at CG opportunity k without waiting for a new schedule.

[0324] Since the gNB is aware of inter-UE collisions, it can configure sidelink retransmissions for the UE without receiving feedback from the Tx UE. Alternatively, the gNB can schedule retransmissions based on feedback from the Tx UE, as disclosed in the dynamically scheduled multicast and unicast scenarios.

[0325] Meanwhile, when a UE with a configured grant (e.g., UE1) sends an indication to the gNB notifying it that it has data to send, UE1 can also indicate the priority of the data to be sent. By doing so, the gNB can determine whether it will schedule another transmission on the same resources. For example, if UE1 indicates that it has urgent data to send on the configured grant, the gNB cannot schedule another transmission on the same resources. Alternatively, if UE1 indicates that it has regular data to send on the configured grant, the gNB can schedule another, more urgent transmission on the same resources and send an indication of an inter-UE conflict to UE1.

[0326] Examples of public procedures are in Figure 25 . The UE receives a configured grant resource for sidelink transmission (2501). The UE determines whether the configured grant is dedicated to the UE (2502). If so, the UE uses the configured grant when the UE has data to send (2509). If so, the UE determines whether it has data to send at the next configured grant opportunity (2503). If so, the UE sends an indication to the gNB indicating that the UE has data to send (2504). The UE sends data on the configured grant (2505). The UE monitors and detects whether it is preempted (2506). The UE determines whether it detects preemption (2507). If so, the UE receives a retransmission schedule from the gNB and performs the retransmission (2508).

[0327] The disclosed solution can also be applied to conflicting scenarios where UE1 and UE2 participate in sidelink communication and decisions on Uu TX / RX grant and sidelink TX / RX grant are made by different entities.

[0328] The disclosed scheme may also be applied to a collision between two Uu transmissions, eg, a collision between two UL transmissions on the Uu interface.

[0329] Signaling of the sidelink cancellation indicator

[0330] Sidelink Cancel Indicator Monitoring

[0331] Since the gNB may determine to preempt a sidelink transmission (e.g., a sidelink transmission scheduled by a dynamic grant or a sidelink transmission performed on configured grant resources), the Tx UE may need to monitor a cancellation indicator (e.g., SL-CI) after the Tx UE receives a scheduling grant from the gNB or when the Tx UE determines to perform a sidelink transmission on a configured grant.

[0332] In one example, for a UE that is dynamically scheduled with sidelink transmission, the UE may monitor the SL-CI starting from the next timeslot after the timeslot carrying the dynamic grant.

[0333] Alternatively, in another example, the UE may be configured by the gNB to start from the k following the slot that carries the DCI for the scheduled sidelink transmission. 偏移，1 For example, k can be configured by RRC signaling. 偏移，1 k value. k can be configured for the UE through UE-specific RRC configuration 偏移，1 , for example, via the RRC parameter SLCIMonitorOffset configured in the SearchSpace information element. Alternatively, k may be configured for the UE via a cell-specific RR configuration. 偏移，1 , for example, through the RRC parameter SLCIMonitorOffset configured in the SIB, for example, OSI.

[0334] Alternatively, in yet another example, the UE may be configured by the gNB to start from the k seconds preceding the timeslot carrying the sidelink transmission scheduled by the dynamic grant. 偏移，2 The SL-CI is monitored starting from the time slot of k. 偏移，1 Similarly, k can be configured through RRC signaling 偏移，2 , for example, through UE-specific RRC configuration, or through cell-specific RRC configuration.

[0335] In one example, for a UE configured with a configuration grant for sidelink transmission, the UE may be configured by the gNB to start from the kth slot following the slot carrying the previously configured grant opportunity. 偏移，3 Alternatively, in another example, the UE may be configured by the gNB to monitor the SL-CI from the time slot k before the time slot carrying the next configuration grant opportunity. 偏移，4 Alternatively, in yet another example, the UE may start monitoring the SL-CI from the next time slot after the time slot carrying the previously configured grant opportunity.

[0336] For configuration authorization type 1 and configuration type 2, k 偏移，3 or k 偏移，4The value of can be configured by RRC, for example, through the RRC parameter SLCIMonitorOffset configured in the SLConfiguredGrantConfig information element.

[0337] In another approach, for configuration grant type 2, a set of k 偏移，3 or k 偏移，4 The activation DCI may carry a field (eg, SL CI monitoring offset field) to indicate to the UE one of the candidate values within the group.

[0338] In one example, for a UE scheduled with dynamic grant and a UE configured with a configured grant, the UE may be scheduled k seconds before the slot carrying the PSSCH. 停止 Stop SL-CI monitoring for k time slots or symbols, where k 停止 It may be the minimum processing time of the SL-CI and the time to prepare the updated SCI (eg, the second stage SCI).

[0339] Alternatively, in another example, the UE may be configured with a time window through RRC that the UE needs to monitor the SL-CI, for example, k mw time slots. The UE can start monitoring k time slots after the time slot mw Stop SL-CI monitoring for each time slot.

[0340] Determine the time zone of the SL-CI reference

[0341] After the UE detects the SL-CI, in order to understand the information it carries, the UE needs to determine the time region and frequency region referenced by the SL-CI.

[0342] For example, to determine the start of a time region, the timing offset between the SL-CI and the referenced time region can be indicated to the UE. In one example, the timing offset can be configured via RRC, for example, via the RRC parameter SLCITimeRegionOffset. The timing offset can be in symbols, or the timing offset can be in slots. The solution proposed for configuring the RRC parameter SLCIMonitorOffset can also be applied here.

[0343] In another example, the timing offset may be indicated by the DCI carrying the SL-CI. For example, the RRC may configure a set of timing offset values; and the DCI carrying the SL-CI may carry a field (e.g., an SL CI time offset field) to indicate to the UE one of the candidate values within the set.

[0344] In addition to the timing offset, the UE also needs to determine the duration of the time region. In one example, the duration can be explicitly configured by RRC via the RRC parameter SLCITimeRegionDuration, for example, 1 time slot or 2 time slots. The timing duration can be in symbols, or the timing offset can be in time slots. The solution proposed for configuring the RRC parameter SLCIMonitorOffset can also be applied here.

[0345] In another example, the timing duration may be indicated by a DCI carrying the SL-CI. For example, the RRC may configure a set of timing duration values; and the DCI carrying the SL-CI may carry a field (e.g., an SL CI duration field) to indicate to the UE one of the candidate values within the group. Alternatively, the timing duration may be indicated by the DCI through a start and length indicator value (SLIV) field, which indicates one of the possible combinations of start and duration values configured by the RRC. In the above example, the timing offset and duration are indicated separately. Alternatively, the timing offset and duration may be indicated jointly, for example, jointly indicated by the DCI carrying the SL-CI. For example, the RRC may configure a set of combinations of timing offset values and timing duration values; and the DCI carrying the SL-CI may carry a field (e.g., an SL CI time indication field) to indicate to the UE one of the candidate combinations within the group.

[0346] In some cases, the sidelink transmission and the Uu interface transmitting the SL-CI may have different subcarrier spacings (SCSs). In one example, the SCS of the sidelink transmission may be used as a reference SCS to determine the time region, e.g., the timing offset and duration are indicated in terms of the number of time slots or symbols on the sidelink. In another example, the SCS of the Uu interface may be used as a reference SCS to determine the time region, e.g., the timing offset and duration are indicated in terms of the number of time slots or symbols on the Uu interface.

[0347] Determine the frequency region of the SL-CI reference

[0348] At the same time, the UE also needs to determine the frequency region referenced by the SL-CI. In one example, the frequency region can be implicitly indicated, for example, the frequency region can be the entire sidelink BWP; or the frequency region can be a frequency band shared by Uu services and sidelink services.

[0349] In another example, the frequency region can be explicitly indicated relative to the sidelink BWP. For example, to determine the frequency region, the UE can be configured with the number of subchannel offsets relative to the lowest subchannel of the sidelink BWP, for example, via the RRC parameter SLCIFrequencyRegionOffset; and the number of subchannels occupied by the frequency region can be configured for the UE, for example, via the RRC parameter SLCIFrequencyRegionRange. In this example, the granularity of the RRC parameter is in units of the number of subchannels. The granularity of the RRC parameter can also be in units of the number of PRBs.

[0350] In yet another example, the frequency region may be explicitly indicated relative to a BWP on the Uu interface (e.g., an active UL BWP or an active DLBWP). For example, to determine the frequency region, the number of PRB offsets may be configured for the UE relative to the lowest PRB of the active UL BWP; and the number of PRBs occupied by the frequency region may be configured for the UE.

[0351] Determine when and how often resources are actually canceled

[0352] In the reference time zone and frequency zone, the gNB can use SL-CI to indicate the actual cancelled time-frequency resources.

[0353] In one example, the cancelled time resources and the cancelled frequency resources may be indicated separately. For example, the DCI carrying the SL-CI may contain two fields, time resource cancellation indicator and frequency resource cancellation indicator, to indicate the time and frequency resources actually cancelled, wherein the two fields may be b T The bitmap of the ones digit and b F The sizes of the two bitmaps can be pre-specified, or b T The value of b F The value of may be configured by the gNB, for example, via the RRC parameters SLCITimePayloadSize and SLCIFrequencyPayloadSize respectively. The UE may evenly divide the reference time region and the reference frequency region into b T Part b F For each part, if the associated bit in the bitmap is set to '1', the UE may determine that transmission on the part is cancelled.

[0354] In another example, the cancelled time resources and the cancelled frequency resources may be jointly indicated. For example, the DCI carrying the SL-CI may include a field side link cancellation indicator to indicate the actual cancelled time and frequency resources, where the field may be b TFThe size of the bitmap can be pre-specified, or b TF The value of may be configured by the gNB, for example, via the RRC parameter SLCIPayloadSize. The UE may evenly divide the reference time region and frequency region into b TF For example, the UE can evenly divide the reference domain into n parts. T Multiply by n F grids, where n T ×n F =b TF In order to determine how to divide the reference area, the UE needs to know n T The value of or n F One of the values ​​of .

[0355] UE can be configured with n T The value of, for example, is configured by the RRC parameter SLCINumberofTimeProtion.

[0356] Alternatively, the UE may be configured with the duration of each portion, for example, via the RRC parameter SLCITimeDurationPerProtion. Determined n T Then the UE can Determined n F value.

[0357] For each portion in the grid, if the associated bit in the bitmap is set to '1', the UE may determine that transmission on that portion is cancelled.

[0358] In the above example, the UE is indicated with information of time granularity. Alternatively, the UE can be indicated with information of frequency granularity and derive the value n from it. T , where similar schemes disclosed for signaling time granularity can also be applied to signaling frequency granularity.

[0359] Inter-UE contention handling in NR V2X Mode 1 with repeated sidelink transmissions scheduled by NB.

[0360] For example, in V2X Mode 1, a Tx UE may be scheduled by the gNB to send a sidelink transmission with multiple repetitions, such as Figure 26 shown.

[0361] The initial transmission and repetitions can be sent in adjacent time slots as shown. Alternatively, the time interval between the initial transmission and the repetitions can be several time slots.

[0362] Please note that Figure 26This section describes an example of a gNB scheduling a sidelink transmission with multiple repetitions. The gNB can also schedule a sidelink transmission with multiple HARQ-based retransmissions. Alternatively, the gNB can schedule periodic sidelink transmissions. In the following, the scheme is disclosed using a sidelink transmission with multiple repetitions as an example. The disclosed scheme can also be applied to sidelink transmissions with multiple HARQ-based retransmissions and periodic sidelink transmissions. For example, by replacing the repetitions in the scheme with HARQ-based retransmissions, the disclosed scheme can also be applied to sidelink transmissions with multiple HARQ-based retransmissions.

[0363] SL-CI is sent only before the initial transmission

[0364] In one example, the UE may assume that the SL-CI for the entire transmission (initial transmission and repetitions) may be signaled only once before the initial transmission.The Tx UE may monitor the SL-CI only before the initial transmission.

[0365] If SL-CI is detected and the Tx UE determines that all initial transmissions and repetitions are canceled, the Tx UE may discard the scheduled initial transmission and the scheduled repetition transmission. To indicate to the Rx that the transmission has been canceled, the Tx UE may discard both the second-stage SCI and the PSSCH transmissions; or, the Tx UE may discard the PSSCH transmission while still sending the second-stage SCI and setting the preemption indication field to '1' or '1111'; or, the Tx UE may discard both the second-stage SCI transmission and the associated PSSCH transmission, while using the resources that should have sent the second-stage SCI to send an indication indicating that the transmission has been canceled.

[0366] In one case, if SL-CI is detected and the Tx UE determines that one or some of the initial transmissions and repetitions are canceled, the Tx UE may discard all scheduled initial transmissions and repetitions. The Tx UE may use the above-proposed scheme to send an indication to the Rx UE to indicate that all scheduled transmissions are canceled.

[0367] In another case, when the Tx UE determines that one or some of the initial transmission and repetitions are cancelled, the Tx UE may discard only the transmissions overlapping with the cancelled resources. The Tx UE may use the preemption indication field in the second stage SCI to indicate the discarded transmissions to the Rx UE. The preemption indication field is a 4-bit bitmap. Assuming the situation is as follows Figure 26As shown. For example, assume that the Tx UE detects the SL-CI and determines that the first and third repetitions overlap with the cancelled resources. The Tx UE may discard the transmissions of the first and third repetitions while still sending the initial transmission and the second repetition. The Tx UE also sets the preemption indication field in the associated second-stage SCI to '0101' and sends it to the Rx UE.

[0368] When the Rx UE detects the indication sent by the Tx UE indicating cancellation of the scheduled sidelink transmission, the Rx UE shall not attempt to decode the corresponding PSSCH and shall not soft combine it with other transmissions of the same TB.

[0369] SL-CI is sent before the initial transmission and during repetitions. The Tx UE indicates preemption information in each repetition.

[0370] In another example, the SL-CI may be signaled by the gNB before the initial transmission and during the scheduled sidelink transmission (before the last repetition). The Tx UE may monitor the SL-CI before the initial transmission and continue monitoring until the last repetition. Figure 27 An example is shown in which the SL-CI is sent by the gNB between the 1st and 2nd repetitions of a scheduled sidelink transmission and indicates that the 2nd repetition is cancelled. It is also possible for one SL-CI to indicate that multiple repetitions are cancelled.

[0371] In this example, the Tx UE may only drop transmissions that overlap with the cancelled resources, e.g., initial transmissions or repetitions. Since the cancellation may occur after the initial transmission, the Tx UE cannot indicate preemption to the Rx UE using the second stage SCI associated with the initial transmission.

[0372] The Tx UE may send an indication in each repetition to indicate whether the sidelink transmission is preempted. The indication may be sent via a preconfigured reference signal (eg, SL-DMRS), via a preconfigured sequence, or via control information.

[0373] For example, the Tx UE sends both SCI (eg, second stage SCI) and data in all repetitions. An SCI field (eg, preemption indication field) may be carried by the second stage SCI associated with the PSSCH to indicate whether the sidelink transmission is preempted.

[0374] The preemption indication field in the second stage may be 1 bit, for example, '0' indicates that the associated PSSCH is not cancelled; and '1' indicates that the associated PSSCH is cancelled. This field may be used to indicate only whether the associated PSSCH transmission is preempted.

[0375] use Figure 27As an example, the Tx UE shall set the Preemption Indication field sent in the initial transmission, the 1st repetition, and the 3rd repetition to '0'; and the Tx UE shall set the Preemption Indication field sent in the 2nd repetition to '1'.

[0376] The preemption indication field in the second stage can be a bitmap, where the length of the bitmap is equal to the total number of initial transmissions and repetitions. This field can be used to indicate whether PSSCH transmissions for all initial transmissions and repetitions are preempted, for example, by setting the bit associated with the corresponding PSSCH in the bitmap to '1'. Based on the detected SL-CI, the Tx UE can set the bitmap sent in different repetitions to different values.

[0377] use Figure 27 As an example, the length of the bitmap is 4. Before sending the initial transmission and the first repetition, the Tx UE does not detect that any PSSCH transmission has been preempted. Therefore, the Tx UE sets the Preemption Indication field sent in the initial transmission and the first repetition to '0000' and '0000', respectively. Before sending the second repetition, the Tx UE detects that the PSSCH in the second repetition is preempted. The Tx UE sets the Preemption Indication field sent in the second repetition to '0010'. Before sending the third repetition, the Tx UE does not detect any further preemption. The Tx UE then sets the Preemption Indication field sent in the second repetition to '0010'.

[0378] SL-CI is sent before the initial transmission and during repetitions, and the Tx UE indicates preemption information only in the last repetition

[0379] Alternatively, the Tx UE may send an indication only in the last repetition to indicate whether the sidelink transmission is preempted. The indication may be sent via a preconfigured reference signal (e.g., SL-DMRS), or via a preconfigured sequence, or via control information.

[0380] For example, the Tx UE may send both SCI (eg, second-stage SCI) and data in the last repetition. An SCI field (eg, preemption indication field) may be carried by the second-stage SCI to indicate whether the sidelink transmission is preempted.

[0381] use Figure 27 As an example, the preemption information sent in the last repetition may be 4 bits.

[0382] In one approach, no dedicated SCI field can be introduced for sending preemption information in the second-stage SCI. In the initial transmission, the transmitting UE cannot indicate preemption information in the second-stage SCI. In the final repetition, the transmitting UE can reuse an existing field in the second-stage SCI to indicate preemption information. For example, the transmitting UE can reuse the first four bits of the MCS field carried in the second-stage SCI in the final repetition and set them to '0010' to indicate that repetition 2 is preempted and that other repetitions are not preempted.

[0383] In another approach, a dedicated SCI field can be introduced to transmit preemption information in the second-stage SCI, for example, a 4-bit SCI field called the Preemption Indication field. Such a field can be carried by the second SCI sent in both the initial transmission and the final repetition. For example, before the initial transmission, the transmitting UE does not detect any preemption. The transmitting UE may set the Preemption Indication field in the initial transmission to '0000'. Before the final repetition, the transmitting UE detects that the second repetition has been preempted. The transmitting UE may set the Preemption Indication field in the final repetition to '0010'.

[0384] The three schemes disclosed herein use the case where there is a time interval between the transmission of the first-stage SCI and the second-stage SCI as an example. In another case, the three schemes disclosed herein can also be applied to the case where the first-stage SCI and the second-stage SCI can be transmitted without any time interval between them, such as Figure 28 As shown. In this case, the SL-CI sent by the gNB to the Tx UE may be sent only before the initial transmission, or may be sent before the initial transmission and during repetitions. The SL-CI sent by the Tx UE to the Rx UE to indicate preemption information may be sent only in the initial transmission, or may be sent in both the initial transmission and all repetitions, or may be sent in the initial transmission and only in the last repetition. The preemption information (e.g., the disclosed preemption indication field) may be carried by the first-stage SCI or by the second-stage SCI.

[0385] When the first-stage SCI and the second-stage SCI are sent without any time interval between them, the disclosed scheme can be applied to sidelink transmissions with multiple repetitions, such as Figure 28 The disclosed scheme can be applied to sidelink transmission with multiple HARQ-based retransmissions and can also be applied to periodic sidelink transmissions.

[0386] Intra-UE prioritization for simultaneous sidelink and uplink transmissions

[0387] In NR V2X, a UE may be scheduled to perform simultaneous sidelink and uplink transmissions, where the carriers for the sidelink transmissions and the uplink transmissions may be different carriers or may be shared carriers. In some scenarios (e.g., where the total transmit power exceeds the maximum power P C9AX ), the UE needs to prioritize among them to adjust the transmit power or even drop the low-priority transmissions. In this section, we disclose the mechanism for the UE to prioritize simultaneous sidelink and uplink transmissions.

[0388] Prioritization using the indicated priority indicators

[0389] In one example, each transmission (e.g., sidelink transmission or uplink transmission) can be indicated as having a priority. The value of the priority can be explicitly signaled by RRC, such as through the RRC parameter TransmissionPriorityLevel, or pre-specified by the specification. For sidelink transmissions, the TransmissionPriorityLevel can be configured within the information element that configures the resource pool (e.g., SLResourcePoolConfig).

[0390] In one example, a priority can be configured / pre-assigned for the transmission of SL-PSCCH, SL-PSSCH, and SL-PSFCH. For example, SL-PSCCH, SL-PSSCH, and SL-PSFCH can share the same resource pool. Within the resource pool configuration, a priority is configured that is used for SL-PSCCH, SL-PSSCH, and SL-PSFCH.

[0391] In another example, SL-PSCCH, SL-PSSCH, and SL-PSFCH may share the same resource pool. Different priorities may be configured / pre-assigned for the transmission of SL-PSCCH, SL-PSSCH, and SL-PSFCH, respectively. For example, within the resource pool configuration, the RRC parameters SLPSCCHPriorityLevel, SLPSSCHPriorityLevel, and SLPSFCHPriorityLevel may be configured separately for the UE.

[0392] In yet another example, dedicated resource pools may be configured / pre-designated separately for SL-PSCCH, SL-PSSCH, and SL-PSFCH, where different priorities may be configured within the associated resource pool configurations, respectively.

[0393] Priority can also be signaled by the DCI that schedules the sidelink transmission. For example, to indicate the priority of the SL-PSSCH, a set of priority values can be configured or pre-specified by RRC; and the DCI for scheduling can carry a field (e.g., PSCCH Priority) to indicate to the UE one of the candidate values within the group.

[0394] Priorities may also be derived implicitly. For example, the priority of SL-PSFCH may be equal to the priority indicated for SL-PSSCH.

[0395] For PSCCH, the same priority can be indicated for the first-stage SCI and the second-stage SCI. Alternatively, different priorities can be indicated for the first-stage SCI and the second-stage SCI separately, for example, by two RRC configurations SL1stSCIPriorityLevel and SL2ndSCIPriorityLevel, respectively.

[0396] For PSFCH, the same priority may be indicated for HARQ-ACK feedback and CSI feedback. Alternatively, different priorities may be indicated separately for HARQ-ACK feedback and CSI feedback, for example, by two RRC configurations SLHARQPriorityLevel and SLCSIPriorityLevel, respectively. When a UE has simultaneous sidelink and uplink transmissions, the UE may prioritize transmissions with higher priorities, for example, transmissions with smaller priority values may be given priority.

[0397] When sidelink transmissions and uplink transmissions have the same priority value, sidelink transmissions (except SL CSI feedback), eg, SL-PSCCH, SL-PSSCH, and SL HARQ feedback, may be prioritized.

[0398] When SL CSI feedback and uplink transmission have the same priority value, uplink transmission (except CSI feedback on uplink), eg, SR, HARQ feedback, PUSCH, may be prioritized.

[0399] When SL CSI feedback and CSI feedback on uplink have the same priority value, SL CSI feedback may be prioritized.

[0400] Alternatively, when the sidelink transmission and the uplink transmission have the same priority value, the UE may prioritize the transmission based on some criteria, some examples of which are shown below:

[0401] Channel conditions: To ensure performance, the UE can prioritize transmissions based on channel conditions. For example, the UE can prioritize transmissions with better channels. Therefore, it has a higher probability of being delivered.

[0402] Package size: Because transmissions with higher priority may preempt other transmissions, a UE may prioritize transmissions that require less resources to reduce potential preemption of other UEs.

[0403] The remaining time before the UE must drop the packet: Two transmissions may have different processing timelines and therefore different remaining times before the packet must be dropped. The UE may prioritize the transmission with the shorter remaining time to reduce the drop rate.

[0404] Priority sorting without a specified priority indicator

[0405] In another example, sidelink transmissions may be classified into URLLC SL transmissions and eMBB SL transmissions, where the UE may determine the category of transmission based on QoS requirements, service type, etc. Similarly, uplink transmissions may be classified into URLLC UL transmissions and eMBB UL transmissions.

[0406] The UE may prioritize transmissions according to the following priority sorting rules:

[0407] URLLC SL transmission (excluding SL CSI feedback) > URLLC UL transmission (excluding UL CSI feedback) > URLLC SLCSI feedback > URLLC UL CSI feedback > eMBB SL transmission (excluding SL CSI feedback) > eMBB UL transmission (excluding UL CSI feedback) > eMBB SL CSI feedback > eMBB UL CSI feedback.

[0408] Where 'A>B' means that the transmission of A takes precedence over the transmission of B.

[0409] Note: All SL CSI feedbacks with the same priority as eMBB SL CSI feedbacks can be treated equally; and all UL CSI feedbacks with the same priority as eMBB UL CSI feedbacks can be treated equally. The prioritization rule can then become:

[0410] URLLC SL transmission (excluding SL CSI feedback) > URLLC UL transmission (excluding UL CSI feedback) > eMBB SL transmission (excluding SL CSI feedback) > eMBB UL transmission (excluding UL CSI feedback) > SL CSI feedback > UL CSI feedback.

[0411] The dynamically scheduled side link transmission preempts the other side link transmission

[0412] In NR V2X Mode 1, it is possible to allocate overlapping resources for two dynamically scheduled sidelink transmissions, such as Figure 29 As shown in the figure, for example, UE1 is dynamically allocated resources for sidelink transmission. The gNB may then determine to allocate some overlapping resources to UE2 and preempt UE1's transmission, for example, because UE2 may have more urgent data to send. Consequently, an inter-UE collision will occur. This inter-UE collision may occur on a shared carrier, or it may occur on a dedicated carrier. In this section, we disclose an inter-UE collision handling solution for such scenarios.

[0413] In an alternative case, the inter-UE conflict may be transparent to UE2. To indicate the inter-UE conflict to UE1, the gNB may send an indication to UE1, where the indication may be a preemption indication, a power reduction indicator, or a cancellation indication, as disclosed in the previous section.

[0414] UE1 can monitor and detect whether it is preempted by the gNB. If UE1 determines it is preempted, it can use the procedures disclosed for handling inter-UE contention between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle broadcast, multicast, and unicast traffic. In principle, the solutions proposed for dynamically scheduled broadcast, multicast, and unicast traffic can also be applied here.

[0415] In another alternative, the gNB can indicate the inter-UE conflict to UE2 and let UE2 know that it will preempt other transmissions. This can be done, for example, via a scheduling DCI with an explicit bit field, or it can be signaled implicitly. Once UE2 determines that it will preempt other transmissions, UE2 can send an indication indicating the inter-UE conflict. This indication can be a preemption indication, a power reduction indicator, or a cancellation indication, as disclosed in the previous section. This indication can be a preamble, a sequence, a reference signal, a broadcast SCI, or the broadcast portion of a two-phase SCI.

[0416] UE1 can monitor and detect whether it is preempted by another V2X UE. If UE1 determines it is preempted, it can use the procedures disclosed for handling inter-UE conflicts between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle broadcast, multicast, and unicast traffic. In principle, the solutions proposed for dynamically scheduled broadcast, multicast, and unicast traffic can also be applied here.

[0417] Sidelink transmissions based on configured grants are preempted by dynamically scheduled sidelink transmissions.

[0418] In NR V2X Mode 1, the UE may be allocated with configured granted resources for sidelink transmission. At the same time, the gNB may dynamically allocate some overlapping resources to another UE, such as Figure 30 As shown in Figure 1. For example, UE1 is allocated configured grant resources for sidelink transmission. The gNB may then determine to allocate some overlapping resources to UE2 in timeslot #2. At the same time, if UE1 also has data to transmit during the configured CG opportunity in timeslot #2, an inter-UE collision will occur. Inter-UE collisions can occur on a shared carrier or on a dedicated carrier. This section describes inter-UE collision handling solutions for such scenarios.

[0419] Similar to the scenario of the inter-UE collision between two dynamically scheduled sidelink transmissions, the potential inter-UE collision may be transparent to UE2, or the potential inter-UE collision may be indicated to UE2.

[0420] On the one hand, potential inter-UE conflicts can be transparent to UE2. The problem will then be similar to the problem for inter-UE conflicts between configuration grant side link and dynamic Uu transmission. The solutions proposed for handling inter-UE conflicts between configuration grant side link and dynamic Uu transmission can also be applied here. Some examples are Figure 24 and Figure 25 shown.

[0421] On the other hand, the gNB may send an indication to UE2 to indicate a potential inter-UE conflict, which has the following alternative cases.

[0422] The gNB assumes that inter-UE collisions will occur

[0423] In the first alternative, the gNB may send an indication of inter-UE conflict to UE2, thereby informing UE2 that other transmissions will be preempted. This may be done, for example, via a scheduled DCI with an explicit bit field, or it may be signaled implicitly. Once UE2 determines that it will preempt other transmissions, it may send an indication indicating the inter-UE conflict, where the indication may be a preemption indication, a power reduction indicator, or a cancellation indication, as disclosed in the previous section. The indication may be a preamble, a sequence, a reference signal, a broadcast SCI, or the broadcast portion of a two-phase SCI.

[0424] When UE1 determines to transmit data at the next configured grant opportunity, it can monitor and detect whether it has been preempted by another V2X UE. If UE1 determines it has been preempted, it can use the procedures disclosed for handling inter-UE conflicts between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to address this issue for broadcast, multicast, and unicast. In principle, the solutions proposed for dynamically scheduled broadcast, multicast, and unicast can also be applied here.

[0425] In this alternative case, the gNB does not know when UE1 will transmit at the configured CG occasion, so the gNB does not know whether it needs to schedule a retransmission for the preempted sidelink transmission.

[0426] In one scenario, the gNB can monitor power levels to determine whether there are other transmissions on the channel. When the gNB detects another transmission, although it cannot decode it, it can determine that an inter-UE collision has occurred. The gNB can then schedule a retransmission for the configured authorized UE. This solution can be applied to power-based inter-UE collision resolution.

[0427] In another case, when UE1 has data to send in a CG opportunity and detects that it is preempted, UE1 can send an indication to the gNB to request scheduling of retransmission instead of waiting for the next CG opportunity for retransmission. For example, the indication can be SR, BSR, reference signal, preamble, or sequence.

[0428] CG UE sends an indication of waiting for transmission at the next CG opportunity

[0429] In the second alternative, when UE1 determines to send data on a configured CG opportunity (e.g., CG opportunity k), it may send an indication to the gNB to inform it that there is data to send. For example, the indication may be an SR, a BSR, a reference signal, a preamble, or a sequence.

[0430] In this alternative scenario, if the gNB needs to schedule some urgent transmission for another UE (e.g., UE2) using the same resources, the gNB knows that an inter-UE conflict will occur. The gNB can send an indication of the inter-UE conflict to UE2, notifying UE2 that the other transmission will be preempted. This can be done, for example, via a scheduling DCI with an explicit bit field, or it can be signaled implicitly. Once UE2 determines that it will preempt the other transmission, it can send an indication indicating the inter-UE conflict, where the indication can be a preemption indication, a power reduction indicator, or a cancellation indication, as disclosed in the previous section. The indication can be a preamble, a sequence, a reference signal, a broadcast SCI, or the broadcast portion of a two-phase SCI.

[0431] UE1 can monitor and detect whether it is preempted at CG opportunity k. When the UE determines that it is preempted, it can use the procedures disclosed for handling inter-UE conflicts between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle this issue for broadcast, multicast, and unicast. In general, the solutions proposed for dynamically scheduled broadcast, multicast, and unicast also apply here. If UE1 does not detect that it is preempted, the UE can send data at CG opportunity k without waiting for new scheduling.

[0432] Since the gNB is aware of the inter-UE collision, the gNB can schedule retransmissions for UE1 without receiving feedback from UE1. Alternatively, the gNB can schedule retransmissions based on feedback from UE1, as disclosed in the dynamically scheduled multicast and unicast scenarios.

[0433] At the same time, UE1 may also indicate the priority of the data to be sent when sending an indication to the gNB, as disclosed for the case of inter-UE conflict between configuring the grant side link and dynamic Uu transmission.

[0434] It should be understood that any of the methods and processes described herein may be embodied in the form of computer-executable instructions (i.e., program code) stored on a computer-readable storage medium, and when the instructions are executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, etc., the systems, methods, and processes described herein are performed and / or implemented. Specifically, any of the above steps, operations, or functions may be implemented in the form of such computer-executable instructions. Computer-readable storage media include both volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium that can be used to store the desired information and can be accessed by a computing system.

[0435] In describing the preferred embodiments of the disclosed subject matter, specific terminology has been employed for the sake of clarity, as shown in the figures. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[0436] Therefore, it should be understood by those skilled in the art that the disclosed systems and methods can be embodied in other specific forms without departing from their spirit or essential characteristics. Therefore, the embodiments currently disclosed are considered to be illustrative and not restrictive in all respects. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Without departing from the breadth or scope, modifications and variations are possible according to the above teachings, or can be obtained from the practice of the present disclosure. Therefore, although specific configurations have been discussed herein, other configurations may also be adopted. Many modifications and other embodiments (e.g., combinations, rearrangements, etc.) are implemented by the present disclosure and are within the scope of ordinary skill in the art and are considered to fall within the scope of the disclosed subject matter and any equivalents thereof. Within the scope of the present invention, the features of the disclosed embodiments can be combined, rearranged, omitted, etc. to produce additional embodiments. In addition, certain features can sometimes be used as advantages without the corresponding use of other features. Therefore, the applicant (one or more) intends to include all such substitutions, modifications, equivalents and variations within the spirit and scope of the disclosed subject matter.

[0437] Unless explicitly stated, reference to an element in the singular is not intended to mean "one and only one," but rather "one or more." Furthermore, where a phrase similar to "at least one of A, B, or C" is used in the claims, it is intended that the phrase be interpreted to mean that A can exist alone in an embodiment, B can exist alone in an embodiment, C can exist alone in an embodiment, or any combination of the elements A, B, and C can exist in a single embodiment; for example, A and B, A and C, B and C, or A and B and C.

[0438] According to 335 U.S.C. 112(f), no claim element herein will be interpreted unless the phrase "means" is used to expressly recite that element. As used herein, the terms "comprise," "include," or any other variations thereof are intended to encompass a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but may also include other elements not expressly listed or inherent to such process, method, article, or apparatus. The scope of the invention is indicated by the appended claims, not the foregoing description, and all variations within the meaning and scope and their equivalents are intended to be included therein.

Claims

1. A computing device comprising: one or more processors; as well as a memory storing instructions that, when executed by the one or more processors, cause the computing device to: receiving a radio resource control (RRC) message, the RRC message including a sidelink resource pool configuration, wherein the sidelink resource pool configuration includes: an RRC parameter SL1stSCIPriorityLevel indicating a first priority level associated with first-stage sidelink control information (SCI) within the resource pool, an RRC parameter SL2ndSCIPriorityLevel indicating a second priority level associated with second-stage SCI within the resource pool, an RRC parameter SLHARQPriorityLevel indicating a third priority level associated with hybrid automatic repeat request (HARQ) transmission on a physical sidelink feedback channel (PSFCH) within the resource pool, an RRC parameter SLCSIPriorityLevel indicating a fourth priority level associated with channel state information (CSI) transmission on the PSFCH within the resource pool, and an RRC parameter SLPSSCHPriorityLevel indicating a fifth priority level associated with physical sidelink shared channel (PSSCH) transmission within the resource pool; determining a sidelink transmission within a sidelink resource pool of a wireless communication network; determining uplink transmission of data in the wireless communication network; determining at least a partial temporal overlap of the sidelink transmission and the uplink transmission; Determining whether to prioritize the uplink transmission or the sidelink transmission, wherein if the uplink transmission is associated with a priority level that is less than the priority level of the sidelink transmission, the uplink transmission is prioritized, and (i) if the sidelink transmission corresponds to a first-phase SCI transmission within the resource pool, the priority level of the sidelink transmission is determined based on an RRC parameter SL1stSCIPriorityLevel, (ii) if the sidelink transmission corresponds to a second-phase SCI transmission within the resource pool, the priority level of the sidelink transmission is determined based on an RRC parameter SL2ndSCIPriorityLevel, and (iii) if the sidelink transmission corresponds to a HARQ transmission of a PSFCH within the resource pool, the priority level of the sidelink transmission is based on an RRC parameter SLHARQ (iv) if the sidelink transmission corresponds to a CSI transmission of a PSFCH within the resource pool, the priority level of the sidelink transmission is determined based on an RRC parameter SLCSIPriorityLevel, (v) if the sidelink transmission corresponds to a PSSCH transmission within the resource pool, the priority level of the sidelink transmission is determined based on an RRC parameter SLPSSCHPriorityLevel, wherein if the uplink transmission has the same priority level as the sidelink transmission, the computing device is configured to prioritize based on packet size, wherein the sidelink transmission is prioritized if the sidelink transmission uses fewer resources than the uplink transmission, and the uplink transmission is prioritized if the uplink transmission uses fewer resources than the sidelink transmission; and Based on the determined higher priority, one of the sidelink transmission or the uplink transmission is transmitted.

2. The computing device of claim 1, wherein: The first priority associated with the sidelink transmission is also based on the SCI.

3. The computing device of claim 2, wherein: The first priority associated with the sidelink transmission is explicitly indicated via the SCI.

4. A method comprising: receiving a radio resource control (RRC) message, the RRC message including a sidelink resource pool configuration, wherein the sidelink resource pool configuration includes: an RRC parameter SL1stSCIPriorityLevel indicating a first priority level associated with first-stage sidelink control information (SCI) within the resource pool, an RRC parameter SL2ndSCIPriorityLevel indicating a second priority level associated with second-stage SCI within the resource pool, an RRC parameter SLHARQPriorityLevel indicating a third priority level associated with hybrid automatic repeat request (HARQ) transmission on a physical sidelink feedback channel (PSFCH) within the resource pool, an RRC parameter SLCSIPriorityLevel indicating a fourth priority level associated with channel state information (CSI) transmission on the PSFCH within the resource pool, and an RRC parameter SLPSSCHPriorityLevel indicating a fifth priority level associated with physical sidelink shared channel (PSSCH) transmission within the resource pool; receiving an indication associated with a sidelink transmission within a sidelink resource pool of a wireless communication network; receiving an indication associated with an uplink transmission of data in the wireless communication network; receiving an indication that the sidelink transmission and the uplink transmission at least partially overlap in time; and receiving an indication of whether to prioritize the uplink transmission or the sidelink transmission, wherein if the uplink transmission is associated with a priority level that is less than the priority level of the sidelink transmission, the uplink transmission is prioritized, and (i) if the sidelink transmission corresponds to a first phase SCI transmission within the resource pool, the priority level of the sidelink transmission is determined based on an RRC parameter SL1stSCIPriorityLevel, (ii) if the sidelink transmission corresponds to a second phase SCI transmission within the resource pool, the priority level of the sidelink transmission is determined based on an RRC parameter SL2ndSCIPriorityLevel, and (iii) if the sidelink transmission corresponds to a HARQ transmission of a PSFCH within the resource pool, the priority level of the sidelink transmission is determined based on an RRC parameter SL2ndSCIPriorityLevel. (iv) if the sidelink transmission corresponds to a CSI transmission of a PSFCH within the resource pool, the priority level of the sidelink transmission is determined based on the RRC parameter SLCSIPriorityLevel, (v) if the sidelink transmission corresponds to a PSSCH transmission within the resource pool, the priority level of the sidelink transmission is determined based on the RRC parameter SLPSSCHPriorityLevel, wherein if the uplink transmission has the same priority level as the sidelink transmission, prioritization is performed based on packet size, wherein the sidelink transmission is prioritized if the sidelink transmission uses fewer resources than the uplink transmission, and the uplink transmission is prioritized if the uplink transmission uses fewer resources than the sidelink transmission.

5. The method according to claim 4, wherein: The first priority associated with the sidelink transmission is also based on the SCI.

6. The method according to claim 5, wherein: The first priority associated with the sidelink transmission is explicitly indicated via the SCI.

Images