Apparatus, system, method, and computer readable medium for performing control to handling inter-UE prioritization of NR v2x
By introducing dynamic scheduling and preemption indication mechanisms in NR V2X mode, the conflict between inter-UE side link transmission and extremely low latency or high priority link transmission is solved, and higher communication reliability and efficiency are achieved.
Patent Information
- Application Number
- CN202510377185.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2019-03-28
- Filing Date
- 2020-02-05
- Publication Date
- 2025-05-09
- Estimated Expiration
- 2040-02-05
AI Technical Summary
In the new radio (NR) Vehicle Connection (V2X) mode, there is a conflict between side link transmissions between user equipment (UEs) and downlink or uplink transmissions with very low latency or high priority, resulting in transmission failure.
By introducing a dynamic scheduling mechanism in gNB, using Type 1 and Type 2 configuration authorization to allocate side link transmission resources on shared carriers, and introducing preemption indication and retransmission scheduling mechanisms between UEs to handle conflicts between UEs.
Effectively resolve inter-UE conflicts, ensure the success of extremely low latency or high priority transmission, and improve communication reliability and efficiency in NR V2X mode.
Smart Images

Figure CN119967604A_ABST
Abstract
Description
[0001] This application is a divisional application of invention patent application 202080025014.2, filed on February 5, 2020, and entitled "Apparatus, system, method, and computer-readable medium for performing control to process NR V2X inter-UE priority sorting."
[0002] CROSS-REFERENCE TO RELATED APPLICATIONS
[0003] 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
[0004] 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
[0005] The "background technology" description provided herein is intended to generally present the context of the present disclosure. To the extent described in this background technology 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 neither explicitly nor implicitly admitted to be prior art against the present invention.
[0006] For New Radio (NR) Vehicle-to-Everything (V2X) Mode 1 shared carrier scenarios, the gNB may allocate sidelink transmissions on a shared carrier with downlink (DL) and / or uplink (UL) transmissions on the Uu interface using dynamic scheduling, Type 1 Configuration Grant (CG), or Type 2 Configuration Grant (CG). For example, the gNB may schedule a very low latency or high priority DL data transmission on 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 degrade or even fail. Therefore, some 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 DL or UL transmissions.
[0007] For NR V2X Mode 1, the gNB may 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 that may overlap with a sidelink transmission that has been scheduled or configured for another UE. In this case, both transmissions may be degraded or even fail. Therefore, some 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
[0008] 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: 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 UE conflicts between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low latency or high priority sidelink transmissions, or UE-to-UE prioritization for New Radio (NR) Vehicle-to-Everything (V2X).
[0009] The Summary of the Invention section is provided to introduce in simplified form some concepts that are further described below in the Detailed Description section. The Summary of the Invention section is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all deficiencies mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0010] 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:
[0011] Figure 1A is a system diagram illustrating an example 3GPP architecture;
[0012] Figure 1B is a system diagram of an example apparatus or device configured for wireless communication;
[0013] Figure 1C is a system diagram showing examples of a radio access network (RAN) architecture and a core network architecture;
[0014] Figure 1D is a system diagram showing an example of a radio access network (RAN) architecture and a core network architecture;
[0015] Figure 1Eis a system diagram showing examples of a radio access network (RAN) architecture and a core network architecture;
[0016] Figure 1F is a system diagram illustrating an example of a computing system for use in a communications network;
[0017] Figure 1G is a system diagram illustrating an example 3GPP architecture;
[0018] Figure 2 shows a sidelink transmission preempted by a dynamically scheduled Uu transmission according to an exemplary embodiment;
[0019] Figure 3 It is shown that a UE according to an exemplary embodiment detects an explicit preemption indication and performs a retransmission;
[0020] Figure 4 UE detection of signaling jointly indicating explicit preemption indication and retransmission scheduling according to an exemplary embodiment is shown;
[0021] Figure 5 It is shown that a UE detects an implicit preemption indication via a retransmission scheduling DCI according to an exemplary embodiment;
[0022] 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;
[0023] Figure 7 shows a joint indication of power reduction and retransmission for a preempted sidelink according to an exemplary embodiment;
[0024] Figure 8 shows separate indications for reducing power and retransmissions for preempted sidelink transmissions according to an exemplary embodiment;
[0025] Fig. 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;
[0026] Fig.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;
[0027] Fig.11 A method according to an exemplary embodiment is shown for a transmitting UE to detect preemption of a unicast sidelink UE that has an inter-UE conflict with a scheduled Uu transmission;
[0028] Fig.12 A process is shown according to an exemplary embodiment for a receiving UE to detect preemption of a unicast sidelink UE that has an inter-UE conflict with a scheduled Uu transmission;
[0029] Fig.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 having an inter-UE collision with a scheduled Uu transmission;
[0030] Fig.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;
[0031] Fig.15 A method according to an exemplary embodiment is shown for a transmitting UE to detect a cancellation indication of a unicast sidelink UE having an inter-UE conflict with a scheduled Uu transmission;
[0032] Fig.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 conflict with a scheduled Uu transmission;
[0033] Fig.17 A method according to an exemplary embodiment is shown for a transmitting UE to detect preemption of a multicast side link UE that has an inter-UE conflict with a scheduled Uu transmission;
[0034] Fig.18 A process is shown according to an exemplary embodiment for a receiving UE to detect preemption of a multicast side link UE that has an inter-UE conflict with a scheduled Uu transmission;
[0035] Fig.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 having an inter-UE conflict with a scheduled Uu transmission;
[0036] Fig. 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 conflict with a scheduled Uu transmission;
[0037] Fig.21 A process is shown according to an exemplary embodiment for a transmitting UE to detect a cancellation indication of a multicast side link UE that has an inter-UE conflict with a scheduled Uu transmission;
[0038] Fig. 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;
[0039] Fig.23 A procedure for cancelling an indicator for a UE having a configured grant side link with an inter-UE conflict with a scheduled Uu transmission is shown;
[0040] Fig.24 A process for detecting a cancellation indicator for a UE having a configured grant side link having an inter-UE conflict with a scheduled Uu transmission is shown;
[0041] Fig.25 An alternative process for detecting preemption of a UE having a configured grant side link with an inter-UE conflict with a scheduled Uu transmission is shown;
[0042] Fig.26 An example of a sidelink transmission with 3 repetitions scheduled by a gNB in NR V2X Mode 1 is shown;
[0043] Fig. 27 An example of a sidelink transmission being preempted during a repetition is shown;
[0044] Fig.28 An example of a sidelink transmission with a first stage SCI and a second stage SCI sent simultaneously is shown;
[0045] Fig.29 An inter-UE collision between two dynamically scheduled sidelink transmissions is shown;
[0046] Fig.30 An inter-UE conflict between a dynamically scheduled sidelink transmission and a sidelink based on a configured grant is shown.
[0047] 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 the example embodiments is for illustration only and, therefore, is not necessarily intended to limit the scope of the present disclosure. DETAILED DESCRIPTION
[0048] The Third 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 standards, and New Radio (NR), also referred to as "5G". Development of the 3GPP NR standards is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of 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 set 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, for example, indoor applications and hotspots. 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.
[0049] 3GPP has identified a variety of use cases that NR is expected to support, resulting in various user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency communication (URLLC), massive machine type communication (mMTC), network operations (e.g., network slicing, routing, migration and intercommunication, energy saving), and enhanced vehicle-to-everything (eV2X) communication, which can include vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and any of the communication between vehicles and other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive electronic calls (ecalls), disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robots, and aerial drones, etc. All of these use cases and others are contemplated herein.
[0050] 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.
[0051] LIST OF ABBREVIATIONS
[0052]
[0053]
[0054] Example Communication Systems and Networks
[0055] Figure 1A An example communication system 100 is shown in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which are 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, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.
[0056] It should be appreciated that the concepts disclosed herein may 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 FIG. 1 , each of the WTRUs 102 is Figures 1A-1E . It will be appreciated that for various use cases contemplated for wireless communications, each WTRU may include or be included in any type of device or apparatus configured to send 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 smart watch or smart clothing, a medical or e-health device, a robot, an industrial device, a drone, a vehicle such as a car, a bus or a truck, a train or an airplane, and the like.
[0057] The communication system 100 may also include a base station 114a and a base station 114b. Figure 1AIn the example of , 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 wired and / or wirelessly 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).
[0058] 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.
[0059] The base station 114a may be part of the RAN 103 / 104 / 105, and the base station 114a may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, and the base station 114b may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to send and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may also be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, for example, one for each sector of the cell. For example, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may use multiple transceivers for each sector of the cell.
[0060] 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).
[0061] The base station 114b may 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 may 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 may be established using any suitable RAT.
[0062] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an 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.
[0063] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, 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 115d / 116d / 117d may be established using any suitable RAT.
[0064] 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).
[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 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 Advanced LTE (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.).
[0066] 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, CDMA2000EV-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.
[0067] For example, Figure 1AThe base station 114c in the figure can be a wireless router, a Home Node B, a Home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area (such as a business place, a home, a vehicle, a train, an antenna, a satellite, a factory, a campus, etc.). The base station 114c and the WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) can implement radio technologies 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) can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a microcell or a femtocell. As Figure 1A As shown, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c does not need to access the Internet 110 via the core network 106 / 107 / 109.
[0068] 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.
[0069] Although not in Figure 1A 103 / 104 / 105 and / or the 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 the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the 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.
[0070] 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) services. The Internet 110 may include a global system and devices of interconnected computer networks that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The 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.
[0071] 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.
[0072] Although not in Figure 1A 106 / 107 / 109. It is shown in the figure, but it should be understood that the user equipment can make a wired connection to the gateway. The gateway can be a residential gateway (RG). The RG can provide a connection to the core network 106 / 107 / 109. It should be understood that many of the schemes contained herein can be equally applicable to a UE that is a WTRU and a UE that is connected to the network using a wired connection. For example, the scheme applicable to wireless interfaces 115, 116, 117 and 115c / 116c / 117c can be equally applicable to a wired connection.
[0073] Figure 1B 1 is a system diagram of an example RAN 103 and a 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, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and radio network controllers (RNCs).
[0074] like Figure 1B As shown, Node-B 140a, 140b can communicate with RNC 142a. Additionally, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node-B 140a, 140b and 140c to which it is connected. In addition, each of RNC 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, macro diversity, security functions, data encryption, etc.
[0075] Figure 1B The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] Figure 1C 1 is a system diagram of an example RAN 104 and a core network 107. As described 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.
[0080] 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.
[0081] 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.
[0082] Figure 1C The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is 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.
[0083] 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, etc. 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.
[0084] 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 / 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 used for the WTRUs 102a, 102b, and 102c, managing and storing the context of the WTRUs 102a, 102b, and 102c, and the like.
[0085] 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.
[0086] 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.
[0087] Figure 1D1 is a system diagram of an example RAN 105 and a 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. A 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.
[0088] The RAN 105 may include gNode-Bs 180a and 180b. It should be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When an integrated access and backhaul connection 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 send wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. It should be appreciated that the RAN 105 may employ other types of base stations, such as an eNode-B. It should 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.
[0089] 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.
[0090] 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 the 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.
[0091] Figure 1DThe core network 109 shown in the figure can be a 5G core network (5GC). The core network 109 can provide many communication services to customers interconnected by radio access networks. 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 can 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 The system 90 shown is stored in a memory and executed on a processor thereof.
[0092] exist Figure 1D In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network open function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, 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 can communicate via a routing agent such as a Diameter routing agent or a message bus.
[0093] exist Figure 1D In the example of , the connection between network functions is realized via a set of interfaces or reference points. It should be understood that network functions can be modeled, described or realized as a set of services invoked or called by other network functions or services. The invocation of network function services can be realized via direct connections between network functions, exchange of message passing on a message bus, calling software functions, etc.
[0094] The AMF 172 may be connected to the RAN 105 via an 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, 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 FIG.
[0095] 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.
[0096] 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 communication 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 an Ethernet network or any type of network that switches data packets. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via an N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting to the packet data network using an N6 interface or by connecting to each other and to other UPFs via an 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.
[0097] For example, via the N2 interface, the AMF 172 may also be connected to the N3IWF 199. For example, via a wireless ground connection technology not defined by 3GPP, the N3IWF facilitates the connection 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.
[0098] 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 1. 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 pass 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.
[0099] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may be connected to a network function so that the network function can add, read, and modify data in the repository. For example, the UDR 178 may be connected to the PCF 184 via an N36 interface. Similarly, the UDR 178 may be connected to the NEF 196 via an N37 interface, and the UDR 178 may be connected to the UDM 197 via an N35 interface.
[0100] The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access the UDR 178. For example, the UDM 197 may be connected to the AMF 172 via the N8 interface, and the UDM 197 may be connected to the SMF 174 via the N10 interface. Similarly, the UDM 197 may be connected to the AUSF 190 via the N13 interface. The UDR 178 and the UDM 197 may be tightly integrated.
[0101] AUSF 190 performs authentication related operations and is connected to UDM 178 via the N13 interface and to AMF 172 via the N12 interface.
[0102] NEF 196 opens capabilities and services in 5G core network 109 to application function (AF) 188. The opening can occur on the N33 API interface. NEF can be connected to AF 188 via the N33 interface and it can be connected to other network functions to open capabilities and services of 5G core network 109.
[0103] 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.
[0104] 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 tailored to provide optimized solutions for different market scenarios that require different requirements, such as in terms of functionality, performance and isolation.
[0105] 3GPP has designed the 5G core network to support network slicing. Network slicing is a great tool that network operators can use to support different groups of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that require very different and sometimes extreme requirements. Without network slicing technology, the network architecture may not be flexible and scalable enough to effectively support a wider range of use case requirements when each use case has its own set of performance, scalability, and availability requirements. In addition, the introduction of new network services should be more efficient.
[0106] Reference again Figure 1D In a network slicing scenario, the WTRU 102a, 102b, or 102c may be connected to the AMF 172 via an N1 interface. The AMF may logically be part of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, 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.
[0107] 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 a 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 a 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.
[0108] 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).
[0109] 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, F, a base station 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, base stations gNBs, V2X networks, and / or other network elements. One or several or all WTRUs A, B, C, D, E, and F may be outside the access network coverage 122. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.
[0110] If WTRU A, B, C, D, E, F are under access network coverage (in Figure 1E 129b), WTRUs A, B, C, D, E, and F may communicate with each other via gNB 121 over Uu interface 129b. If WTRUs A, B, C, D, E, and F are in or outside of access network coverage (e.g., 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.
[0111] WTRUs A, B, C, D, E, and F may communicate with the RSU 123a or 123b via a vehicle-to-network (V2N) interface 126 or a sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with a V2X server 124 via a vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via a vehicle-to-person (V2P) interface 128.
[0112] Figure 1F is an example apparatus or device WTRU 102 (such as Figure 1A , 1B , 1C, 1D or 1E WTRU 102). 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 keyboard 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be understood 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.
[0113] 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.
[0114] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Figure 1A The base station 114a of the transmitter or receiver may be configured to transmit or receive signals from the base station, or to transmit 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 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.
[0115] Furthermore, although the send / receive element 122 Figure 1F Although depicted as a single element in the figure, 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.
[0116] 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 via multiple beams using the same RAT.
[0117] The processor 118 of the WTRU 102 may be coupled to and receive user input data from a speaker / microphone 124, a keyboard 126, and / or a 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 keyboard 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 a random access memory (RAM), a 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 a 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).
[0118] 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.
[0119] The processor 118 may also be coupled to the GPS chipset 136 that is configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. 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 in addition to or in lieu of the information from the GPS chipset 136. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method.
[0120] 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.
[0121] 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 the interconnect interface that may include one of the peripheral devices 138.
[0122] 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 the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112 or network services 113. The computing system 90 may include a computer or a 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 the processor 91 to enable the computing system 90 to work. The processor 91 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 91 may perform signal encoding, data processing, power control, input / output processing and / or any other function that enables the 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.
[0123] In operation, processor 91 fetches, 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 components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.
[0124] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such a memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by the 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 a virtual address into a physical address when an instruction is 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.
[0125] In addition, 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 .
[0126] 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 electronic components that need to generate a video signal that is sent to the display 86.
[0127] In addition, computing system 90 may include 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 the 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.
[0128] 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 for storing information implemented in any non-transitory (e.g., tangible or physical) method or technology, 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 disk (DVD) or other optical disk storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store the desired information and can be accessed by a computing system.
[0129] 5G V2X use cases
[0130] As vehicle-to-everything (V2X) applications make significant progress, the transmission of short messages about the vehicle's own status data for basic safety can be extended 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 to meet the required data rate, latency, reliability, communication range and speed are more stringent.
[0131] For enhanced V2X (eV2X) services, 3GPP has identified 25 use cases and related requirements in TR 22.886.
[0132] A set of normative requirements is specified in TS22.186, and these use cases are categorized into four use case groups: vehicle platooning, extended sensors, advanced driving, and remote driving.
[0133] A detailed description of the performance requirements for each use case group is specified in TS22.186.
[0134] Uu-based sidelink control for V2X in NR
[0135] In NR V2X, sidelink resource allocation mode 1 and mode 2 are agreed. In mode 1, the base station schedules the sidelink resources for the UE for sidelink transmission. The UE can perform broadcast, multicast or unicast on the sidelink using the allocated resources. In mode 2, the UE determines the sidelink resources for sidelink transmission within the sidelink resources configured by the base station or the pre-configured sidelink resources.
[0136] Mode 1 supports the gNB to allocate sidelink resources between Uu transmission and sidelink transmission over the Uu interface for both dedicated sidelink carrier and shared licensed carrier. When the carrier is shared between Uu transmission and sidelink transmission, Uu transmission and sidelink transmission may occur in the same frame but in different time slots, or Uu transmission and sidelink transmission may occur in the same time slot. In the subsequent sections, the carrier on which Uu transmission and sidelink transmission are multiplexed is referred to as a shared carrier.
[0137] 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.
[0138] Inter-UE multiplexing in NR
[0139] 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 will drop the low priority transmission and send the high priority data. The gNB will then send a preemption indication to instruct the preempted UE(s) to flush their buffer(s).
[0140] DCI format 2_1 is used to inform the UE of (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. In one DCI, it can carry multiple preemption indications, where each preemption indication 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.
[0141] Similar to the downlink, in some scenarios, two scheduled uplink transmissions may also conflict. When uplink transmission conflicts occur, the scheduled low-priority uplink transmission may affect the performance of the scheduled high-priority uplink transmission. To address this issue, the gNB can send a cancel 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.
[0142] For NR V2X Mode 1 shared carrier scenarios, the gNB may allocate sidelink transmissions on a shared carrier with downlink (DL) and / or uplink (UL) transmissions on the Uu interface using dynamic scheduling, type 1 configuration grants, or type 2 configuration grants. For example, the gNB may schedule a very low latency or high priority DL data transmission on 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, some mechanisms need to be introduced to handle inter-UE conflicts between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low latency or high priority DL or UL transmissions.
[0143] For NR V2X Mode 1, the gNB may 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 that has been scheduled or configured for another UE. In this case, both transmissions may be degraded or even fail. Therefore, some mechanism needs to be introduced to handle inter-UE conflicts between dynamically scheduled or configured sidelink transmissions and dynamically scheduled very low latency or high priority sidelink transmissions.
[0144] Public options include:
[0145] The present disclosure includes a scheme for handling inter-UE contention in NR V2X for the following use cases:
[0146] • Inter-UE conflicts between dynamically scheduled broadcast sidelink and dynamically scheduled Uu transmissions.
[0147] • Inter-UE conflicts between dynamically scheduled unicast sidelink and dynamically scheduled Uu transmissions.
[0148] • Inter-UE conflicts between dynamically scheduled multicast sidelinks and dynamically scheduled Uu transmissions.
[0149] • Inter-UE conflicts between the broadcast sidelink based on configuration grants and dynamically scheduled Uu transmissions.
[0150] • Inter-UE conflicts between unicast sidelink based on configured grants and dynamically scheduled Uu transmissions.
[0151] • Inter-UE conflicts between the multicast sidelink based on configuration grants and the dynamically scheduled Uu transmissions.
[0152] • Inter-UE collision between a dynamically scheduled sidelink and another dynamically scheduled sidelink.
[0153] • Inter-UE conflicts between configured grant-based sidelinks and dynamically scheduled sidelinks.
[0154] The public UE conflict handling mechanisms include:
[0155] ●Reduce the transmit power of the preempted transmission.
[0156] ● Reduce the sender and / or receiver antenna gain of the preempted transmission.
[0157] ● Increase the transmit power of transmissions that are to preempt other transmissions.
[0158] ●Increase the sender and / or receiver antenna gain of the transmission that is to preempt other transmissions.
[0159] ● Preempt the antenna panel of the preempted transmission.
[0160] ●Cancel the sending of a preempted transmission.
[0161] The present disclosure includes the following solutions:
[0162] ●Configuration and signaling for UE to monitor and decode Side Link Cancellation Indication (SL-CI).
[0163] • Mechanisms to handle inter-UE collisions with duplicate sidelink transmissions.
[0164] ● Prioritization rules for simultaneous sidelink and uplink transmissions. Dynamically scheduled Uu transmissions preempt sidelink transmissions
[0165] 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 Uu (e.g., PDSCH and / or PUSCH) may partially or completely overlap in time or frequency with the resources allocated to the sidelink transmissions, with the following implications: Figure 2 Alternative case shown.
[0166] ● Case A: Dynamically scheduled downlink transmission on the Uu interface (e.g.
[0167] PDSCH) may overlap / collide with dynamically scheduled sidelink transmissions.
[0168] ● Case B: Dynamically scheduled uplink transmission on the Uu interface (e.g.
[0169] PUSCH) may overlap / collide with dynamically scheduled sidelink transmissions.
[0170] ● Case C: Dynamically scheduled downlink transmission on the Uu interface (e.g.
[0171] PDSCH) may overlap / collide with the configuration grant sidelink transmission.
[0172] ● Case D: Dynamically scheduled uplink transmission on the Uu interface (e.g.
[0173] PUSCH) may overlap / conflict with the configuration grant sidelink transmission.
[0174] Figure 2 The sidelink transmission shown in can be broadcast, multicast or unicast, or any combination of the foregoing. In this example, the Uu transmission can have a higher priority or low latency requirement than the sidelink transmission. In order to ensure that higher priority data will be transmitted / received to / from the Uu transmission, the sidelink transmission can be preempted.
[0175] Dynamically scheduled broadcast sidelink transmission preempted by dynamically scheduled Uu transmission
[0176] In this section, the scheme is described for the case where a dynamically scheduled Uu transmission conflicts with a dynamically scheduled broadcast sidelink transmission. In the broadcast scenario, the Tx UE (sender UE) will not receive ACK / NACK feedback from (one or more) Rx UEs (receiver UEs). The Uu transmission herein may be a downlink transmission or may be an uplink transmission.
[0177] 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 conflicts, we disclose that the broadcast sidelink transmission can be preempted, with the following alternative cases:
[0178] Preemption of Uu transmissions using higher power
[0179] In the first alternative case, UE1 will perform broadcast sidelink transmission regardless of whether preemption is received.
[0180] In order to ensure that higher priority data is transmitted / received to / from UE2, Uu transmission may be performed at a higher power level than the power level used for scenarios without inter-UE collision. For example, if it is a downlink transmission, the gNB may increase the transmit power and / or beamforming antenna gain; if it is an uplink transmission, the UE2 may be instructed to increase the transmit power. The transmit power command (TPC) field in the DCI for scheduling may be used to instruct the UE2 to increase the transmit power; or, a bit field in the DCI for scheduling may be used to indicate to the UE2 whether it is preempting other transmissions, or, the selection of a specific codeword in the codebook for codebook-based UL transmission may indicate the increased transmit power, and if the UE2 is preempting other transmissions, it may perform the transmission at maximum power or by applying a predefined / preconfigured transmit power offset; or, the priority level of the scheduled uplink transmission may be used to indicate to the UE2 by the DCI for scheduling, each priority level may be associated with a predefined / preconfigured transmit power level and / or offset, and the UE2 shall set the transmit power level accordingly based on the indicated priority level.
[0181] 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 is preempted before refreshing UE1's transmission buffer. Information on the preemption monitoring opportunity, such as monitoring periodicity, can be configured to the UE by the radio resource control (RRC) at symbols and / or time slots. If UE1 does not detect that the transmission is preempted, it will refresh its buffer; if UE1 detects that the transmission is preempted, it can retain the buffer and prepare for retransmission.
[0182] 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, a UE-specific configuration will be configured for the UE. 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 DCI for scheduling to schedule retransmissions, such as Figure 3 Alternatively, UE1 may detect that the transmission is preempted by detecting signaling that jointly indicates the preemption and the resources used 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, such as Figure 5 The scheduling of retransmissions may be intra-slot scheduling as shown in the figure or may be cross-slot scheduling, which depends on the delay requirements, for example.
[0183] For a UE receiving a broadcast message retransmission, the UE may soft combine (one or more) retransmissions of multiple message receptions to increase the probability of successfully decoding the data. If the UE uses the preempted transmission for soft combining, it may downgrade the combined decoding. (One or more) preemption indications may be sent to the receiving UE to notify not to soft combine the preempted transmission with (one or more) other transmissions. For example, after detecting the preemption from the gNB, UE1 may broadcast the preemption to the receiving UE, for example, by means of a 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 the bit in the CBGFI bitmap to "1". Or through the new data indicator (NDI) field in the SCI for the retransmission. For example, if the retransmission is due to preemption, UE1 may switch the value in the NDI field in the SCI for the retransmission. If the retransmission is not due to preemption, UE1 will not switch the value in the NDI field. Alternatively, when UE1 performs a retransmission, it may use a different RV from the initial transmission (e.g., RV0 for the initial transmission and RV2 for the retransmission) for the retransmission. Alternatively, when UE1 performs a retransmission, it may use a different HARQ ID (e.g., HARQ ID 1 for the initial transmission and HARQ ID 4 for the retransmission) 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.
[0184] The UE is preconfigured or indicated 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.
[0185] 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.
[0186] An example of a public procedure for detecting preemption is given in Figure 6601 . 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 a preemption indication of the Uu transmission (603). When preemption is detected (604), the UE will retransmit (605) the broadcast on the sidelink. When preemption is not detected, the UE will flush the buffer for the transmitted packets (606).
[0187] Use adjusted transmission control parameters to preempt low priority SL transmissions
[0188] In the second alternative case, UE1 may monitor before performing a broadcast sidelink transmission to detect if it is preempted. If preemption occurs, the gNB may send an indication, thereby 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 may reduce the transmit power (even to zero) on the entire transmission or on part of the transmission (e.g., reduce data REs but not DMRS REs). For example, by detecting the indication, UE1 will overwrite the old TPC and send the scheduled broadcast sidelink transmission with the new transmit power.
[0189] The new transmit power level or offset may be indicated dynamically to the UE; alternatively, the UE may be indicated to switch to a preconfigured low power level or offset. The indication may be signaled via a DCI, a reference signal, a preamble, or a sequence.
[0190] In one case, the UE may be instructed to reduce the power level of all allocated resources, regardless of whether it fully overlaps or partially overlaps with the conflicting Uu transmission. In this example, a value may be signaled to the UE to indicate the new transmit power, for example, the UE may be instructed to reduce the transmit power by an offset equal to a certain number of dB; or, the UE may be indicated the absolute transmit power level to which it needs to change. For example, the UE may be configured with multiple sequences, each of which is associated with a value. The UE may determine the new transmit power based on which sequence and / or preamble is detected.
[0191] Alternatively, when reference signals such as DMRS, CSI-RS are used to indicate power reduction, the UE may be configured with different reference signal time and frequency configurations, each configuration being associated with a value. The UE may determine a new transmit power based on which time and frequency resource the UE detected the reference signal.
[0192] Alternatively, the UE may be configured with one reference signal (DMRS or CSI-RS) time and frequency configuration but with a different reference signal sequence. For example, the UE may be configured with 4 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 sequence of the detected reference signal.
[0193] Table 1 - Example initializer values for determining associated power control commands for UE configuration
[0194]
[0195]
[0196] Alternatively, the gNB may instruct the UE using a power control command via a UE-specific DCI or via a group common DCI. The UE may be configured with information on monitoring opportunities via RRC, such as monitoring period, symbols and / or time slots to be monitored, etc. Alternatively, the UE may only detect time slots containing allocated resources.
[0197] 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). A 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 time slot these PIs apply. For example, a new DCI format may be introduced having a CRC scrambled with a UE-specific RNTI (e.g., RNTIp). Such a 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 time slot; 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, by 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 an indication can also be indicated by an existing DCI format (e.g., DCI format 0_1). When the UE detects a 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 due to an inter-UE conflict, and determine the power to be adjusted and the preempted time and / or resources.
[0198] Alternatively, a group-common 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. For example, a new DCI format may be introduced having 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; fields 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 where each bit represents one symbol or a 7-bit bitmap where each bit represents two symbols in a time slot; and / or fields 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., by a bitmap. When a group is formed, each UE may be configured with a power control command bit for the UE in the group-common DCI via an RRC message. When the UE detects the DCI encrypted with the configured RNTIpg during the UE's monitoring opportunity, the UE can determine that it is preempted and determine the power adjustment in the configured bits, the preempted time domain resources and / or frequency domain resources.
[0199] Alternatively, a sequence, a preamble, or a reference signal 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. Since more information needs to be carried, more sequences, preambles, or reference signal initializers may be configured for different assumptions. The UE may perform blind cross-correlation for more possible situations to detect and determine the information accordingly.
[0200] 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.
[0201] In one case, the scheduling of retransmissions may be indicated jointly with an indication for reducing power, such as 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.
[0202] 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., a sequence, preamble, reference signal, or DCI as disclosed), the UE determines that it is preempted and reduces the transmission power. The UE may then monitor the scheduling of retransmissions and perform retransmissions as scheduled.
[0203] 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 scheme disclosed in the Uu transmission preemption using higher power may also be applied here.
[0204] Fig. 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 the 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). Using the cancellation indicator, preempt the low priority SL transmission
[0205] In a third alternative, UE1 may monitor before performing a broadcast sidelink transmission to detect if it is preempted. If preemption occurs, the gNB may send a cancel indication, such as SL-CI (Sidelink Cancel Indication), thereby instructing UE1 to cancel the scheduled transmission. By detecting this indication, UE1 will not perform all or part of the scheduled transmission. If a cancel indication is detected, the PHY may send an indication to the upper layer, such as a canceled MAC.
[0206] 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 the 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.
[0207] In another case, the UE may be instructed to cancel transmission on a portion of the allocated resources, for example, cancel transmission on overlapping symbols and / or PRBs, or cancel transmission of a CBG that overlaps 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 scrambles a group-specific RNTI, for example, 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 that they are preempted and cancel transmissions, for example, a 14-bit bitmap in which each bit represents one symbol or a 7-bit bitmap in which each bit represents two symbols in a time slot; and / or fields indicating frequency resources on which the UEs may consider that they are preempted and cancel transmissions, for example, via a bitmap.
[0208] 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.
[0209] Alternatively, a sequence, preamble, or reference signal may be used to indicate to the UE that it needs to cancel the time domain resources and / or frequency domain resources for a scheduled transmission. For example, k different sequence initializers may be configured for the UE via an RRC for generating a 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 a time slot). The UE may be configured with all of the initializers shown in the table, or the UE may be configured with a subset of the listed initializers. Based on the reference signal sequence detected by blind cross-correlation, the UE may determine that the UE needs to cancel the time domain and / or frequency domain resources required for its transmission.
[0210] Table 2 Different initializer values configured to the UE for determining the resources on which the transmission needs to be cancelled
[0211]
[0212]
[0213] 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.
[0214] 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).
[0215] Furthermore, 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 soft combined.The solutions disclosed in the alternative case of preemption of Uu transmission using higher power may also be applied here.
[0216] Fig.10An example of a disclosed process for detecting a cancellation indication is shown for a sidelink UE having 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).
[0217] The dynamically scheduled Uu transmission preempts the dynamically scheduled unicast sidelink transmission
[0218] 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 herein can be a downlink transmission or can be an uplink transmission.
[0219] Assume that UE1 is dynamically scheduled by the gNB to send unicast transmissions on the sidelink as a Tx UE; UE2 is an 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 overlap in time with the resources allocated to UE1. To handle inter-UE conflicts, we disclose unicast sidelink transmissions that may be preempted in the following alternative scenarios.
[0220] Preemption of Uu transmissions using higher power
[0221] In the first alternative case, regardless of whether UE1 receives the preemption or not, it will perform unicast sidelink transmission.
[0222] To guarantee transmission / reception of UE3, Uu transmission may be performed at a higher power level than for a scenario without inter-UE collision, using a similar scheme proposed in the dynamically scheduled broadcast sidelink case.
[0223] For Tx UE, after UE1 performs unicast sidelink transmission, it will monitor the feedback sent by UE2 through PSFCH, such as ACK / NACK. UE1 can also monitor the indication sent by gNB to determine whether its transmission is preempted, where the configuration of monitoring timing can be configured by RRC.
[0224] 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.
[0225] In another case, 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.
[0226] In yet another case, 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 perform a retransmission and send preemption information to UE2 to instruct UE2 to flush its buffer accordingly. The solutions disclosed in the alternative case of preemption using higher power Uu transmission in the broadcast scenario may also be applied here.
[0227] In yet another case, UE1 may receive a NACK from UE2 and detect a preemption indication from the gNB, where the gNB may send a preemption indication to both the Tx UE and the Rx UE. UE1 may then determine that the transmission failed due to the preemption. UE1 may perform a retransmission without sending preemption information to UE2.
[0228] In yet another case, UE1 may receive NACK and preemption information from UE2, for example, through the CBGFI field in the SFCI. For example, UE2 may receive a preemption indication from the gNB. It may flush the buffer accordingly. UE2 may send a bitmap in the SFCI to UE1 to indicate the preempted resources. When UE1 receives such information, UE1 may determine that the transmission failed due to the preemption. UE1 may then perform a retransmission.
[0229] When an inter-UE conflict occurs, on the one hand, the gNB may allocate resources for retransmission to UE1 without receiving feedback from UE1. UE1 may determine whether to perform retransmission based on the feedback from the Rx UE. For example, if an ACK is received from UE2, UE1 may ignore the retransmission scheduling; or if a NACK is received from UE2, UE1 may perform retransmission using the allocated resources. Alternatively, on the other hand, the gNB may allocate resources for retransmission based on the feedback from UE1. UE1 may send an indication, such as SR, BSR, to the gNB based on the feedback from the Rx UE to indicate whether retransmission needs to be scheduled. For example, when UE1 receives an ACK from UE2, UE1 may indicate to the gNB that retransmission does not need to be scheduled. When UE1 receives a NACK from UE2, UE1 may indicate to the gNB that retransmission needs to be scheduled. 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.
[0230] 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.
[0231] Fig.11 An example of a disclosed process for a Tx UE to detect preemption is shown in FIG. 1 for a sidelink UE having an inter-UE conflict 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 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 the transmitted 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).
[0232] For Rx UE, UE2 can try to decode the transmitted data and send feedback to UE1. When UE2 cannot decode the data, it can send NACK to UE1.
[0233] 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.
[0234] In another case, UE2 may receive a retransmission from UE1 and receive a preemption indication. UE2 may flush its buffer and decode the retransmission. If the initial transmission is partially preempted, the UE may flush the buffer only for the preempted portion. For example, the UE may soft combine the retransmission with a first portion of the soft buffer but not with a second portion of the soft buffer, which may correspond to the preempted resources, so the UE may flush the second portion of the soft buffer.
[0235] 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.
[0236] In yet another case, UE2 may receive a preemption indication from the gNB before sending the HARQ feedback to UE1. UE2 may flush its buffer and send the preemption information together with the HARQ feedback.
[0237] Fig.12 An example of a disclosed process for an Rx UE to detect preemption is shown in FIG. 1 for a sidelink UE having an inter-UE conflict with a scheduled Uu transmission. The Rx UE receives a schedule for unicast sidelink preemption (1201). The UE determines whether the received data is successfully decoded (1202). If yes, the UE sends an ACK and refreshes its buffer (1206). If no, the Rx UE determines whether preemption is detected (1203). If yes, it refreshes its buffer of resources indicated as preempted and decodes retransmissions (1205). If no, the Rx UE decodes the retransmissions by soft combining (1204).
[0238] For the retransmission scheduling, such as Figure 3 , Figure 4 , Figure 5 The solutions disclosed for dynamically scheduled broadcasts are also applicable here.
[0239] Use adjusted transmission control parameters to preempt low priority SL transmissions
[0240] In the second alternative case, the gNB may 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 a power reduction indicator for the dynamically scheduled broadcast sidelink may also be applied here. The gNB may send the power reduction indicator only to the Tx UE, or the gNB may 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.
[0241] For Tx UE, after detecting the power reduction indicator, UE1 can rewrite the old TPC and send the scheduled unicast sidelink with the new transmit power. Then, it will monitor the feedback, such as ACK / NACK, sent by UE2 through PSFCH.
[0242] The Tx UE behaviors, retransmission allocation methods disclosed in the alternative case of Uu transmission preemption using higher power may also be applied here.
[0243] Fig.13 An example of a disclosed process for a Tx UE to detect a power reduction indicator is shown for a sidelink UE having an inter-UE conflict 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 refreshes 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).
[0244] For Rx UE, UE2 may try to decode the transmitted data and send feedback to UE1. When UE2 cannot decode the data, it may send a NACK to UE1.
[0245] The Rx UE behavior disclosed in the alternative case of Uu transmission preemption using higher power may also be applied here.
[0246] Fig.14 An example of a disclosed process for an Rx UE to detect a power reduction indicator is shown for a sidelink UE having an inter-UE conflict 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 yes, it determines whether the received data is successfully decoded (1403). If yes, it sends an ACK and refreshes its buffer (1404). If no, it refreshes the buffer of the preempted resources 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 yes, it sends an ACK and refreshes its buffer (1407). If no, the UE decodes the retransmission by soft combining (1408).
[0247] Use cancel indicator to preempt low priority SL transfers
[0248] In a third alternative scenario, UE1 may monitor to detect whether it is preempted before performing a unicast sidelink transmission. If preemption occurs, the gNB may send a cancel indication, thereby instructing UE1 to cancel the scheduled transmission.
[0249] The scheme for sending cancellation indication disclosed for the dynamically scheduled broadcast sidelink can also be applied here. The gNB can send the cancellation indication only to the Tx UE, or the gNB can send the cancellation indication 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.
[0250] For the Tx UE, by detecting the cancellation indication, UE1 will not perform all or part of the scheduled transmission as instructed, and will retransmit later.
[0251] In one case, UE1 may retransmit and send preemption information to UE2 to instruct UE2 to flush the buffer accordingly. The solution disclosed in the alternative case of preemption using higher power Uu transmission can also be applied here.
[0252] 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.
[0253] In yet another case, if UE1 detects a cancellation indication before sending SCI (e.g., first phase) for the scheduled sidelink transmission, UE1 cannot send SCI (e.g., both first phase SCI and second phase SCI) to UE2. Alternatively, if SCI (e.g., first phase SCI) has 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. The indication may be a reference signal, or a preamble, or a sequence, or SCI, for example, using the preemption indication field in the second phase SCI.
[0254] When there is a time interval between the transmission of the first stage SCI and the second stage SCI, the example provided for the above case can be applied. In another example, the first stage SCI and the second stage SCI can be sent without any time interval between them, for example, the first stage SCI and the second stage SCI can be frequency division multiplexed (FDM) and sent together with the data; or the first stage SCI and the second stage SCI can be sent 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 for ignoring the sidelink transmission indicated by the previous SCI, for example, the reserved retransmission or the reserved periodic transmission. Such an indication (e.g., the preemption indication field) can be carried by the first stage SCI or can be carried by the second stage SCI.
[0255] 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.
[0256] In one example, when the Tx UE detects that the scheduled sidelink transmission on the PSSCH is preempted by other transmissions, the Tx UE may discard the transmission of the PSSCH. The Tx UE may only send 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 of the same TB.
[0257] 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 be 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.
[0258] 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 sent to send an indication. The indication may be a preconfigured reference signal, or a preconfigured preamble, or a preconfigured sequence. For example, the Rx UE may be configured with a value of an initializer, 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.
[0259] When the Tx UE detects that the transmission of the second stage SCI is preempted by other transmissions, the Tx UE may discard both the transmission of the second stage SCI and the transmission of the associated PSSCH.
[0260] The scheme disclosed here for unicast side link transmission can also be applied to the cases of broadcast side link transmission and multicast side link transmission.
[0261] 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.
[0262] Fig.15 An example of a disclosed process for a Tx UE to detect a cancellation indication is shown in FIG. 15 for a sidelink UE having 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 detects 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).
[0263] In one case, for Rx UE, UE2 may receive a cancellation indication from the gNB. Depending on the time when the cancellation indication is received, UE2 may ignore the scheduled sidelink transmission or may flush the buffer of the cancelled resources when decoding the retransmission.
[0264] In another case, UE2 may receive a retransmission from UE1 and receive a preemption indication. UE2 may flush its buffer and decode the retransmission.
[0265] In yet another case, UE2 may receive an indication from UE1 to ignore the scheduled sidelink transmission because it has been cancelled 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 buffer and decode the retransmission.
[0266] Fig.16An example of a disclosed process for an Rx UE to detect a cancellation indication is shown for a sidelink UE having an inter-UE conflict 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 via soft combining (1607). If a 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). Preemption of a dynamically scheduled multicast sidelink transmission by a dynamically scheduled Uu transmission
[0267] In this section, a solution is disclosed for the case where a dynamically scheduled Uu transmission conflicts with a dynamically scheduled multicast sidelink transmission. In a multicast scenario, a Tx UE needs to send data to multiple Rx UEs and receive ACK / NACK from all or some of the Rx UEs. Since the channels between the Tx and Rx UEs may be different for the Rx UEs in the group, for a multicast transmission, some Rx UEs may be able to successfully decode it, while some other Rx UEs may not be able to decode it. The Uu transmission in this article can be a downlink transmission or can be an uplink two-way transmission.
[0268] Assume that UE1 is dynamically scheduled by the gNB to send multicast transmissions 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 transmission or reception on the Uu interface (e.g., PDSCH or PUSCH), where some or all of the resources allocated to UE3 overlap in time with the resources allocated to UE1. To handle inter-UE conflicts, the multicast sidelink transmissions may be preempted in the following alternative cases.
[0269] Preemption of Uu transmissions using higher power
[0270] In the first alternative case, UE1 will perform multicast sidelink transmission regardless of whether it receives preemption.
[0271] 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.
[0272] For Tx UE, after UE1 performs multicast sidelink transmission, it will monitor the feedback sent by Rx UE through PSFCH, such as ACK / NACK. UE1 can also monitor the indication sent by gNB to determine whether its transmission is preempted, where the configuration of monitoring timing can be configured by RRC.
[0273] When UE1 sends a multicast message, one beam can be used to multicast the message to all Rx UEs.
[0274] The Tx UE behavior disclosed in the alternative case of Uu transmission preemption using higher power may also be applied here together with the feedback sent by the scheduled Rx UE.
[0275] 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 space-multiplexed. UE1 can monitor each beam separately and detect whether it is preempted through explicit signaling 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 the preemption based on the preempted time and frequency resources. The processes and behaviors disclosed for multicast using one beam can also be applied here.
[0276] When UE1 performs retransmission, it may retransmit the entire TB or it may retransmit only a subset of the TB, e.g., the preempted symbols, PRBs, or CBGs. When multiple beams are used for multicast, UE1 may retransmit the multicast message on all beams or it may retransmit the multicast message on the preempted beams.
[0277] When inter-UE collision occurs, the gNB may allocate resources for retransmission to UE1 without receiving feedback from UE1. Alternatively, the gNB may allocate resources for retransmission based on feedback from UE1. The same scheme proposed in the alternative case of detecting preemption after initial transmission of unicast can also be applied here.
[0278] Fig.17An example of a disclosed process for a Tx UE to detect a preemption indication is shown in FIG. 17 for a sidelink UE having an inter-UE conflict 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 is successful (1704). If yes, the Tx UE's transmission is successful and refreshes its buffer (1708). If no, the Tx UE determines whether it detects preemption (1705). If no, 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).
[0279] For an Rx UE that successfully decodes the multicast message, the Rx UE may ignore subsequent scheduling of retransmissions for failed UEs.
[0280] For the Rx UE that fails to decode the message, the disclosed Rx UE behavior for preemption of Uu transmissions using higher power in unicast scenarios may also be applied here.
[0281] Fig.18 An example of a disclosed process for an Rx UE to detect preemption is shown in FIG. 1 for a sidelink UE having an inter-UE conflict 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 is 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 together with the HARQ feedback and decodes the retransmissions by 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 together 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).
[0282] For the retransmission scheduling, such as Figure 3 , Figure 4 , Figure 5 The solutions presented for dynamically scheduled broadcasts can also be applied here.
[0283] Use adjusted transmission control parameters to preempt low priority SL transmissions
[0284] In the second alternative case, the gNB may send an indication to instruct UE1 to adjust the transmission control parameters before UE1 performs the scheduled initial multicast transmission. The scheme disclosed for how to send the power reduction indicator for the dynamically scheduled broadcast sidelink can also be applied here. The gNB may send the power reduction indicator only to the Tx UE, or the gNB may 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.
[0285] The Tx UE behavior disclosed in the alternative case of Uu transmission preemption using higher power in multicast scenario can also be applied here.
[0286] When multiple beams are used to multicast messages to Rx UEs in different directions, UE1 can monitor each beam separately and detect whether it is preempted. Assume that 3 beams are used in multicast. For example, if beam 1 is preempted and beam 2 and beam 3 are not preempted, UE1 can only reduce the transmission power on beam 1. The procedures and behaviors disclosed for multicast using one beam can also be applied here.
[0287] Fig.19 An example of a disclosed process for a Tx UE to detect a power reduction indicator is shown for a sidelink UE having an inter-UE conflict 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 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 refreshes its buffer (1907). If no, the UE retransmits and sends the preemption information to the Rx UE (1906).
[0288] The Rx UE behavior disclosed in the alternative case of Uu transmission preemption using higher power may also be applied here.
[0289] Fig. 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 having an inter-UE conflict with a scheduled Uu transmission. The Rx UE receives a schedule for reception of a unicast sidelink transmission (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 the retransmission by 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 reduced power 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 no, the Rx UE flushes its buffer of the preempted resource and decodes the retransmission (2008).
[0290] Use the adjusted transmission control parameter cancel indicator to preempt the low priority SL transmission
[0291] In a third alternative scenario, UE1 may monitor to detect whether 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.
[0292] The scheme for sending cancellation indication disclosed for the dynamically scheduled broadcast sidelink can also be applied here. The gNB can send the cancellation indication only to the Tx UE, or the gNB can send the cancellation indication 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.
[0293] For the Tx UE, by detecting the cancellation indication, UE1 will not perform all or part of the scheduled transmission as instructed and will retransmit later.
[0294] When UE1 sends a multicast message, one beam can be used to multicast the message to all Rx UEs.
[0295] The Tx UE behavior disclosed in the alternative case of Uu transmission preemption using higher power in multicast scenario can also be applied here.
[0296] In addition to the disclosed Tx UE behavior, if UE1 detects a cancellation indication before sending an SCI for a scheduled sidelink transmission, UE1 may 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.
[0297] 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 and detect whether it is preempted. Assume that 3 beams are used in multicast. For example, if beam 1 is preempted and beam 2 and beam 3 are not preempted, UE1 can cancel the transmission on beam 1 only. The procedures and behaviors disclosed for multicast using one beam can also be applied here.
[0298] Fig.21 An example of a disclosed process for a Tx UE to detect a cancellation indication is shown for a sidelink UE having 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 is 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).
[0299] For the 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.
[0300] In another case, the Rx UE may receive a retransmission and receive a preemption indication from UE 1. The Rx UE may flush the buffer and decode the retransmission.
[0301] In yet another case, the Rx UE may receive an indication from UE1 to ignore the scheduled sidelink transmission because it was cancelled 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 are preempted. The Rx UE may flush the buffer and decode the retransmission.
[0302] Fig. 22 An example of a disclosed process for an Rx UE to detect a cancellation indication is shown for a sidelink UE having an inter-UE conflict with a scheduled Uu transmission. The Rx UE receives a schedule for unicast sidelink reception (2201). The UE determines whether its received data is successfully decoded (2202). If yes, the UE sends an ACK and refreshes its buffer (2207). If no, if the UE is scheduled to send feedback, the UE sends a NACK (2203). The UE determines whether it has received preemption information along with a retransmission (2204). If no, the UE decodes the retransmission by soft combining (2205). If yes, the Rx UE refreshes its buffer for the preempted resources and decodes the retransmission (2206).
[0303] Preemption of sidelink transmission based on configuration grant by Uu transmission
[0304] In this section, a solution is disclosed for the case where a sidelink transmission based on a configuration grant is preempted by a dynamically scheduled Uu transmission. The Uu transmission herein may be a downlink transmission or an uplink transmission.
[0305] When resources are allocated to a UE via a configuration grant for sidelink transmission. The allocated resources can be dedicated to this UE. For example, time and frequency resources are configured to only one UE as a configuration grant. At the same time, the gNB will not schedule any other SL transmission or Uu transmission on these resources. Alternatively, the allocated resources can be shared with other UEs. For example, the gNB can schedule another high priority Uu transmission or SL transmission on these resources as needed. The same time and frequency resources can also be allocated to multiple UEs as a configuration grant. If the allocated resources are dedicated to one 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 the UE performs sidelink transmission using the configuration grant resources.
[0306] 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, an RRC parameter ConfiguredGrantShared with possible values of "yes" and "no" may be used; or an RRC parameter ConfiguredGrantSharingStatus with possible values of "shared" and "dedicated" may be used.
[0307] In configuring grant type 2, such an indication may be indicated by RRC or activation DCI. When using RRC, the scheme proposed for configuring grant type 1 also applies to configuring grant type 2. Alternatively, when using activation DCI, a new field may be introduced in the activation DCI for this purpose. An example of the shared status indicator field is shown in Table 3. Alternatively, one bit may 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.
[0308] In various embodiments herein, sidelink configuration grant type 1 and type 2 may be equivalent to Uu UL configuration grant type 1 and 2; or Uu UL configuration grant type 1 and 2 may be used as a baseline, but with potential enhancements.
[0309] Table 3 Activate the shared status indicator field in the DCI
[0310]
[0311] When the 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 the 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.
[0312] In an alternative case, whenever it schedules where some of the resources overlap with the resources of the 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. The indication may be a preemption indication as disclosed in the previous section, or a power reduction indicator, or a cancellation indication. At the same time, 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.
[0313] If any UE determines to transmit data at a configured grant opportunity k, the UE may monitor and detect the indication sent by the gNB (e.g., before performing a sidelink transmission). The UE may then determine that it is preempted and handle this issue for broadcast, multicast, and unicast using the procedures disclosed for inter-UE conflict handling between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions. In general, the solutions proposed for dynamically scheduled broadcast, multicast, and unicast may also be applied here.
[0314] In one example, when the Tx UE is configured to send multiple repetitions of the same TB on the sidelink using the 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 send the preempted (one or more) repetitions (e.g., repetitions overlapping the canceled resources) while still sending the non-preempted (one or more) repetitions. The Tx UE can then monitor feedback (e.g., ACK / NACK feedback) from the Rx UE to determine whether the transmission is successful. If the transmission fails, the Tx UE can send an indication to the gNB to request scheduling of retransmissions, for example, the indication can be NACK feedback.
[0315] 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 Fig.23 . The UE receives information of configured grant resources for sidelink transmission (2301). The UE determines whether the configured grant is dedicated to the UE (2302). If yes, the UE uses the configured grant when the UE has data to send (2311). If no, the UE determines whether the UE has data to send at the next configured grant opportunity (2303). If yes, 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 no, the UE sends data at the next configured grant opportunity (2310). If preemption is detected (2305), the UE determines whether all repetitions are preempted (2306). If yes, the UE sends an indication to the gNB to request resources for transmission (2309). If not all repetitions are preempted (2306), the UE sends the repetitions that are not preempted at the next configured grant opportunity (2307). The UE determines whether the Rx UE successfully receives the transmission (2308). If no, the Tx UE sends an indication to the gNB to request resources for transmission (2309).
[0316] 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.
[0317] Alternatively, the UE may monitor and detect that there is no preemption on the configured grant opportunity k. The UE may then perform sidelink transmission using the resources in the configured grant opportunity k.
[0318] 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.
[0319] 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 a 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 in the bitmap (i=1, 2,…, L) is indicated as '0', the Rx UE may determine that the i-th repetition is sent and may be soft combined 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.
[0320] In yet another example, the Tx UE may be configured with multiple configuration grants. When the Tx UE determines to send data on one configuration grant (e.g., configuration grant A), and the Tx UE detects that it is preempted by other transmissions, it may discard the transmission on configuration grant A and perform 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.
[0321] Alternatively, when the Tx UE determines to send data on one configuration grant (e.g., configuration grant A), and the Tx UE detects that it is preempted by other transmissions, it cannot send the preempted repetitions while sending the non-preempted repetitions. If the Tx UE detects that the Rx does not receive the transmission, it can perform a retransmission on another configuration grant (e.g., configuration grant B). For example, configuration grant B can be the next available configuration grant in all configured CGs. In order to enable the Rx UE to soft-combine repetitions of the same TB in different configuration grants, the Tx UE can indicate the same HARQ process ID, where the NDI field does not switch for transmissions in configuration grant A and configuration grant B. If no UE determines to send data on configuration grant time k, this indication can become an invalid message and no UE will monitor and detect it.
[0322] 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.
[0323] In one case (e.g., when a Uu UL transmission preempts a sidelink transmission), the gNB can monitor the received power level to determine if there is another transmission in the channel. When the gNB detects another transmission, although the gNB cannot decode it, the gNB can determine that there is an inter-UE collision. The gNB can then schedule a retransmission for the configured authorized UE. This scheme can be applied to the power-based inter-UE collision handling scheme.
[0324] In another case, when the V2X Tx UE has data to send at the CG opportunity and detects that it is preempted, the UE may 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 may be SR, or BSR, or NACK feedback, or reference signal, or preamble, or sequence. An example of the disclosed process is Fig.24 . The Tx UE receives configured grant resources for sidelink transmission (2401). The UE determines whether the configured grant is dedicated to the UE (2402). If yes, the UE uses the configured grant whenever the UE has data to send (2408). If no, the UE determines whether the UE has data to send at the next configured grant opportunity (2403). If yes, the UE sends 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 yes, the UE sends an indication to the gNB to request resources for retransmission (2407).
[0325] 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 to inform the gNB that it has data to send. For example, the indication may be an SR, or a BSR, or a reference signal, or a preamble, or a sequence. The indication may be sent on a PUCCH resource before the configured grant resource. The time offset between the PUCCH and the configured grant opportunity may be fixed or may be configurable. Alternatively, the indication may be sent on (one or more) dedicated symbols (e.g., the first symbol in the configured grant), or the indication may be sent on some REs in the first symbol.
[0326] In this alternative case, if the gNB expects 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 the inter-UE conflict, where the indication may be a preemption indication, a power reduction indicator, or a cancel indication, as disclosed in the previous section.
[0327] If the UE determines to send data at the configured authorization time k, the UE can monitor and detect whether it is preempted. If the UE detects that it is preempted, it can use the process disclosed for the inter-UE conflict handling between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle this problem 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 is preempted, the UE can send data at CG time k without waiting for new scheduling.
[0328] Since the gNB is aware of the inter-UE collision, the gNB can configure the grant sidelink scheduling retransmission for the UE without receiving feedback from the Tx UE. Alternatively, the gNB can schedule retransmission based on feedback from the Tx UE as disclosed in the dynamically scheduled multicast and unicast scenarios.
[0329] Meanwhile, when a UE (e.g., UE1) with a configured grant sends an indication to the gNB to inform it that it has data to send, UE1 may 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 may schedule another more urgent transmission on the same resources and send an indication of inter-UE conflict to UE1.
[0330] Examples of public procedures are in Fig.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 to indicate 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 schedule for retransmission from the gNB and retransmits (2508).
[0331] The disclosed scheme may 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.
[0332] The disclosed scheme may also be applied to a conflict between two Uu transmissions, for example, a conflict between two UL transmissions on the Uu interface.
[0333] Signaling of the sidelink cancellation indicator
[0334] Sidelink Cancel Indicator Monitoring
[0335] 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 granted 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.
[0336] 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.
[0337] Alternatively, in another example, the UE may be configured by the gNB to start from the kth slot after the slot carrying the DCI for the scheduled sidelink transmission. 偏移,1 The SL-CI is monitored starting from the time slot of the first time slot. For example, the k configured by RRC signaling 偏移,1 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, the UE may be configured with a cell-specific RR configuration. 偏移,1 , for example, via the RRC parameter SLCIMonitorOffset configured in the SIB, for example, OSI.
[0338] Alternatively, in yet another example, the UE may be configured by the gNB to receive the sidelink transmission scheduled by the dynamic grant from the k-th slot preceding the time slot carrying the sidelink transmission scheduled by the dynamic grant. 偏移,2 The SL-CI is monitored from the time slot of k. 偏移,1 Similarly, k can be configured through RRC signaling 偏移,2 , for example, through a UE-specific RRC configuration, or through a cell-specific RRC configuration.
[0339] In one example, for a UE configured with a configured grant for sidelink transmission, the UE may be configured by the gNB to start from the kth slot after 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 monitor the SL-CI from the next time slot of the time slot carrying the previously configured grant opportunity.
[0340] For configuration authorization type 1 and configuration type 2, k 偏移,3 or k 偏移,4The value of can be configured by RRC, for example, via the RRC parameter SLCIMonitorOffset configured in the SLConfiguredGrantConfig information element.
[0341] In another approach, for configuration grant type 2, a set of k 偏移,3 or k 偏移,4 The activation DCI may carry a field (e.g., SL CI monitoring offset field) to indicate to the UE one of the candidate values within the group.
[0342] In one example, for a UE scheduled with dynamic grant and a UE configured with a configured grant, the UE may be scheduled to receive a PSSCH k seconds before the slot carrying the PSSCH. 停止 The SL-CI monitoring is stopped for k time slots or symbols. 停止 It may be the minimum processing time of the SL-CI and the time to prepare the updated SCI (eg, the second stage SCI).
[0343] Or, 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 The UE can start monitoring k time slots after the time slot it starts monitoring. mw Stop SL-CI monitoring for each time slot.
[0344] Determine the time zone of the SL-CI reference
[0345] After the UE detects the SL-CI, in order to understand the information it carries, the UE needs to determine the time area and frequency area referenced by the SL-CI.
[0346] For example, in order to determine the start of a time region, the timing offset between the SL-CI and the referenced time region may be indicated to the UE. In one example, the timing offset may be configured via RRC, for example via the RRC parameter SLCITimeRegionOffset. The timing offset may be in symbols, or the timing offset may also be in slots. The scheme proposed for configuring the RRC parameter SLCIMonitorOffset may also be applied here.
[0347] 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., SL CI time offset field) to indicate to the UE one of the candidate values within the set.
[0348] 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, etc. The timing duration can be in symbols, or the timing offset can also be in time slots. The solution proposed for configuring the RRC parameter SLCIMonitorOffset can also be applied here.
[0349] 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.
[0350] In some cases, the sidelink transmission and the Uu interface sending the SL-CI may have different subcarrier spacing (SCS). In one example, the SCS of the sidelink transmission may be used as a reference SCS to determine the time region, for example, the timing offset and duration are indicated in 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, for example, the timing offset and duration are indicated in the number of time slots or symbols on the Uu interface.
[0351] Determine the frequency region of the SL-CI reference
[0352] At the same time, the UE also needs to determine the frequency region referenced by the SL-CI. In one example, the frequency region may be implicitly indicated, for example, the frequency region may be the entire sidelink BWP; or the frequency region may be a frequency band shared by the Uu service and the sidelink service.
[0353] In another example, the frequency region may be explicitly indicated relative to the sidelink BWP. For example, to determine the frequency region, the number of subchannel offsets may be configured for the UE relative to the lowest subchannel of the sidelink BWP, e.g., via an RRC parameter SLCIFrequencyRegionOffset; and the number of subchannels occupied by the frequency region may be configured for the UE, e.g., via an 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 may also be in units of the number of PRBs.
[0354] 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.
[0355] Determine when and how often resources are actually canceled
[0356] In the reference time zone and frequency zone, the gNB can use SL-CI to indicate the actual cancelled time and frequency resources.
[0357] 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, by RRC parameters SLCITimePayloadSize and SLCIFrequencyPayloadSize, respectively. The UE may divide the reference time region and the reference frequency region into b evenly, respectively. 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.
[0358] 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 or n F One of the values of .
[0359] The UE can be configured with n T The value of, for example, is configured by the RRC parameter SLCINumberofTimeProtion.
[0360] 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.
[0361] 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.
[0362] In the above example, the UE is indicated with information of time granularity. Alternatively, the UE may 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.
[0363] Inter-UE contention handling in NR V2X Mode 1 with repeated sidelink transmissions scheduled by NB.
[0364] 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 Fig.26 shown.
[0365] The initial transmission and repetitions may be sent in adjacent time slots as shown. Alternatively, the time interval between the initial transmission and the repetitions may be several time slots.
[0366] Please note, Fig.26An example of a gNB scheduling a sidelink transmission with multiple repetitions is shown. The gNB may also schedule a sidelink transmission with multiple HARQ-based retransmissions. Alternatively, the gNB may schedule periodic sidelink transmissions. In the following, we disclose the scheme using a sidelink transmission with multiple repetitions as an example. The disclosed scheme may also be applied to a sidelink transmission with multiple HARQ-based retransmissions and a periodic sidelink transmission. For example, by replacing the repetitions in the scheme with HARQ-based retransmissions, the disclosed scheme may also be applied to a sidelink transmission with multiple HARQ-based retransmissions.
[0367] SL-CI is sent only before the initial transmission
[0368] 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.
[0369] 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 where the second-stage SCI should have been sent to send an indication to indicate that the transmission has been canceled.
[0370] In one case, if SL-CI is detected and the Tx UE determines that one or some of the initial transmission and the repetition are cancelled, the Tx UE may discard all scheduled initial transmissions and repeated transmissions. The Tx UE may send an indication to the Rx UE using the above proposed scheme to indicate that all scheduled transmissions are cancelled.
[0371] In another case, when the Tx UE determines that one or some of the initial transmission and the repetition 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 Fig.26As shown. For example, assume that the Tx UE detects the SL-CI and determines that the 1st and 3rd repetitions overlap with the cancelled resources. The Tx UE may discard the transmission of the 1st and 3rd repetitions while still sending the initial transmission and the 2nd 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.
[0372] When the Rx UE detects the indication sent by the Tx UE indicating the 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.
[0373] SL-CI is sent before the initial transmission and during repetitions. The Tx UE indicates the preemption information in each repetition.
[0374] In another example, the SL-CI may be signaled by the gNB prior to the initial transmission and during the scheduled sidelink transmission (before the last repetition). The Tx UE may monitor the SL-CI prior to the initial transmission and continue monitoring until the last repetition is reached. Fig. 27 An example is shown in which an 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 may also be possible for one SL-CI to indicate that multiple repetitions are cancelled.
[0375] In this example, the Tx UE may only discard transmissions that overlap with the cancelled resources, such as 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.
[0376] 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), or via a preconfigured sequence, or via control information.
[0377] 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.
[0378] 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.
[0379] use Fig. 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'.
[0380] The preemption indication field in the second stage may be a bitmap, where the length of the bitmap is equal to the total number of initial transmissions and repetitions. This field may 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 may set the bitmap sent in different repetitions to different values.
[0381] use Fig. 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 1st repetition to '0000' and '0000', respectively. Before sending the 2nd repetition, the Tx UE detects that the PSSCH in the 2nd repetition is preempted. The Tx UE will set the Preemption Indication field sent in the 2nd repetition to '0010'. Before sending the 3rd repetition, the Tx UE does not detect any further preemption. Then the Tx UE will set the Preemption Indication field sent in the 2nd repetition to '0010'.
[0382] SL-CI is sent before the initial transmission and during repetitions, the Tx UE indicates preemption information only in the last repetition
[0383] 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 (eg, SL-DMRS), or via a preconfigured sequence, or via control information.
[0384] 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.
[0385] use Fig. 27 As an example, the preemption information sent in the last repetition may be 4 bits.
[0386] In one method, no dedicated SCI field may be introduced for sending preemption information in the second stage SCI. In the initial transmission, the Tx UE cannot indicate the preemption information in the second stage SCI. In the last repetition, the Tx UE may reuse the existing field in the second stage SCI to indicate the preemption information. For example, the Tx UE may reuse the first 4 bits of the MCS field carried by the second stage SCI in the last repetition and set it to '0010' to indicate that the second repetition is preempted and other repetitions are not preempted.
[0387] In another method, a dedicated SCI field may be introduced for sending preemption information in the second stage SCI, for example, a 4-bit SCI field preemption indication field. Such a field may be carried by the second SCI sent in both the initial transmission and the last repetition. For example, before the initial transmission, the Tx UE does not detect any preemption. The Tx UE may set the preemption indication field in the initial transmission to '0000'. Before the last repetition, the Tx UE detects that the second repetition is preempted. The Tx UE may set the preemption indication field in the last repetition to '0010'.
[0388] 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 Fig.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 the repetition. The SL-CI sent by the Tx UE to the Rx UE to indicate the 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 may be carried by the second stage SCI.
[0389] 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 Fig.28 The disclosed scheme can be applied to sidelink transmission with multiple HARQ-based retransmissions; and can be applied to periodic sidelink transmission.
[0390] Intra-UE prioritization for simultaneous sidelink and uplink transmissions
[0391] In NR V2X, a UE may be scheduled to perform simultaneous sidelink and uplink transmissions, where the carrier for the sidelink transmission and the carrier for the uplink transmission may be different carriers or may be a shared carrier. CMAX ), 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.
[0392] Prioritization using the indicated priority indicators
[0393] In one example, each transmission (e.g., a sidelink transmission or an uplink transmission) may be indicated as having a priority. The value of the priority may be explicitly signaled by RRC, such as via an RRC parameter TransmissionPriorityLevel, or may be pre-specified by the specification. For sidelink transmissions, the TransmissionPriorityLevel may be configured within an information element that configures a resource pool (e.g., SLResourcePoolConfig).
[0394] In one example, a priority may be configured / pre-assigned for transmission of SL-PSCCH, SL-PSSCH, and SL-PSFCH. For example, SL-PSCCH, SL-PSSCH, and SL-PSFCH may 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.
[0395] 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, SLPSFCHPriorityLevel may be configured separately for the UE.
[0396] In yet another example, dedicated resource pools may be separately configured / pre-assigned for SL-PSCCH, SL-PSSCH, and SL-PSFCH, wherein different priorities may be respectively configured within the associated resource pool configurations.
[0397] Priority may 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 may be configured or pre-specified by the RRC; and the DCI that schedules may carry a field (e.g., PSCCH Priority) to indicate to the UE one of the candidate values within the group.
[0398] Priorities may also be derived implicitly. For example, the priority of SL-PSFCH may be equal to the priority indicated for SL-PSSCH.
[0399] For PSCCH, the same priority may be indicated for the first stage SCI and the second stage SCI. Alternatively, different priorities may be indicated for the first stage SCI and the second stage SCI separately, for example, respectively indicated by two RRC configurations SL1stSCIPriorityLevel and SL2ndSCIPriorityLevel.
[0400] 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 the UE has simultaneous sidelink and uplink transmissions, the UE may prioritize transmissions with higher priorities, for example, transmissions with smaller priority values may be prioritized.
[0401] 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.
[0402] 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.
[0403] When SL CSI feedback and CSI feedback on uplink have the same priority value, SL CSI feedback may be prioritized.
[0404] 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:
[0405] ● 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 can have a higher probability of being delivered.
[0406] ● Package size: Because a transmission with a high priority may cause preemption of other transmissions. The UE may prioritize transmissions that require less resources to reduce potential preemption of other UEs. ● Remaining time before the UE must discard a packet: Two transmissions may have different processing timelines and therefore may have different remaining times before a packet must be discarded. The UE may prioritize transmissions with shorter remaining times to reduce the discard rate.
[0407] Priority sorting without a priority indicator
[0408] 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.
[0409] The UE may prioritize transmissions according to the following priority sorting rules:
[0410] 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.
[0411] Where 'A>B' means that the transmission of A takes precedence over the transmission of B.
[0412] 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:
[0413] 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.
[0414] The dynamically scheduled side link transmission preempts the other side link transmission
[0415] In NR V2X Mode 1, it is possible to allocate overlapping resources for two dynamically scheduled sidelink transmissions, such as Fig.29 As shown. For example, UE1 is dynamically allocated resources for sidelink transmission. Then, the gNB may determine to allocate some overlapping resources to UE2 and preempt UE1's transmission, for example, because UE2 may have more urgent data to send. Therefore, an inter-UE conflict will occur. The inter-UE conflict may occur on a shared carrier; or, it may occur on a dedicated carrier. In this section, we disclose an inter-UE conflict handling solution for such a scenario.
[0416] In an alternative case, the inter-UE conflict may be transparent to UE2, and in order to indicate the inter-UE conflict to UE1, the gNB may send an indication to UE1, where the indication may be a preemption indication, or a power reduction indicator, or a cancellation indication, as disclosed in the previous section.
[0417] For UE1, it can monitor and detect whether it is preempted by the gNB. When UE1 determines that it is preempted, it can handle this problem of broadcast, multicast and unicast using the procedures disclosed for inter-UE conflict handling 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.
[0418] In another alternative, the gNB may indicate the inter-UE conflict to UE2 and let UE2 know that it will preempt other transmissions. For example, this may be indicated by a DCI with an explicit bit field for scheduling, or it may be signaled implicitly. Once UE2 determines that it will preempt other transmissions, UE2 may send an indication to indicate the inter-UE conflict, where the indication may be a preemption indication, or a power reduction indicator or a cancellation indication, as disclosed in the previous section. The indication may be a preamble, or a sequence, or a reference signal, or a broadcast SCI, or a broadcast portion of a two-stage SCI.
[0419] For UE1, it can monitor and detect whether it is preempted by other V2X UEs. When UE1 determines that it is preempted, it can use the disclosed procedures for inter-UE conflict handling between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle this problem for broadcast, multicast and unicast. In general, the solutions proposed for dynamically scheduled broadcast, multicast and unicast can also be applied here.
[0420] Sidelink transmissions based on configuration grants are preempted by dynamically scheduled sidelink transmissions.
[0421] In NR V2X Mode 1, a 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 Fig.30 As shown. For example, UE1 is allocated configured granted resources for sidelink transmission. Then, the gNB may determine to allocate some overlapping resources to UE2 in time slot #2. At the same time, if UE1 also has data to send in the CG opportunity configured in time slot #2, an inter-UE conflict will occur. The inter-UE conflict may occur on a shared carrier; or, it may occur on a dedicated carrier. In this section, we disclose an inter-UE conflict handling solution for such a scenario.
[0422] 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.
[0423] 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 configuring the grant side link and dynamic Uu transmissions. The solutions proposed for handling inter-UE conflicts between configuring the grant side link and dynamic Uu transmissions can also be applied here. Some examples are Fig.24 and Fig.25 shown.
[0424] 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.
[0425] The gNB assumes that inter-UE collisions will occur
[0426] In a first alternative case, the gNB may send an indication of inter-UE conflict to UE2, thereby informing UE2 that other transmissions will be preempted. For example, by means of a DCI with an explicit bit field for scheduling, or may be implicitly signaled. Once UE2 determines that it will preempt other transmissions, UE2 may send an indication to indicate the inter-UE conflict, wherein the indication may be a preemption indication, or a power reduction indicator, or a cancellation indication, as disclosed in the previous section. The indication may be a preamble, or a sequence, or a reference signal, or a broadcast SCI, or a broadcast portion of a two-stage SCI.
[0427] For UE1, when it determines to send data at the next configured authorization opportunity, it can monitor and detect whether it is preempted by other V2X UEs. When UE1 determines that it is preempted, it can use the disclosed process for inter-UE conflict handling between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle this problem for broadcast, multicast and unicast. In general, the solutions proposed for dynamically scheduled broadcast, multicast and unicast can also be applied here.
[0428] 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.
[0429] In one scenario, the gNB can monitor the power level to determine if there is another transmission in the channel. When the gNB detects another transmission, although the gNB cannot decode it, the gNB can determine that there is an inter-UE collision. The gNB can then schedule a retransmission for the configured authorized UE. This scheme can be applied to the power-based inter-UE collision handling scheme.
[0430] In another case, when UE1 has data to send at a CG opportunity and detects that it is preempted, UE1 may 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 may be an SR, or a BSR, or a reference signal, or a preamble, or a sequence.
[0431] CG UE sends an indication of waiting for transmission at the next CG opportunity
[0432] In the second alternative case, when UE1 determines to send data on the configured CG opportunity (e.g., CG opportunity k), it can send an indication to the gNB to inform it that there is data to send. For example, the indication can be an SR, or a BSR, or a reference signal, or a preamble, or a sequence.
[0433] In this alternative case, 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, informing UE2 that other transmissions will be preempted. For example, through a DCI with an explicit bit field for scheduling, or it can be implicitly signaled. Once UE2 determines that it will preempt other transmissions, UE2 can send an indication to indicate the inter-UE conflict, where the indication can be a preemption indication, or a power reduction indicator, or a cancellation indication, as disclosed in the previous section. The indication can be a preamble, or a sequence, or a reference signal, or a broadcast SCI, or a broadcast part of a two-stage SCI.
[0434] For UE1, it can monitor and detect whether it is preempted at CG time k. When the UE determines that it is preempted, it can use the process disclosed for inter-UE conflict handling between dynamically scheduled Uu transmissions and dynamically scheduled sidelink transmissions to handle this problem of 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 time k without waiting for new scheduling.
[0435] 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.
[0436] 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 granted side link and dynamic Uu transmission.
[0437] 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, a server, an M2M terminal device, an M2M gateway device, etc., the systems, methods, and processes described herein are executed 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 technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tapes, 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.
[0438] In describing the preferred embodiment of the disclosed subject matter, as shown in the figures, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.
[0439] 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 basic characteristics. Therefore, the embodiments disclosed at present are considered to be illustrative rather than 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, according to the above teachings, modifications and changes are possible, 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 technicians 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 changes within the spirit and scope of the disclosed subject matter.
[0440] Unless explicitly stated, reference to an element in the singular is not intended to mean "one and only one," but rather "one or more." Further, 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 may exist alone in an embodiment, B may exist alone in an embodiment, C may exist alone in an embodiment, or any combination of elements A, B, and C may exist in a single embodiment; for example, A and B, A and C, B and C, or A and B and C.
[0441] According to 335 U.S.C. 112 (f), any claim element herein will not be interpreted unless the phrase "means" is used to expressly recite the element. As used herein, the terms "include," "comprise," or any other variation thereof are intended to cover non-exclusive inclusions, such that a process, method, article, or device that includes a list of elements includes not only those elements, but may also include other elements that are not explicitly listed or inherent to such a process, method, article, or device. The scope of the invention is indicated by the appended claims rather than the foregoing description, and all changes within the meaning and scope and their equivalents are intended to be included therein.
Claims
1. A device comprising: One or more processors configured to: Determining a first transmission associated with a sidelink resource in a wireless communication network, wherein the first transmission corresponds to a physical sidelink feedback channel (PSFCH) transmission for providing feedback for a physical sidelink shared channel (PSSCH) transmission; determining a second transmission associated with uplink resources in the wireless communication network; determining that the first transmission and the second transmission at least partially overlap in time; determining a priority associated with the PSFCH transmission based on the priority associated with the PSSCH transmission; determining a radio resource control, RRC, configuration parameter associated with the second transmission associated with the uplink resource; determining which of the first transmission or the second transmission is a higher priority transmission based on a comparison of the priority associated with the PSFCH transmission and the RRC configuration parameter associated with the second transmission; and Based on the determined higher priority transmission, one of the first transmission associated with the sidelink resources or the second transmission associated with the uplink resources is transmitted.
2. The device according to claim 1, wherein: The priority associated with the PSSCH transmission is determined based on sidelink control information SCI.
3. The device according to claim 2, wherein: The priority associated with the PSSCH transmission is explicitly indicated via the SCI.
4. The device according to claim 1, wherein: The PSSCH transmission is sent in the sidelink resource pool.
5. The device according to claim 1, wherein: The feedback provided in the PSFCH transmission includes an acknowledgement ACK or a non-acknowledgement NACK.
6. The device according to claim 1, wherein: The RRC configuration parameters are configured for a specific sidelink resource pool.
7. The device according to claim 1, wherein: The one or more processors are configured to transmit hybrid automatic repeat request (HARQ) feedback via the PSFCH.
8. A method comprising: Receiving an indication associated with a first transmission associated with a sidelink resource in a wireless communication network, wherein the first transmission corresponds to a physical sidelink feedback channel (PSFCH) transmission for providing feedback for a physical sidelink shared channel (PSSCH) transmission; receiving an indication associated with a second transmission associated with uplink resources in the wireless communication network; receiving an indication that the first transmission and the second transmission at least partially overlap in time; receiving an indication of a priority associated with the PSFCH transmission based on the priority associated with the PSSCH transmission; receiving an indication of a radio resource control (RRC) configuration parameter associated with the second transmission associated with the uplink resource; receiving an indication of a higher priority transmission associated with one of the first transmission or the second transmission, the higher priority determined based on comparing the priority associated with the PSFCH transmission and the RRC configuration parameter associated with the second transmission; and Based on the indication of the higher priority transmission, the second transmission associated with the uplink resources is received one of before or after the first transmission associated with the sidelink.
9. The method according to claim 8, wherein: The priority associated with the PSSCH transmission is determined based on sidelink control information SCI.
10. The method according to claim 9, wherein: The priority associated with the PSSCH transmission is explicitly indicated via the SCI.
11. The method according to claim 8, wherein: The PSSCH transmission is sent in the sidelink resource pool.
12. The method according to claim 8, wherein: The feedback provided in the PSFCH transmission includes an acknowledgement ACK or a non-acknowledgement NACK.
13. The method according to claim 8, wherein: The RRC configuration parameters are configured for a specific sidelink resource pool.
14. The method of claim 8, further comprising transmitting a hybrid automatic repeat request (HARQ) feedback via the PSFCH.
Citation Information
Patent Citations
Power control method and device
CN107889157A
Priority based resource selection in a device-to-device communication system
CN109478991A
Techniques and apparatuses for priority-based resource configuration
US20180316395A1