Resource Management for 5G eV2X

Abstract

A method and system for resource management in a sidelink for vehicle-to-everything (V2X) scenarios are disclosed. Exemplary methods and systems for resource structure in a sidelink are disclosed. Control and data channels may be frequency division multiplexed (FDMed) or time division multiplexed (TDMed) with an orthogonal frequency division multiplexing (OFDM) waveform. Exemplary methods and systems for resource configuration in a sidelink are disclosed. Resource configuration may be statically configured or locally configured. Exemplary methods and systems for supplemental resource allocation are disclosed. Auxiliary sensing may be performed by a group lead or an RSU, and local scheduling may be performed by a group lead or an RSU.

Description

[Background technology]

[0001] As Vehicle-To-Everything (V2X) applications advance significantly, the transmission of short messages regarding the vehicle's own status data for basic safety may need to be extended with the transmission of larger messages including raw sensor data, vehicle intent data, collaboration, confirmation of upcoming maneuvers, etc. For these advanced applications, the expected requirements to meet the required data rates, latency, reliability, communication range, and speed are made more stringent.

[0002] For enhanced V2X (eV2X) services, the 3rd Generation Partnership Project (3GPP) has identified 25 exemplary use cases and associated requirements (see 3GPP TR 22.886 Study on enhancement of 3GPP Support for 5G V2X Services, Release 15, V15.2.0). A set of normative requirements is also specified in use cases, which are categorized into four use case groups: vehicle platooning, enhanced sensors, advanced driving, and remote driving (see 3GPP TS 22.186 Enhancement of 3GPP support for V2X scenarios (Stage 1), Release 15, V15.3.0). A detailed description of the performance requirements for each use case group is specified in TS 22.186. Summary of the Invention

[0003] A method and system for resource management in sidelink for Vehicle-to-Everything (V2X) scenarios are disclosed. An exemplary method and system for resource structure in sidelink is disclosed. Control and data channels may be frequency division multiplexed (Famed) or time division multiplexed (Timed) with Orthogonal Frequency Division Multiplexing (OFDM) waveforms. An exemplary method and system for resource configuration in sidelink is disclosed. Resource configuration may be statically configured, locally semi-persistent, or dynamically configured. An exemplary method and system for supplemental resource allocation is disclosed. Auxiliary sensing may be performed by a special device or a user terminal (UE) such as a group lead or Roadside Unit (RSU) or a scheduling User Equipment (UE), and local scheduling may be performed by a special device or a user terminal (UE) such as a group lead or RSU or a scheduling UE. An exemplary method and system for scheduler allocation schemes for both with and without network control are disclosed. Exemplary methods and systems are disclosed for resource allocation mode switching schemes for both network controlled and non-network controlled.Exemplary methods and systems are disclosed for slot or subframe structures with resource allocation of control and data channels for different communications.Exemplary methods and systems are disclosed for sensing schemes for both periodic and aperiodic data transmissions.Exemplary methods and systems are disclosed for sensing based on resource selection and congestion control transmission schemes.

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages noted in any part of the disclosure.

[0005] BRIEF DESCRIPTION OF THE DRAWINGS The following detailed description will be better understood when read in conjunction with the accompanying drawings, in which:

[0023] For purposes of illustration, there are shown examples in the drawings, but the subject matter is not limited to the specific elements and instrumentalities disclosed. [Brief description of the drawings]

[0006] [Figure 1A] FIG. 1A illustrates an exemplary communication system. [Figure 1B] FIG. 1B is a system diagram of an example Radio Access Network (RAN) and core network. [Figure 1C] FIG. 1C is a system diagram of an example RAN and core network. [Figure 1D] FIG. 1D is a system diagram of an example RAN and core network. [Figure 1E] FIG. 1E illustrates another exemplary communication system. [Figure 1F] FIG. 1F is a block diagram of an example apparatus or device, such as a Wireless Transmit / Receive Unit (WTRU). [Figure 1G] FIG. 1G is a block diagram of an exemplary computing system. [Diagram 2] FIG. 2 shows an example block diagram of advanced V2X services. [Diagram 3] FIG. 3 shows an example one-symbol resource structure in the sidelink. [Figure 4]FIG. 4 shows example 2-symbol and 4-symbol resource structures in the sidelink. [Diagram 5] FIG. 5 shows an example 2-symbol minislot resource structure in the sidelink. [Figure 6A] FIG. 6A illustrates an example call flow for resource reconfiguration when joining a platoon. [Figure 6B] FIG. 6B illustrates an example call flow for resource reconfiguration when joining a platoon. [Figure 7A] FIG. 7A illustrates an example call flow for resource reconfiguration when exiting the formation. [Figure 7B] FIG. 7B illustrates an example call flow for resource reconfiguration when exiting the formation. [Figure 8A] FIG. 8A illustrates an example call flow of resource reconfiguration when switching RSUs. [Figure 8B] FIG. 8B illustrates an example call flow of resource reconfiguration when switching RSUs. [Figure 9A] FIG. 9A illustrates an example call flow for supplemental resource sensing. [Figure 9B] FIG. 9B illustrates an example call flow for supplemental resource sensing. [Figure 10A] FIG. 10A illustrates an example call flow for scheduling locally by lead. [Figure 10B] FIG. 10B illustrates an example call flow for scheduling locally by a lead. [Figure 11] FIG. 11 illustrates the allocated or scheduled broadcast, multicast, and unicast resources in the sidelink operating band or in the sidelink resource pool. [Figure 12]FIG. 12 shows an example of aggregated slot scheduling in the sidelink, where a broadcast transmission in the Physical Sidelink Shared Channel (PSSCH) spans the slot boundary between slots SL1 and SL2. [Figure 13] FIG. 13 shows an example of Sidelink Channel State Information (SL-CSI) acquisition. [Figure 14] FIG. 14 illustrates minislot-based scheduling. [Figure 15A] FIG. 15A illustrates a receiving UE initiated unicast. [Figure 15B] FIG. 15B shows a transmitting UE initiated unicast. [Figure 16] FIG. 16 illustrates an example method of sensing for periodic and aperiodic data transmissions over a shared resource pool. [Figure 17] FIG. 17 shows an example of UE-initiated scheduler selection with network control. [Figure 18] FIG. 18 shows an example of network-initiated scheduler selection with network control. [Figure 19A] FIG. 19A shows an example of scheduler selection without network control. [Figure 19B] FIG. 19B shows an example of scheduler selection without network control. [Figure 20A] FIG. 20A shows an example call flow for scheduler selection without network control. [Figure 20B] FIG. 20B illustrates an example call flow for scheduler selection without network control. [Figure 21] FIG. 21 illustrates an example call flow for scheduler modification with network control. [Figure 22] FIG. 22 shows an example of scheduler modification without network control. [Figure 23]FIG. 23 shows an example call flow for scheduler modification without network control. [Figure 24A] FIG. 24A illustrates an example call flow for resource allocation mode switching with network control. [Figure 24B] FIG. 24B illustrates an example call flow for resource allocation mode switching with network control. [Figure 25A] FIG. 25A illustrates an example call flow for resource allocation mode switching without network control. [Figure 25B] FIG. 25B illustrates an example call flow for resource allocation mode switching without network control. [Figure 26A] FIG. 26A illustrates an example of sensing-based resource selection. [Figure 26B] FIG. 26B illustrates an example of sensing-based resource selection. [Figure 26C] FIG. 26C illustrates an example of sensing-based resource selection. [Figure 27] FIG. 27 illustrates an example of a call flow for sensing-based resource selection. [Figure 28] FIG. 28 shows an example of congestion measurement. [Figure 29] FIG. 29 shows an example of a call flow for congestion control based transmission. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] Exemplary Communication Systems and Networks The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities (including those affecting codecs, security, and quality of service). The latest Radio Access Technology (RAT) standards include Wideband CDMA (WCDMA), commonly referred to as 3G, Long Term Evolution (LTE), commonly referred to as 4G, LTE-Advanced, and New Radio (NR), also referred to as "5G". 3GPP NR standard development is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include new flexible radio access offerings below 7 GHz and new ultra-mobile broadband radio access offerings above 7 GHz. Flexible Radio Access is expected to consist of new non-backward compatible radio access in new spectrum below 7 GHz and is expected to include different operation modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverse requirements. Ultra Mobile Broadband is expected to include ultra mobile broadband access, e.g., cmWave and mmWave spectrum, providing opportunities for indoor applications and hotspots. In particular, ultra mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.

[0008] 3GPP has identified various use cases that NR is expected to support, which result in different user experience requirements for data rate, latency, and mobility. The 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 interworking, energy conservation), and enhanced Vehicle-to-Everything (eV2X) communications, which may include any of Vehicle-To-Vehicle (V2V) communications, Vehicle-To-Infrastructure (V2I) communications, Vehicle-To-Network (V2N) communications, Vehicle-To-Pedestrian (V2P) communications, and vehicular communications with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive e-calls, disaster alerts, real-time gaming, multi-party video calling, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and others are contemplated herein.

[0009] 1A illustrates an example communication system 100 in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmission / reception units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be generally or collectively referred to as a WTRU 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, a V2X server, a V2X function, a ProSe server, a ProSe function, an IoT service, video streaming, and / or edge computing, etc.

[0010] It will be appreciated that the concepts disclosed herein may be used in any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. In the example of FIG. 1A, each of the WTRUs 102 is illustrated in FIGS. 1A-1E as a handheld wireless communication device. With various use cases considered for wireless communication, it will be appreciated that each WTRU may comprise or be included in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics 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 truck, a train, or an airplane, etc.

[0011] The communication system 100 may also include a base station 114a and a base station 114b. In the example of FIG. 1A, each base station 114a and 114b is shown 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 and facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or other networks 112. Similarly, the base station 114b may be any type of device configured to interface wired and / or wirelessly with at least one of the remote radio heads (RRHs) 118a, 118b, the transmission and reception points (TRPs) 119a, 119b, and / or the road side units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. The RRHs 118a, 118b may be any type of device configured to interface wirelessly with at least one of the WTRUs 102, e.g., the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

[0012] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d and facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the 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 and facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. As an example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), Node B, eNode B, Home Node B, Home eNode B, Next Generation Node B (gNode B), satellite, site controller, Access Point (AP), wireless router, etc.

[0013] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, relay nodes, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a particular geographical area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographical area, which may be referred to as a cell (not shown). The cells may be further 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, e.g., one for each sector of the cell. The base station 114a may also employ Multiple-Input Multiple Output (MIMO) technology and thus utilize multiple transceivers, e.g., for each sector of the cell.

[0014] 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).

[0015] 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 wired or air interfaces 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optics, etc.) or wireless communication links (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). The air interfaces 115b / 116b / 117b may be established using any suitable RAT.

[0016] The RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over 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.

[0017] The WTRUs 102 may communicate with each other over a direct air interface 115d / 116d / 117d, such as sidelink communications, 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.

[0018] The communications 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, and so on. For example, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 103 / 104 / 105, 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), Universal Terrestrial Radio Access (UTRA), etc., whereby the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively, may be established 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).

[0019] The base station 114a and 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 in the RAN 103b / 104b / 105b, and WTRUs 102c, 102d may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), thereby establishing the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications).

[0020] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RAN 103 / 104 / 105, or the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b in the RAN 103b / 104b / 105b, and the WTRUs 102c, 102d, 102e, and 102f may be compliant with any of the following standards: IEEE 802.16 (e.g., Worldwide Interoperability For Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000, etc. The wireless technology may implement wireless technologies such as IS-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), and GSM EDGE (GERAN).

[0021] The base station 114c in FIG. 1A may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity within a local area, such as a location, such as an office, a home, a vehicle, a train, an aircraft, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102, e.g., the WTRU 102e, may implement a radio technology, such as IEEE 802.11, to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRU 102, e.g., the WRTU 102e, may implement a radio technology, such as IEEE 802.15, to establish a Wireless Personal Area Network (WPAN). The base station 114c and the WTRU 102, e.g., the WRTU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. 1A, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not need to access the Internet 110 through the core network 106 / 107 / 109.

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

[0023] 1A, it will be understood that the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may utilize E-UTRA radio technology, the core network 106 / 107 / 109 may also communicate with another RAN (not shown) employing GSM or NR radio technology.

[0024] The core network 106 / 107 / 109 may also act 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 Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communications protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / Internet Protocol (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 network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b or a different RAT.

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

[0026] Although not shown in FIG. 1A, it will be understood that the user terminal may have a wired connection to a gateway. The gateway may be a Residential Gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It will be understood that many of the ideas contained herein may be equally applicable to UEs that are WTRUs and UEs that use a wired connection to connect to a network. For example, ideas applied to the air interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to a wired connection.

[0027] FIG. 1B is a system diagram of an example RAN 103 and core network 106. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. As shown in FIG. 1B, 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).

[0028] 1B, Node Bs 140a, 140b may communicate with RNC 142a. Additionally, Node B 140c may communicate with RNC 142b. Node Bs 140a, 140b, and 140c may communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b may communicate with each other via an Iur interface. Each of RNCs 142a and 142b may be configured to control its respective connected Node Bs 140a, 140b, and 140c. Additionally, each of RNCs 142a and 142b may be configured to perform or support other functionalities such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

[0029] 1B 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 above elements is shown as part of the core network 106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

[0032] 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.

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

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

[0035] Each of the eNodeBs 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 on the uplink and / or downlink, etc. As shown in FIG 1C, the eNodeBs 160a, 160b, and 160c may communicate with each other via an X2 interface.

[0036] 1C may include a Mobility Management Gateway (MME) 162, a Serving Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the above elements is shown as part of the core network 107, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0037] The MME 162 may be connected to each of the eNodeBs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may function 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, selection of a particular serving gateway during initial attachment 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.

[0038] The serving gateway 164 may be connected to each of the eNodeBs 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-eNodeB handover, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing the context of the WTRUs 102a, 102b, and 102c, etc.

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

[0040] 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, and facilitate communications between the WTRUs 102a, 102b, and 102c and traditional terrestrial communications devices. For example, the core network 107 may include or 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 networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

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

[0042] The RAN 105 may include g Node Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of g Node Bs. The g Node 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 g Node Bs, which may be the core network 109 via one or more gNBs. The g Node Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the g Node B 180a may transmit wireless signals to and receive wireless signals from the WTRU 102a, for example, using multiple antennas. It will be appreciated that the RAN 105 may employ other types of base stations, such as eNode Bs. It will also be appreciated that the RAN 105 may employ multiple types of base stations. For example, the RAN may employ eNodeBs and gNodeBs.

[0043] The N3IWF 199 may include a non-3GPP access point 180c. It will 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 an 802.11 protocol.

[0044] Each of the g NodeBs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users on the uplink and / or downlink, etc. As shown in FIG 1D, the g NodeBs 180a and 180b may communicate with each other over, for example, an Xn interface.

[0045] The core network 109 shown in FIG. 1D may be a 5G Core (5G Core: 5GC) network. The core network 109 may provide numerous communication services to customers interconnected by a radio access network. The core network 109 comprises several entities that perform the functionality of a core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functionality of a core network. It should be understood that such a core network entity may be a logical entity implemented in the form of computer-executable instructions (software) stored in a memory of an apparatus configured for wireless and / or network communication or a computer system, such as the system 90 shown in FIG. 1G, and executed on a processor of the apparatus.

[0046] In the example of Figure 1D, the 5G core network 109 may include an Access and Mobility Management Function (AMF) 172, a Session Management Function (SMF) 174, a User Plane Function (UPF) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, and a User Data Repository (UDR) 178. Although each of the above elements is shown as part of the 5G core network 109, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator. It will also be appreciated that the 5G core network may not be comprised of all of these elements, may be comprised of additional elements, and may be comprised of multiple instances of each of these elements. Although Figure 1D shows the network functions connecting directly to each other, it will be appreciated that they may communicate via a routing agent, such as a Diameter routing agent, or a message bus.

[0047] In the example of Figure 1D, connectivity between network functions is achieved through a set of interfaces or reference points. It will be appreciated that network functions may be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. Invocation of network function services may be achieved through direct connections between network functions, messaging exchanges on a message bus, invocation of software functions, etc.

[0048] The AMF 172 may be connected to the RAN 105 via an N2 interface and may function as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward Non-Access-Stratum (NAS) packets to / from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in FIG. 1D.

[0049] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may function 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 at the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

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

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

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

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

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

[0055] The AUSF 190 performs authentication related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.

[0056] The NEF 196 exposes capabilities and services in the 5G core network 109 to an application function (AF) 188. The exposure may occur over an N33 API interface. The NEF may connect to the AF 188 via the N33 interface, which may connect to other network functions to expose the capabilities and services of the 5G core network 109.

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

[0058] Network slicing is a mechanism that can be used by mobile network operators to support one or more "virtual" core networks behind the operator's air interface. It involves "slicing" the core network into one or more virtual networks to support different service types launching across different RANs, or across a single RAN. Network slicing allows operators to create networks that are customized to provide optimized solutions for different market scenarios that demand diverse requirements, for example in the areas of functionality, performance, and isolation.

[0059] 3GPP is designing the 5G core network to support network slicing. Network slicing is a great tool that network operators can use to support a diverse set of 5G use cases (e.g., large-scale IoT, critical communications, V2X, and enhanced mobile broadband) that are very diverse and sometimes demanding. Without the use of network slicing technology, the network architecture may not be flexible and scalable enough to efficiently support the wider range of use cases required when each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, the introduction of new network services should be more efficient.

[0060] Referring again to FIG. 1D , in a network slicing scenario, the WTRUs 102a, 102b, or 102c may connect to the AMF 172 via an N1 interface. The AMF may logically be part of one or more slices. The AMF may coordinate the connectivity or communication of the WTRUs 102a, 102b, or 102c with one or more UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

[0061] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include or 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 communicate with a Short Message Service (SMS) service center that facilitates communications via 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.

[0062] Although the core network entities described herein and shown in Figures 1A, 1C, 1D, and 1E are identified by names given to those entities in certain existing 3GPP specifications, it should be understood that in the future, those entities and functionality may be identified by other names and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, it should be understood that the specific network entities and functionality described and shown in Figures 1A, 1B, 1C, 1D, and 1E are provided by way of example only, and 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.

[0063] 1E illustrates an example communication system 111 in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmission / receiving units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and road side 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 some or all of WTRUs A, B, C, D, E, and F may be outside the range of access network coverage 131. WTRUs A, B, and C form a V2X group in which WTRU A is the group lead and WTRUs B and C are group members.

[0064] WTRUs A, B, C, D, E, and F may communicate with each other over Uu interface 129 via gNB 121 when they are within access network coverage 131. In the example of FIG. 1E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate with each other directly over a sidelink interface (e.g., PC5 or NR PC5), such as interfaces 125a, 125b, or 128, whether they are under access network coverage 131 or outside of access network coverage 131. For example, in the example of FIG. 1E, WRTU D, which is outside access network coverage 131, communicates with WTRU F, which is inside coverage 131.

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

[0066] FIGURE 1F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communication and operation in accordance with the systems, methods, and apparatus described herein, such as the WTRU 102 of FIGURE 1A, FIGURE 1B, FIGURE 1C, FIGURE 1D, or FIGURE 1E. As shown in FIGURE 1F, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, a non-removable memory 130, a removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the above-mentioned elements. Additionally, the base stations 114a and 114b, such as, but not limited to, a Base Transceiver Station (BTS), Node B, site controller, access point (AP), Home Node B, evolved Home Node B (eNodeB), Home Evolved Node B (HeNB), Home Evolved Node B Gateway, Next Generation Node B (gNodeB), and proxy node, among others, and / or the nodes that the base stations 114a and 114b may represent, may include some or all of the elements shown in FIG. 1F and described herein.

[0067] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of Integrated Circuit (IC), a state machine, 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 connected to the transceiver 120, which may be connected to the transmit / receive element 122. Although FIG. 1F depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0068] The transmit / receive element 122 of the UE may be configured to transmit or receive signals to or from a base station (e.g., base station 114a of FIG. 1A) over the air interface 115 / 116 / 117, or to another UE over 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. The transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. The transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0069] 1F as a single element, 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.

[0070] 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 mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, e.g., NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0071] The processor 118 of the WTRU 102 may be connected to and receive user input data from a speaker / microphone 124, a keypad 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 keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or 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, etc. The processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server hosted on a cloud or edge computing platform, or in a home computer (not shown).

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

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

[0074] The processor 118 may further be connected 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 an accelerometer, a biometric (e.g., fingerprint) sensor, an e-compass, a satellite transceiver, a digital camera (for photos or videos), a Universal Serial Bus (USB) port or other interconnection interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a Frequency Modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0075] The WTRU 102 may be included in other apparatus or devices, such as sensors, consumer electronics products, 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, etc. The WTRU 102 may connect to other components, modules, or systems of such apparatus or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.

[0076] FIG. 1G is a block diagram of an exemplary computing system 90 in which one or more devices of the communications networks shown in FIGS. 1A, 1C, 1D, and 1E may be embodied, such as particular 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 comprise a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software (wherever or however such software is stored or accessed). Such computer-readable instructions may be executed within a processor 91 to run the computing system 90. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate within a communications network. The coprocessor 81 is an optional processor distinct from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

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

[0078] The memories connected to the system bus 80 include a random access memory (RAM) 82 and a read only memory (ROM) 93. Such memories include circuits that allow information to be stored and read. The ROM 93 generally includes stored data that cannot be easily modified. Data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and / or the ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates virtual addresses to physical addresses as instructions are executed. The memory controller 92 can also provide a memory protection function that isolates processes in the system and isolates system processes from user processes. Thus, a program executing in the first mode may only access memory that is mapped by its own process virtual address space and cannot access memory in another process' virtual address space unless memory sharing between processes is set up.

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

[0080] The display 86, controlled by the display controller 96, is used to display 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 panel. The display controller 96 contains the electronic components required to generate the video signals that are sent to the display 86.

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

[0082] 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 instructions, when executed by a processor, such as processor 118 or 91, cause the processor to perform and / or implement the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions and executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile media, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, although 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 memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other tangible or physical medium that may be used to store the desired information and that can be accessed by a computing system.

[0083] (Brief introduction) In Release 14 of LTE V2X, basic requirements for V2X services are supported for road safety services, improving system level performance under high density while meeting the latency requirements of vehicle-to-vehicle (V2V) (e.g. supporting low latency and reliable message exchange between vehicles and infrastructure to improve safety and efficiency). Two configurations of resource pools are specified for scheduling assignments in the Physical Sidelink Control Channel (PSCCH) and associated data transmissions in the Physical Sidelink Shared Channel (PSSCH) (see 3GPP TS 36.213 Physical layer procedures, Release 15, V15.2.0).

[0084] To meet the latency requirements and accommodate high Doppler spread and high density of vehicles for V2X communications, sidelink transmission modes 3 and 4 are specified in TS 36.213.

[0085] Mode 4 uses the new PC5 interface, which provides a direct LTE Sidelink (SL) between the UEs of the two vehicles. Mode 4 employs distributed UE scheduling based on sensing with semi-persistent transmissions. V2V traffic from devices is mostly periodic and small data in nature, which is utilized to sense congestion on resources and estimate future congestion on those resources. Based on the estimation, resources are reserved.

[0086] On the other hand, Mode 3 uses a centralized eNB scheduler: the vehicular UE and eNB use the Uu interface to schedule communications in the sidelink, e.g., the PC5 interface.

[0087] As shown in Figure 2, advanced V2X applications are generating a shift towards more proactive and advanced transport infrastructure, and the expected requirements are becoming more stringent to meet the required data rates, latency, reliability, system capacity, service coverage, etc. Current LTE V2X solutions are unable to deliver the required latency and reliability, as well as the required data rates. Therefore, how to optimize the resource structure and how to allocate resources to support advanced V2X services are essential problems to be addressed and solved.

[0088] A method and system are disclosed for resource management in a sidelink for vehicle-to-everything (V2X) scenarios.

[0089] A method and system for resource structure in sidelink is disclosed. Control and data channels are Frequency Division Multiplexed (FDMed) or Time Division Multiplexed (TDMed) with an Orthogonal Frequency Division Multiplexing (OFDM) waveform. Symbol or minislot based resource pools in time are also disclosed.

[0090] A method and system for resource configuration in sidelink is disclosed. Resource configuration can be statically configured in a V2X system via System Information (SI) or Radio Resource Control (RRC) messages via Uu interface, or via Sidelink SI (SL-SI) or Sidelink RRC (SL-RRC) via PC5 interface, e.g., per level of automation vehicle UE, per role of vehicle UE in a group, per service or application and associated priority, and per data traffic characteristic. Resource configuration can be locally configured via SL-SI or SL-RRC messages via PC5 interface, e.g., by special UE such as group lead, roadside unit (RSU), or scheduling UE.

[0091] A method and system for supplemental resource allocation is disclosed. The supplemental sensing may be performed by a group lead or an RSU or a UE. The localized scheduling may be performed by a group lead or an RSU or a UE.

[0092] Methods and systems for scheduler selection or election and modification for both under network control and outside of network control are disclosed.

[0093] A method and system for resource allocation mode switching schemes for both under network control and outside network control are disclosed.

[0094] A method and system for slot or subframe structure with control and data channel resource allocation for different communications is disclosed. Both slot-based and mini-slot-based are proposed.

[0095] A method and system for sensing schemes for both periodic and aperiodic data transmissions are disclosed. Sensing is performed with an adjustable sensing window, and candidate resources are selected based on the sensing results. Channel sensing, such as Listen-Before-Talk (LBT), is performed before transmitting on the selected resource to avoid possible collisions. For high-priority short-latency data transmissions, preemption is proposed to prioritize reserved resources.

[0096] A method and system are disclosed for a sensing-based resource selection scheme, where resource selection is based on priority, latency, range, and / or congestion.

[0097] A method and system for a congestion control based transmission scheme is disclosed, in which transmission dropping is based on priority, latency, range, and / or congestion.

[0098] It should be noted that the terms "UE" and "vehicle UE" are interchangeable in this disclosure.

[0099] An example method may include receiving congestion associated with at least one of a resource and a resource pool, where the resource and the resource pool are located in a sidelink bandwidth part; determining resource usage and one or more available resources in the resource pool; receiving an indication from a higher layer that a data packet is ready for transmission; selecting and reserving one or more resources in the resource pool for the one or more transmissions; and sending one or more transmissions of the data packet based on the selected one or more resources.

[0100] Determining resource usage and one or more available resources in the resource pool may include setting a time interval for a sensing window, where the time interval for the sensing window is set based on at least one of periodic or aperiodic transmissions, latency requirements for the data packets, repetitions for transmission of the data packets, and retransmission of the data packets per Hybrid Automatic Repeat Request (HARQ) feedback.

[0101] Determining resource usage and one or more available resources in the resource pool may include at least one of sensing resource usage by decoding Sidelink Control Information (SCI) for scheduled or reserved or preempted resources, measuring at least one of a Sidelink Reference Signal Received Power (SL-RSRP), a Sidelink Received Signal Strength Indicator (SL-RSSI), a channel busy rate, or a channel occupancy rate, and determining available resources based on a determination that at least one of the resources that are not scheduled or reserved or preempted, the resources that are within a communication coverage zone, or the SL-RSRP measurement of the resources or the SL-RSSI measurement of the resources is below a threshold.

[0102] Selecting and reserving one or more resources in the resource pool may include determining a time interval for resource selection, where the time interval for resource selection is determined based on at least one of one or more of priority, latency, or reliability of the data packet to be transmitted and one or more of repetitions or retransmissions per HARQ feedback.

[0103] Selecting and reserving one or more resources in the resource pool may include selecting one or more candidate resources by comparing the measured SL-RSRP or RS-RSSI to a threshold, the threshold being based on at least one of the priority of the data packet to be transmitted, latency, communication range, QoS requirements, or interference or congestion measurements of the available resources.

[0104] Selecting and reserving one or more resources in the resource pool may include selecting one or more resources based on at least one of a priority, latency, reliability, or communication range of the data packet to be transmitted, or an interference or congestion measurement, and selecting one or more resources for at least one of a scheduling or reserving SCI, an initial transmission, a repetition, a HARQ feedback, a retransmission per HARQ feedback, or a next data packet of periodic traffic.

[0105] Transmitting one or more transmissions of the data packet may include determining whether a congestion threshold is exceeded based on at least one of the congestion level or the priority, latency, reliability, or range of the transmitted data packet, transmitting one or more transmissions of the data packet based on a determination that the congestion threshold is not exceeded, dropping a transmission based at least on at least one of the congestion level or the priority, latency, reliability, or range of the transmitted data packet, or adjusting a modulation and coding scheme or a transmission power level based on at least one of the congestion level or the priority, latency, reliability, or range of the transmitted data packet, and transmitting at least one of an initial transmission, a repeat, or a retransmission of the data packet based on a determination that the congestion threshold is exceeded.

[0106] (Resource Structure) To support advanced V2X services and use cases, data communication in the sidelink is no longer limited to small periodic transmissions. A more scalable and flexible resource structure may be required to support both small and large data, which can be periodic or aperiodic (e.g., event-triggered). The adoption of multi-carrier OFDM waveforms for 5G uplink transmissions allows for a more flexible resource structure with OFDM-based multiplexing in the sidelink. For example, the New Radio Physical Sidelink Control Channel (NR-PSCCH) for scheduling assignments will be replaced by the New Radio Physical Sidelink Control Channel (NR-PSCCH) for data transmissions. share channel( New Radio Physical Sidelink Shared Channel: In NR-PSSCH), it can be time division multiplexed (TDMed) or frequency division multiplexed (FDMed).

[0107] For highly autonomous vehicles, it is very important to support much higher reliability, lower latency, and higher vehicle density. This calls for an optimized resource structure to reduce latency, improve reliability, and minimize congestion. With increasing operating bandwidth in high frequency spectrum, time resources can be allocated at finer granularity (e.g., symbols or minislots) with different numerologies (e.g., 15KHz, 30KHz, 60KHz, 120KHz, and 240KHz subcarrier spacing). This can help improve latency and congestion, as well as reliability (e.g., available time resources for repetition).

[0108] With multi-carrier OFDM, sidelink resources can be structured differently to meet requirements for latency, reliability, data rate, coverage, etc.

[0109] As shown in Figure 3, resources in the sidelink can be structured as short as one symbol in the time domain (e.g., a symbol pool) and as many resource blocks (RBs) or resource block groups (RBGs) (e.g., a group of adjacent RBs) or subchannels (e.g., a group of adjacent RBs or RBGs) available in frequency (e.g., a resource block (RB) or resource block group (RBG) pool or subchannel pool). This allows for very low latency transmission of messages with short control signaling in the NR-PSCCH, e.g., the sidelink control information (SCI) shown in the figure, and data in the New Radio Physical Sidelink Shared Channel (NR-PSSCH), which are FDMed over the same symbol either periodically or aperiodically (e.g., event-triggered transmissions).

[0110] Because each vehicular UE may have very little time to transmit, more time resources are available to other vehicular UEs in each slot, subframe, or frame, improving coverage in high-density areas such as road intersections, multi-lane highways, or multi-level bridges.

[0111] Because each vehicle UE may have very little time to transmit, more time resources are available to transmit repetitions in each slot, subframe, or frame to the receiver, improving reliability with very short latency.

[0112] Since each vehicular UE may have very little time to transmit, more time resources are available for the vehicular UE to sweep its beam to different receivers for area coverage in each slot, subframe, or frame, enabling beam-based operation in very high frequency spectrum up to 52.6 GHz.

[0113] For example, UE-v1 transmits short control signaling, e.g., SCI, on the NR-PSCCH in symbol 1 “Sym1” of subframes “SF 0” and “SF l1”, respectively, in period “Period-v1”, from RB k1 to RB k2 or from RBG k1 to RBG k2, or from subchannel k1 to subchannel k2, if more RBs are used in its bandwidth part (BWP) “BWP-v1”.

[0114] In another example, UE-v2 transmits a short message, e.g., SCI, with control in NR-PSCCH, and data in NR-PSSCH FDMed in the same symbol, e.g., symbol 4 “Sym4”, and repeats the same transmission in symbols 5 and 6 of subframes “SF 0” and “SF 12”, respectively, in period “Period-v2”. The transmissions can be sent to the same receiver (e.g., repetition for reliability) or can be sent to different receivers each time (e.g., beam sweeping for area coverage). Since UE-v2 transmits FDMed control in NR-PSCCH and data in NR-PSSCH over one symbol, as shown in FIG. 3, its BWP “BWP-v2” is much larger than the BWP of UE-v1, e.g., in the range of BR 0 to RB N or RBG 0 to RBG N or subchannels 0 to N, if more RBs are used in its BWP “BWP-v2” as shown in FIG. 3.

[0115] When NR-PSCCH and NR-PSSCH are FDMed over the same symbol, the PSCCH carrying the SCI may be assigned to a different position in frequency, e.g., it may be located at the lowest or highest index of an RB, RBG, or subchannel, or in the middle of a frequency band, e.g., a bandwidth part (BWP), as shown in FIG. 3.

[0116] As further shown in Figure 3, the NR-PSCCH carrying the SCI is allocated in adjacent RBs, RBGs, or subchannels, but the NR-PSCCH may also be distributed within the entire sidelink BWP of a vehicular UE, e.g., for frequency diversity gain, in non-adjacent RBs, RBGs, or subchannels.

[0117] As shown in Figure 4, resources in the sidelink may be structured with multiple symbols in time (e.g., a symbol pool) and many available RBs, RBGs, or subchannels in frequency (e.g., an RB pool, an RBG pool, or a subchannel pool). This allows very low latency transmission for medium or large size messages, either periodic or aperiodic.

[0118] In one example, UE-v1 transmits a short message, e.g., SCI, with control in NR-PSCCH at symbol 1 “Sym1” and data in NR-PSSCH at symbol 2 “Sym2” in subframes “SF 0” and “SF 11” respectively in period “Period-v1” from RB k1 to RB k2 or from RBG k1 to RBG k2 or from subchannel k1 to subchannel k2 if more RBs are used in its BWP “BWP-v1”. In this case, the control in NR-PSCCH and the data in NR-PSSCH are TDMed over the same RB or RBG or subchannel.

[0119] In another example, UE-v2 transmits a large message with control in NR-PSCCH, e.g., SCI, and data in NR-PSSCH FDMed in symbol 5, “Sym5”, and remaining data in NR-PSSCH in symbols 6 and 7, in subframes “SF 0” and “SF 12”, respectively, in period “Period-v2”. Because UE-v2 transmits the large message over only four symbols, its BWP “BWP-v2” is much larger than the BWP of UE-v1, in the range of BR 0 to RB N or RBG 0 to RBG N or subchannel 0 to subchannel N, if more RBs are used in its BWP “BWP-v2” as shown in the figure.

[0120] When the NR-PSCCH and NR-PSSCH are TDMed as shown in Figure 4, the PSCCH carrying the SCI may be allocated over the same or different locations in frequency. For example, as shown in Figure 3, they may be located in the same frequency range, e.g., BWP-v1, or in different frequency ranges, e.g., BWP-v2, or even over different frequency locations without any overlap (not shown in Figure 4).

[0121] As further shown in Figure 4, the NR-PSCCH is allocated in adjacent RBs, RBGs, or subchannels. However, the NR-PSCCH may also be distributed in the entire BWP of the vehicle UE in the first symbol (e.g., allocated in non-adjacent RBs, RBGs, or subchannels), or distributed in the BWP of the vehicle UE over the first two symbols, as an example, using frequency first (e.g., filling frequency resources in the first symbol and then the second symbol) or using time mapping first (e.g., filling time resources in the first RB, RBG, or subchannel and then the second RB, RBG, or subchannel).

[0122] Resources in the sidelink may additionally or alternatively be structured in time in minislots (e.g., time length in adjacent symbols). For a 14-symbol slot or subframe (e.g., 15 KHz subcarrier numerology, where each subframe contains one slot, and thus slot and subframe are interchangeable in the example), a minislot may contain, as an example, 1, 2, 4, or 7 symbols adjacently. As shown in Figure 5, a 2-symbol minislot is used for the sidelink resource structure in time (e.g., minislot pool) and the number of RBs or RBGs or subchannels available in the frequency band (e.g., RB pool or RBG pool or subchannel pool). This allows for a larger granularity than symbol-based allocation, but a finer granularity in time than subframe-based allocation, which may save signaling bits for large data transmissions within a short time. Minislot-based time allocation may be applied to both periodic and aperiodic (e.g., event-triggered) transmissions.

[0123] In one example, UE-v1 transmits a short message, e.g., SCI, with control in NR-PSCCH and data in NR-PSSCH in minislot 1 of subframes “SF 0” and “SF l1” in its BWP “BWP-v1” from RB k1 to RB k2 or from RBG k1 to RBG k2, or from subchannel k1 to subchannel k2 if more RBs are used in its BWP “BWP-v1”. In this case, the control in NR-PSCCH and the data in NR-PSSCH are TDMed over the same RB or RBG or subchannel in a 2-symbol minislot.

[0124] In another example, UE-v2 transmits a large message, e.g., SCI, with control in NR-PSCCH and data in NR-PSSCH that is TDMed in minislots 3 and 4 of subframes “SF 0” and “SF 12”, respectively, in period “Period-v2”.

[0125] In another example, UE-v3 transmits an intermediate message with control in NR-PSCCH and data in NR-PSSCH TDMed in minislot 0, and repeats the same transmission in minislot 1 of subframe "SF l1." The transmissions may be sent to the same receiver (e.g., repeating in the minislot) or may be sent to different receivers each time (e.g., beamsweeping in the minislot).

[0126] As further shown in Figure 5, the NR-PSCCH carrying the SCI is allocated in adjacent RBs, RBGs, or subchannels. However, the NR-PSCCH may also be distributed within the entire sidelink BWP of the vehicular UE in the first symbol of the first minislot (e.g., may be allocated in non-adjacent RBs, RBGs, or subchannels) or distributed within the sidelink BWP of the vehicular UE over the first two symbols of the first minislot, such as by using frequency first (e.g., filling frequency resources in the first symbol and then the second symbol) or by using time mapping first (e.g., filling time resources in the first RB, RBG, or subchannel and then the second RB, RBG, or subchannel).

[0127] For a resource in frequency (RB or RBG pool or subchannel pool), the vehicle UE may select adjacent RBs, RBGs, or subchannels, or non-adjacent RBs, RBGs, or subchannels. For adjacent RBs, RBGs, or subchannels, the resource may be a starting point and a length from the starting point in units of RBs, RBGs, or subchannels, e.g., {RB start ,RB length} or {RBG start ,RBG length} or {Subchannel start ,Subchannel lengthFor non-adjacent RBs, RBGs, or subchannels, the resources can be represented as {RB start1 R.B. length1 ,RB start2 R.B. length2 ,...,RB startN R.B. lengthN}, {RBG start1 RBG length1 ,RBG start2 RBG length2 ,...,RBG startN RBG lengthN} or {Subchannel start1 Subchannel length1 ,Subchannel start2 Subchannel length2 ,...,Subchannel startN ,Subchannel lengthN} (each N>1), or a combination of RBs, RBGs, and subchannels. For uniformly distributed non-adjacent RBs or RBGs or subchannels, the resources can be denoted as {RB start R.B. length ,RB gap} or {RBG start RBG length ,RBG gap} or {Subchannel start Subchannel length ,Subchannel gap}, or a combination of RB, RBG, and subchannel.

[0128] If a bitmap is used for the RB or RBG pool or subchannel pool, the bit string may be mapped to an RB, RBG, or subchannel in the operating band for the sidelink, e.g., the sidelink BWP. RB ,b RB-1 ,...,b1,b0} is the number of bits for the first RB (e.g., RB0). RB For the last RB (e.g., RB N), the RB is mapped to b0.RBG ,b RBG-1 ,...,b1,b0} is the b RBG and for the last RBG (e.g., RBG N) it is mapped to b0, or {b Subch ,b Subch-1 ,...,b1,b0} is the b for the first subchannel (e.g., subchannel 0). Subch for the last subchannel (eg, subchannel N), it is mapped with b0.

[0129] For resources in time (e.g., symbol or minislot pools), the starting symbol or minislot may be referenced from a system time reference point such as the System Frame Number (SFN) or Direct Frame Number (DFN). For example, a symbol or minislot may be indexed as "SFN or DFN number + symbol number within frame" or "SFN or DFN number + minislot number within frame". The time length or duration may be in symbols, minislots or slots, or subframes. For non-contiguous time allocations, the resources are allocated in the order {Symbol start1 Symbol length1 Symbol start2 Symbol length2 ,...,Symbol startN Symbol lengthN}, {mini-slot start1 mini-slot length1 ,mini-slot start2 mini-slot length2 ,...,mini-slot startN mini-slot lengthN}, {slot start1 ,slot length1 ,slot start2 slot length2 ,...,slot startN slot lengthN} or {Subframestart1 Subframe length1 ,Subframe start2 Subframe length2 ,...,Subframe startN ,Subframe lengthN} (each N>1), or a combination of symbols, minislots and slots, or subframes. For uniformly distributed non-contiguous symbols or minislots or slots or subframes, the resources are denoted by {Symbol start .Symbol length Symbol gap} or {mini-slot start ,mini-slot length ,mini-slot gap} or {slot start ,slot length ,slot gap} or {subframe start ,subframe length ,Subframe gap}, or a combination of symbols, minislots and slots, and subframes.

[0130] If a bitmap is used to represent resources with symbols, they can be mapped to symbols in time intervals. For example, s ,b s-1 ,...,b1,b0} is the first symbol s For the last symbol it is mapped with b0, and for the last symbol it is mapped with b1. A value of "1" indicates an assignment at this symbol.

[0131] If a bitmap is used to indicate resources in minislots, it can be mapped to minislots within a time interval. For example, m ,b m-1 ,...,b1,b0} is the b m For the last minislot, it is mapped to b0, and for the last minislot, it is mapped to b1. A value of "1" indicates an allocation in this minislot.

[0132] To save mapping bits, a two-level mapping can be used. For example, f ,a f-1 ,...,a1,a0} is mapped to an SFN or DFN (e.g., for the first SFN or DFN, f , a0) for the last SFN or DFN in the time interval, {c s ,c s-1 ,...,c1,c0} are mapped to symbols in the frame or {c m ,c m-1 ,...,c1,c0} are mapped to minislots or slots within the frame.

[0133] Sidelink resource or resource pool configuration or allocation in frequency and time may be configured in a Radio Resource Control (RRC) message per BWP per cell carrier or cell over Uu with network control (e.g., gNB or eNB management), or in a Sidelink RRC (SL-RRC) message over the sidelink (PC5) interface without network control (e.g., UE management).

[0134] The sidelink resource or resource pool configuration or allocation may be broadcast periodically using SI or shared or common RRC over the Uu interface or using SL-SI or shared or common SL-RRC messages over the sidelink (PC5) interface. The sidelink resource or resource pool configuration or allocation may also be transmitted to the UE using dedicated RRC messages over the Uu interface or using dedicated SL-RRC messages over the sidelink (PC5) interface, among others, periodically or aperiodically, which may be per UE request.

[0135] For RRC over the Uu interface, the Control Resource Set (CORESET) carried on the Physical Downlink Control Channel (PDCCH) is configured by RRC in a Common Search Space (CSS) or UE Search Space (USS) for common or UE-specific RRC messages, respectively. DCI in the CORESET within the CSS or USS addresses the location of the common broadcasted RRC or UE-specific RRC messages carried on the Physical Downlink Shared Channel (PDSCH), respectively.

[0136] For SL-RRC over the sidelink (PC5) interface, the Sidelink Control Resource Set (SL-CORESET) carried on the New Radio Physical Sidelink Control Channel (NR-PSCCH) is configured in the Sidelink-Common Search Space (SL-CSS) or Sidelink-UE Search Space (SL-USS) by RRC or SL-RRC for common or UE-specific SL-RRC messages, respectively. The Sidelink Control Information (SCI) in the SL-CORESET within the SL-CSS or SL-USS, respectively, addresses the location of the common broadcasted SL-RRC or UE-specific SL-RRC messages carried on the New Radio Physical Sidelink Shared Channel (NR-PSSCH).

[0137] The sidelink resource pool allocation or configuration in frequency and time may also be indicated in the Medium Access Control (MAC) Control Element (CE) over the Uu interface with network control (e.g., gNB or eNB managed resource allocation) or in the Sidelink-Medium Access Control (SL-MAC) over the Sidelink (PC5) interface without network control (e.g., UE managed resource allocation). The set or subset of resources or resource pools configured in the RRC or SL-RRC may be indicated by the MAC CE or SL-MAC CE, for example, using a configuration index. Also, the resource or resource pool configuration may be enabled or disabled by the MAC CE or SL-MAC CE for semi-static allocation.

[0138] The sidelink resource pool allocation or configuration in frequency and time may also be dynamically indicated in the Downlink Control Information (DCI) over the Uu with network control (e.g. gNB or eNB managed resource allocation) or dynamically indicated in the Sidelink Control Information (SCI) over the Sidelink (PC5) interface without network control (e.g. UE managed resource allocation).

[0139] The set or subset of sidelink resources or resource pool configured in the RRC or SL-RRC may be indicated by the DCI over the Uu interface or by the SCI over the sidelink (PC5) interface, e.g., using a configuration index. Also, resource allocation in time and frequency may be indicated directly in the DCI over the Uu interface or in the SCI over the sidelink (PC5) interface in the time allocation and frequency allocation fields, respectively, using the different description methods previously described (e.g., bitmaps).

[0140] Also, a sidelink resource or resource pool configuration or allocation may be enabled or disabled by the DCI via the Uu interface or by the SCI via the sidelink (PC5) interface for semi-persistent assignment or scheduling, which may be enabled solely in a resource configuration carried in the DCI or SCI (e.g., Scheduling Assignments SCI (SA SCI)) or in a sidelink resource allocation mode, e.g. by enabling a sidelink resource allocation mode with the associated sidelink resource or resource pool configuration or allocation, by the DCI via the Uu interface or by the SCI via the sidelink interface.

[0141] (Resource configuration) A method and system for resource configuration in sidelink is disclosed.

[0142] In a first example, the sidelink resources may be statically configured by common or dedicated RRC or SL-RRC messages, e.g., the resource pool may be configured when the vehicular UE is connected to an access network (e.g., a gNB or an RSU such as a gNB) via, for example, an SI or Radio Resource Control (RRC) message, or when the vehicular UE registers with a V2X application server, for example, in a cloud or infrastructure via a Non-Access Stratum (NAS) or Access Stratum (AS) message. The resource pool configuration may be updated semi-statically by an RRC or SL-RRC message or a Medium Access Control (MAC) Control Element (CE) or SL-MAC CE, or dynamically by a Downlink Control Information (DCI) from a gNB or an RSU such as a gNB when the vehicular UE is connected to the access network or V2X service server.Without network control, the sidelink resources may be statically configured by SL-SIs carried or indicated by a New Radio-Sidelink Primary Synchronization Signal (NR-SPSS) / New Radio-Sidelink Secondary Synchronization Signal (NR-SSSS) / New Radio-Physical Sidelink Broadcast Channel (NR-PSBCH) block carrying the master SL-SI or the primary SL-SI of the selected New Radio-Sidelink Primary Synchronization Signal (NR-SPSS) / New Radio-Sidelink Secondary Synchronization Signal (NR-SSSS) / New Radio-Physical Sidelink Broadcast Channel (NR-PSBCH) block or a New Radio Physical Sidelink Shared Channel (NR-PSSCH) carrying the remaining or other SL-SIs or SL-RRC messages associated with the selected NR-SPSS / NR-SSSS / NR-PSBCH block, and / or may be semi-persistently or dynamically indicated by Scheduling Allocation Sidelink Control Information (SCI) carried on a New Radio Physical Sidelink Control Channel (NR-PSCCH) from an RSU as a neighboring coordinator, neighboring lead, group lead, or synchronization source UE.

[0143] For sidelink resources, different vehicle UEs may be configured differently according to their own capabilities or characteristics (such as level of driving automation) and V2X applications. For example, a resource pool for highly autonomous vehicle UEs may be configured for very low latency and high reliability characteristics, as described above. Thus, the automation level of the vehicle UE may be used in configurations such as Level of Automation (LoA) SAE0-2 for driver control and SAE3-5 for vehicle control, based on whether a human operator or an automated system is primarily responsible for monitoring the driving environment. The automation level of the vehicle UE may be indicated by a higher layer parameter, e.g., auto_level, that may be indicated from the vehicle UE during the sidelink resource configuration procedure.

[0144] For sidelink resources, the resource pool may be configured separately for different types of vehicle UEs with different operating modes, e.g., priority levels, such as ambulance driving versus medical emergency mode, and the operating mode, e.g., high_priority_mode, may be indicated from a higher layer or application layer.

[0145] For sidelink resources, resource pools may be configured separately for different vehicular UEs at different speeds, such that vehicular UEs at high speeds may be configured with a low-latency resource pool, and the parameter speed may be indicated from a higher layer or an application layer.

[0146] For sidelink resources, the resource pool may be configured according to the location or range of the vehicular UE, so that vehicular UEs at different locations may be configured with shared resources, e.g., resources reused per location or in close proximity, and the parameter location_zone may be indicated from higher layers or from the application layer.

[0147] For sidelink resources, a vehicle UE may be configured differently based on its role in an application or service, e.g., lead or member role in a platoon. The role of the UE, e.g., ue_role, may be indicated by a higher layer or an application layer.

[0148] Different V2X applications may be configured differently for sidelink resources. For example, the resource pool for a lead vehicle UE may be configured differently from member vehicle UEs for a platooning application, while the resource pool between vehicle UEs for an extended sensor application may be configured the same. In addition, different applications or services may have different performance requirements, and resources may be configured with different priority levels. Thus, the vehicle UE may be configured with different configurations associated with different application IDs or service IDs that may have different priority levels, and the application or service ID to priority level mapping may be handled by higher layers or applications, and the vehicle UE may select a resource configuration according to higher layer parameters, such as app_id or app_index for an application or service_id or service_index for a service.

[0149] For sidelink resources, different data communications may be configured separately. For example, for low traffic areas, the resource pool may be shared by both periodic transmissions (e.g., using semi-persistent resource reservation based sensing) and aperiodic or event-triggered transmissions (e.g., using fast channel sensing for access) as indicated by higher layers or application layers, e.g., parameter periodic_flag with value "1" for periodic and "0" for aperiodic, and the resource pool may be shared by higher layers or application layers, e.g., broadcast, multicast, and unicast as indicated by parameter communication_type. However, for high traffic areas, the probability of collisions between semi-persistent periodic transmissions and event-triggered heavy data transmissions is very high. To reduce collisions, the vehicular UE may be configured with different resource pools for different data traffic (e.g., a resource pool for periodic small or medium data transmissions using sensing-based semi-persistent reservation) as well as a resource pool for event-triggered large data transmissions with very low latency and high reliability using a priority-based channel-sensing access scheme, with a parameter priority indicated from a higher layer or application layer (e.g., first sense the channel, transmit data with or without back-off based on the priority of the vehicular UE, wait for a time interval that may be mapped to the priority of the vehicular UE, and sense the channel again if the channel is occupied). To reduce collisions, e.g., in half-duplex communication, the UE cannot receive and transmit at the same time, and broadcast, multicast, and unicast may also be configured with different resource pools, e.g., allocated at different times.

[0150] All parameters illustrated for resource or resource pool configuration or allocation may be configured by the RRC or SL-RRC, indicated by the MAC CE or SL MAC CE, and dynamically signaled by the DCI or SCI for the associated data.

[0151] In a second example, to utilize the resource pool more efficiently, to meet the more stringent resource requirements for vehicular UEs with very low latency and high reliability, the resource pool may be configured locally by an RSU as a nearby coordinator (e.g., at a busy intersection), by a platoon lead for the platoon, or by a nearby group lead using SL-RRC messages, SL-MAC-CE, or SA SCI over the sidelink (PC5) interface as described above.

[0152] An example of resource pool configuration and reconfiguration for joining a platoon is shown in Figures 6A and 6B, which may include, as an example, the following steps. In step 0, when the vehicular UE is under network control over the Uu interface, it may first configure and then update the resource pool configuration with an RSU such as a gNB or a V2X cloud server or a gNB, or an RSU as a neighboring coordinator, neighboring lead, group lead, or synchronization source UE over the sidelink (PC5) interface.

[0153] In step 1A, the formation lead may periodically broadcast or beam sweep synchronization signals and discovery information over the sidelink interface, including New Radio Primary Sidelink Synchronization Signal (NR-PSSS) and New Radio Secondary Sidelink Synchronization Signal (NR-SSSS) for synchronization, master or primary system information and / or master or primary group information, and New Radio Physical Sidelink Discovery Channel (NR-PSDCH) or New Radio Physical Sidelink Shared Channel (NR-PSSCH) for group discovery or NR-PSSCH for remaining or other SL-SI or SL-RRC messages.

[0154] In step 1B, the vehicular UE may discover the platoon lead. One or more of the following may occur: the vehicular UE may select the best NR-PSSS / NR-SSSS / NP-PSBCH block on the detected beam for synchronization, the vehicular UE may detect and decode the NR-PSDCH or NR-PSSCH indicated by the NR-PSBCH (e.g., SL-CORESET assignment for NR-PSSCH) or associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block, or associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block having discovery information for a quasi-colocated (QCLed) beam, e.g., QCL type D for spatial QCL relationship, and / or the upper layer or application decides to join the platoon.

[0155] In a first option, the reconfiguration may be based on a broadcast resource pool as illustrated in FIG. 6A (eg, broadcast-based). In step 2A, the formation lead may periodically broadcast or beam sweep the resource pool configuration, which may be, for example, the resources (e.g., reserved and / or unreserved) assigned to the formation in its NR-PSBCH carrying a Sidelink Master Information Block (SL-MIB), or indicated by the NR-PSBCH, or the NR-PSSCH associated with or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block (e.g., carrying remaining or other SL-SI or SL-RRC messages), or the available resources (e.g., unused or not yet reserved) of the total formation resources in its NR-PSSCH associated with or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block (e.g., carrying SL-SI or SL-RRC).

[0156] In step 2B, the vehicular UE may reconfigure the resource pool. One or more of the following may occur: That is, the vehicle UE may determine the available resources based on sensing (note that an example of sensing is shown later in FIG. 16 ) of the total formation resources associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block or broadcast by the formation lead on the QCLed beam, and / or based on the available resources associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block or broadcast by the formation lead on the QCLed beam, and / or based on the sidelink channel occupancy, sidelink radio quality or interference, e.g., Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), or Signal to Noise and Interference Ratio (SNR) on the DMRS or Periodic New Radio Sidelink Channel State Information Reference Signal (NR-SL-CSI-RS) of NR-PSSS / NR-SSSS or NR-PSBCH. A resource pool candidate may be selected based on measurements such as Signal-to-Interference Rate (SINR), if available, and the vehicle UE may pass the resource pool or resource candidates and associated measurements, if available, to a higher layer or application, and / or the higher layer or application may determine the resource pool or resource configuration to use.

[0157] In step 3, the vehicle UE may request to join the platoon. The request may be sent on the default or common sidelink resource indicated by the NR-PSBCH (e.g., SL-MIB) of the lead during synchronization, or the NR-PSDCH or NR-PSSCH during discovery, or the NR-PSBCH in the SL-CSS or SL-USS, or indicated by the SL-CORESET, or the selected NR-PSSS / NR-SSSS / NR-PSBCH block, or the selected sidelink resource from step 2B on the beam associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block, or indicated by the QCLed NR-PSSCH (e.g., carrying SL-SI or SL-RRC). The request may be carried on the new format New Radio Physical Sidelink Control Channel (NR-PSCCH) or New Radio Physical Sidelink Feedback Control Channel (NR-PSFCCH), or the NR-PSSCH.

[0158] In step 4, the platoon lead may transmit a response to the vehicular UE associated with the request to join the platoon. The response may be transmitted on a resource pool within the selected resource indicated in the vehicular UE's request in step 3 or indicated by the vehicular UE in its Transmission Configuration Indicator (TCI) state or associated Reference Signal (RS) index, on default sidelink resources indicated by the syncing lead's NR-PSBCH (e.g., SI-MIB), or the discovering NR-PSDCH or NR-PSSCH, or the NR-PSBCH (e.g., SL-CORESET), or associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block, or indicated by the QCLed NR-PSSCH (e.g., SL-SI or SL-RRC), or on a beam associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block, or indicated by the vehicular UE in its Transmission Configuration Indicator (TCI) state or associated Reference Signal (RS) index. The response may include the sidelink group ID SL-G-RNTI and group member ID SL-G-CRNTI, as well as the associated resource pool configuration for shared or dedicated resources for different communication types such as broadcast, multicast, and unicast, and for shared or dedicated resources among the formation members for each communication type. The response may be carried in the new format NR-PSCCH or NR-PSFCCH, or NR-PSSCH.

[0159] In a second option, the reconfiguration may be based on multicast (eg, group-based) as illustrated in FIG. 6B. In step 2, the vehicle UE may request to join the platoon. The request may be transmitted on default or selected sidelink resources indicated by the lead broadcast NR-PSBCH, or NR-PSBCH, or mapped to a selected NR-PSSS / NR-SSSS / NR-PSBCH block, or mapped to a selected NR-PSSS / NR-SSSS / NR-PSBCH block on a QCLed beam, or indicated on a QCLed NR-PSDCH or NR-PSSCH.

[0160] In step 3, the platoon lead may send a response to the vehicle UE associated with the request to join the platoon. The response may be sent in a default resource pool indicated in the lead's broadcast NR-PSBCH or NR-PSDCH or NR-PSSCH, or in a selected resource pool indicated in the UE's request in the selected NR-PSSS / NR-SSSS / NR-PSBCH block, or in the QCLed beam, or by the vehicle UE in the TCI state or associated RS index. The response may include the sidelink group ID SL-G-RNTI and group member ID SL-G-CRNTI, as well as the associated resource pool configuration for shared or dedicated resources for different communication types such as broadcast, multicast, and unicast, and for shared or dedicated resources between platoon members for each communication type.

[0161] In step 4A, the formation lead may periodically multicast or beam sweep a resource pool on its NR-PSSCH indicated by a Scheduling Assignment (SA) SCI, which may be the total resources (e.g., reserved and unreserved) assigned to the formation, or the available resources (e.g., not yet reserved) of the total formation resources.

[0162] In step 4B, the vehicular UE may reconfigure the resource pool. One or more of the following may occur: the vehicular UE decodes the SA SCI using the sidelink group ID SL-G-RNTI for the multicast message in the beam associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block or QCLed (e.g., the SA SCI is scrambled by the source ID or group ID, or the SA SCI field for the source ID or group ID), based on sensing available resources of the total platoon resources multicast by the platoon lead, or based on available resources multicast by the platoon lead, and / or based on measurements such as sidelink channel occupancy, sidelink radio quality and interference (e.g., RSRP, RSRQ, or SINR measured on the sidelink), if available, or based on the group member ID (e.g., indicated by the SA SCI field for the destination ID or group member ID) for the dedicated resources assigned to the group members by the lead. Based on the SL-G-CRNTI, a resource pool candidate may be selected, and the vehicle UE may pass the resource pool candidates and, if available, sidelink measurements to a higher layer or application, and / or the higher layer or application may determine the resource pool configuration to use.

[0163] In a third option, the reconfiguration may be based on a unicast (eg, ask / response) as illustrated in FIG. 6B. In step 2, the vehicle UE may transmit a request to join the platoon. The request may be transmitted on default or selected sidelink resources indicated in the lead's broadcast NR-PSBCH (e.g., SL-MIB) or NR-PSDCH or PSSCH (e.g., SL-SI or SL-RRC) in the beam, as described above.

[0164] In step 3, the platoon lead may transmit a response to the vehicle UE associated with the request to enter the platoon. The response may be transmitted in the resource pool in the lead's broadcast NR-PSBCH or NR-PSDCH or NR-PSSCH, or may be indicated in the UE's request in the beam as described above, and includes the group RNTI and resource pool. The response may include the sidelink group ID SL-G-RNTI and group member ID SL-G-CRNTI, as well as the associated resource pool configuration for shared or dedicated resources for different communication types such as broadcast, multicast, and unicast, and for shared or dedicated resources among platoon members for each communication type. The resource pool configuration may also be transmitted in a separate unicast message from the platoon lead, e.g., in the PSSCH, which is specifically indicated to the UE by the SA-SCI (e.g., using the UE's group member ID).

[0165] In step 4, the vehicular UE may reconfigure the resource pool. One or more of the following may occur: the vehicular UE may select resource pool candidates in response based on sensing available resources versus shared resources or dedicated resources indicated to group members and measurements on the sidelink such as sidelink channel occupancy, sidelink radio quality or interference, and the vehicular UE may pass the resource pool candidates and measurements, if available, to a higher layer or application as described above, and / or the higher layer or application determines the resource pool configuration to use.

[0166] An example of resource pool configuration and reconfiguration for exiting the platoon is shown in Figures 7A and 7B, which may include, as an example, the following steps. At step 0, the vehicle UE may be associated with the platoon lead and other numbers within the group.

[0167] In the first option as illustrated in FIG. 7A, for example, an RSU or another UE is first discovered. In step 1A, the RSU or another UE may periodically broadcast or beam sweep synchronization signals and discovery information, e.g., NR-PSSS / NR-SSSS / NR-PSBCH for synchronization and beam selection, NR-PSDCH or NR-PSSCH indicated by the NR-PSBCH (e.g., SL-MIB) or associated with or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block for discovery, and broadcast or beam sweep NR-PSCCH and / or NR-PSSCH with a resource pool configuration associated with or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block.

[0168] In step 1B, the vehicular UE may discover an RSU or another UE. One or more of the following may occur: the vehicular UE may select the best NR-PSSS / NR-SSSS / NR-PSBCH detected based on sidelink measurements such as RSRP, RSRQ, or SINC as described above, the vehicular UE may detect and decode the NR-PSDCH or NR-PSSCH for discovery on a beam that is associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH or QCLed, and may pass the sidelink measurements, if available, to a higher layer or application, and / or the higher layer or application may determine a resource pool configuration to use after exiting the platoon or use a resource pool configuration broadcast by the RSU or other UE.

[0169] In step 2, the vehicular UE may request to exit the platoon. The request may be transmitted on selected sidelink resources from resources that are broadcast, multicast, or unicast as described in Figures 6A and 6B.

[0170] In step 3A, the platoon lead may transmit a response to the vehicle UE associated with the request to exit the platoon. The response may be transmitted on sidelink resources or indicated in the UE request in a resource pool configuration as described with respect to Figures 6A and 6B.

[0171] In step 3B, the vehicular UE may receive responses to exit the platoon from other member UEs (e.g., relay member UEs to and from this vehicular UE) in the resource pool indicated in the configuration or in the UE's request, as described with respect to Figures 6A and 6B.

[0172] The second option, as illustrated in FIG. 7B, for example, is to exit the formation first. In step 1, a vehicular UE may request to exit the platoon. The request may be transmitted on selected sidelink resources that are broadcast, multicast, or unicast as described with respect to Figures 6A and 6B.

[0173] In step 2A, the platoon lead may send a response to the vehicle UE associated with the request to exit the platoon with a resource pool indicated in the configuration or in the UE's request, as described with respect to Figures 6A and 6B.

[0174] In step 2B, the vehicular UE may receive responses to exit the platoon from other member UEs (e.g., relay member UEs to and from this vehicular UE) in the resource pool indicated in the configuration or in the UE's request, as described with respect to Figures 6A and 6B.

[0175] In step 3A, the RSU / other UE may periodically broadcast or beam sweep synchronization signals and discovery information, i.e., NR-PSSS / NR-SSSS / NR-PSBCH for synchronization and beamforming, NR-PSDCH or NR-PSSCH indicated by the NR-PSBCH or associated or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block for discovery, and a broadcast NR-PSCCH and / or NR-PSSCH having a resource pool configuration associated or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block.

[0176] In step 3B, the vehicular UE may discover the RSU or other UEs. One or more of the following operations may be performed: the vehicular UE may select the best NR-PSSS / NR-SSSS / NR-PSBCH detected based on sidelink measurements such as RSRP, RSRQ, or SINC as described above, the vehicular UE may detect and decode the NR-PSDCH on a beam that is associated with or QCLed to the selected NR-PSSS / NR-SSSS / NR-PSBCH, and may pass the sidelink measurements, if available, to a higher layer or application, and / or the higher layer or application may determine a resource pool configuration to use after exiting the formation or use a resource pool configuration broadcast by the RSU or other UE.

[0177] For both the first option and the second option as shown in FIG. In step 4, the vehicular UE may reconfigure the resource pool selected by higher layers or an application.

[0178] In step 5, the vehicular UE may broadcast a Basic Safety Message (BSM) or Common Awareness Message (CAM) to be transmitted on the sidelink resource pool selected after reconfiguration.

[0179] An example of resource pool configuration and reconfiguration for switching RSUs of different Public Land Mobile Networks (PLMNs) is shown in FIG. 8A and FIG. 8B, which may include the following steps as an example. In step 0, the vehicular UE may configure and update a resource pool configuration in an RSU of PLMN1.

[0180] In step 1A, RSU2 of PLMN2 may periodically broadcast or beam sweep synchronization signals and discovery information, i.e., NR-PSSS / NR-SSSS / NR-PSBCH for synchronization and beam selection, NR-PSDCH or NR-PSSCH indicated by NR-PSBCH or associated or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block for discovery, and broadcast NR-PSCCH and / or NR-PSSCH having resource pool configuration associated or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block.

[0181] In step 1B, the vehicular UE may discover RSUs of other PLMNs. One or more of the following may occur: the vehicular UE may select the best NR-PSSS / NR-SSSS / NR-PSBCH detected based on sidelink measurements such as RSRP, RSRQ, or SINR as described with respect to FIG. 6A and FIG. 6B. The vehicular UE may detect and decode the NR-PSDCH or NR-PSSCH indicated by the NR-PSBCH or associated or QCLed with the selected NR-PSSS / NR-SSSS / NR-PSBCH block, and pass the discovery information and, if available, the sidelink measurements to a higher layer or application, and / or the higher layer or application may determine a resource pool configuration to enter the selected RSU or may decide to use the resource pool configuration broadcasted by the RSU in the NR-PSBCH or NR-PSCCH and / or NR-PSSCH with the resource pool configuration associated or QCLed with the selected NR-PSSS / NR-SSSS / NR-PSBCH block.

[0182] In the first option (broadcast, discovery-based) as shown in Figure 8A, In step 2, the vehicular UE may send a request to disassociate from RSU1. The request may be sent on the configured sidelink resource pool of RSU1 in a manner similar to that described in Figures 7A and 7B.

[0183] In step 3, RSU1 in PLMN1 may send a response to the vehicular UE associated with the request to disassociate from RSU1 with the resource pool indicated in the configuration of RSU1 or in the UE request, in a manner similar to that described in FIG. 7A and FIG. 7B.

[0184] In step 4, the vehicular UE may request to associate with the RSU2. The request may be transmitted on the default or selected sidelink resource pool of the RSU2 indicated by its NR-PSBCH or NR-PSDCH or NR-PSSCH in a manner similar to that described in Figures 6A and 6B. The vehicular UE may include UE assistant information such as priority, latency, reliability, speed, location, etc. in the request.

[0185] In step 5, RSU2 in PLMN2 may send a response to the vehicular UE associated with the request to associate RSU2 with the resource pool indicated in the RSU2's configuration or in the UE's request, in a manner similar to that described in FIG. 6A and FIG. 6B.

[0186] Please note that in the first option, steps 2 to 5 may be optional, and steps 2 and 3 may be reordered with steps 4 and 5.

[0187] In the second option (unicast-based, response-based) as shown in Figure 8B, In step 2, the vehicular UE may request to associate with the RSU 2. The request may be transmitted on the default or selected sidelink resource pool of the RSU 2 indicated by its NR-PSBCH or NR-PSDCH or NR-PSSCH. The vehicular UE may include UE assistant information such as priority, latency, reliability, speed, location, traffic type, etc. in the request for resource allocation.

[0188] In step 3, the RSU2 of the PLMN2 may send a response to the vehicular UE associated with the request to associate the RSU2 with the resource pool indicated in the configuration or in the UE request, with a resource pool configuration for the vehicular UE based on the UE assistant information sent in the request, as an example in step 3. The vehicular UE may also send a request for resource pool configuration, or a request for later reconfiguration, which may include new or updated UE assistant information for the resource pool (e.g., location change, speed change, etc.).

[0189] In step 4, the vehicular UE may request to disassociate from RSU1. The request may be transmitted on the configured sidelink resources of RSU1.

[0190] In step 5, RSU1 in PLMN1 may send a response to the vehicular UE associated with the request to disassociate from RSU1 with the resource pool indicated in the configuration of RSU1 or in the UE's request.

[0191] Note that in the second option, steps 4 and 5 may be optional.

[0192] For both the first option and the second option as shown in FIG. In step 6, the vehicular UE may reconfigure the resource pool with an RSU2 selected by a higher layer or an application.

[0193] In step 7, the vehicular UE may broadcast a BSM or CAM to be transmitted on the sidelink resource pool selected for RSU2.

[0194] Messages for mapping or de-mapping requests or responses may be carried on the new format PSCCH or the New Radio Physical Sidelink Feedback Channel (NR-PSFCH), or on the NR-PSSCH over the sidelink (PC5) interface.

[0195] (Auxiliary Resource Allocation Sensing Assistant) For highly autonomous vehicles in advanced driving cases, low latency and high reliability are essential for safety. For example, an autonomous vehicle UE needs to detect fallen objects on the road and transmit emergency trajectories and cooperative operations to nearby RSUs and other UEs with performance requirements such as 2000 byte payload, 30 Megabits per second (Mbps) data rate, 3 ms maximum end-to-end latency, and 99.999% reliability.

[0196] However, a sensing-based semi-persistent resource reservation scheme as specified for LTE takes a very long time to sense available resource pool candidates, which are not completely collision-free, which may degrade reliability performance.

[0197] To reduce sensing time and possible collisions, auxiliary sensing may be provided locally by a Sensing Assistant (SA), such as an RSU as a proximate coordinator, a platoon lead, or a proximate lead, or a vehicular UE. The Sensing Assistant may periodically broadcast the usage and reservation status of the local resource pool, as well as interference, congestion, location or location zone, communication range, etc., and the Sensing Assistant may also provide the usage and reservation status of the local resource pool at the request of the vehicular UE.

[0198] The sensing assistant may be pre-configured by the manufacturer or service provider, may be configured by the gNB / eNB or the V2X server, and may optionally be enabled and disabled by the gNB / eNB via a DCI over the Uu interface, or by an RSU, group lead, or proximity coordinator, or lead, over an SCI over the sidelink (PC5) interface.

[0199] An example of auxiliary resource sensing is shown in Figures 9A and 9B, which may include the following steps: The sensing assistant may collect information associated with one or more of the following: traffic patterns (e.g., scheduled or reserved resources), information on periodicity, time offsets, message sizes, QoS information, and source or destination identifiers. It should be understood that the sensing assistant may sense and / or collect any type of information and is not limited to the above examples.

[0200] In step 0, the sensing assistant may collect and broadcast resource pool status. The sensing assistant may constantly collect resource pool or resource status via decoding SA SCI carried in NR-PSCCH transmitted locally from all vehicular UEs and / or measuring sidelink radio link quality and interference (e.g., RSRP, RSRQ, SINC, etc.), and periodically broadcast the resource pool or resource status, as well as interference, congestion, location or location zone, communication range, etc.

[0201] In step 1, the vehicle UE may have a large data size to transmit. The upper layer or application indicates the emergency trajectory and cooperative operation data to be transmitted.

[0202] In the first option (resource state based on broadcast) as shown in Figure 9A: In step 2A, the sensing assistant may periodically broadcast or beam sweep resource pool status, such as time resource pool and frequency resource pool. For example, a bitmap of the symbol pool or mini-slot pool and a bitmap for the RB pool or RBG pool may be broadcast. The resource pool or resource status with other information, such as interference, congestion, location or location zone, communication range, etc., may be indicated by the NR-PSBCH (e.g., SL-CORESET) or may be carried in the broadcast NR-PSSCH indicated by the NR-PSCCH or NR-PSSCH associated with each NR-PSSS / NR-SSSS / NR-PSBCH block or the QCLed NR-PSCCH or the SA SCI carried in the NR-PSCCH, or the SA SCI carried in the NR-PSCCH (e.g., SL-CORESET in the SL-CSS). A periodic configuration may be defined, and a particular broadcast period configuration index may be indicated in the NR-PSBCH, e.g., a 2-bit value indicating four possible period values.

[0203] In step 2B, the vehicular UE may select a resource pool. One or more of the following steps may occur: the vehicular UE may select a resource pool or resource candidates based on a broadcast resource pool or resource state, and may optionally further perform rapid sensing of available resources, e.g., collecting resource reservations within a sensing window defined by the time line and latency requirements for the data to be transmitted (e.g., one or more transport blocks), the vehicular UE may pass the resource pool or resource candidates, and, if available, sidelink channel conditions (e.g., congestion), radio quality, and interference measurements to a higher layer or application, and / or the higher layer or application determines the resource pool to use.

[0204] The second option (resource state based on request) as shown in Figure 9B: In step 2A, the vehicular UE may transmit a request for a resource pool or resource status. The request may be transmitted on the default or reserved sidelink resources for sensing assistance's NR-PSBCH or an emergency request associated with a selected NR-PSSS / NR-SSSS / NR-PSBCH block or indicated in a QCLed NR-PSDCH or broadcast NR-PSSCH. The request may include a sidelink group ID SL-G-RNTI, a sidelink group member ID SL-G-CRNTI, if required, for group-based sensing assistance, or a sidelink ID SL-CRNTI or a location zone-ID of the vehicular UE for proximity or range-based sensing assistance, if required. The request may be carried in a new format SCI on the PSCCH, or a new radio physical sidelink feedback control channel (NR-PSFCCH), or in a new format Sidelink Feedback Control Information (SFCI) on the NR-PSSCH on a beam that is associated with or QCLed to a selected NR-PSSS / NR-SSSS / NR-PSBCH block, or associated with a TCI state or RS index indicated to the vehicle UE.

[0205] In step 2B, the sensing assistant may send a response with a resource pool or resource status on the sensing assistant's NR-PSBCH or the resource pool or resources indicated by the NR-PSDCH or broadcast NR-PSSCH indicated in the vehicular UE's request, which may be associated or QCLed with the sensing assistant's NR-PSSS / NR-SSSS / NR-PSBCH block, or may include the sensing assistant's sidelink group ID or location zone ID. The response may be broadcast, multicast, or unicast on the NR-PSSCH indicated or associated with the selected NR-PSSS / NR-SSSS / NR-PSBCH block, or the PSCCH on the beam indicated by the vehicular UE in its request with the TCI state or RS index.

[0206] In step 2C, the vehicular UE may select a resource pool or resource. One or more of the following steps may occur: the vehicular UE may select a resource pool or resource candidate using a resource pool or resource status, and a group ID in the group-based case or a location zone ID in the proximity- or range-based case, and may optionally further perform rapid sensing of available resources, e.g., collecting resource reservation statistics within a sensing window defined by the time line and latency requirements for the data to be transmitted (e.g., one or more transport blocks), the vehicular UE may pass the resource pool or resource candidate and, if available, sidelink channel conditions, radio quality, and interference measurements to a higher layer or application, and / or the higher layer or application may determine a resource pool or resource configuration to use.

[0207] For both the first and second option: In step 3, the vehicle UE may further sense the channel on the selected sidelink resource, if needed, to see if it is still available by using, as an example, energy detection or Received Signal Strength Indication (RSSI) measurements, e.g., sense channel occupancy.

[0208] In step 4, the vehicular UE may broadcast emergency data using repetition or beam sweeping. The vehicular UE may broadcast emergency trajectories and cooperative operations locally to all UEs on selected resources. The same or different resources may be used for repetition to the same receiver or beam sweeping to different receivers, as illustrated in steps 4B and 4C. The data may be carried on the broadcast NR-PSSCH, indicated by the SA SCI carried on the NR-PSCCH.

[0209] Note that step 3 may be optional.

[0210] (Auxiliary Resource Allocation Scheduler) Sensing-based resource allocation is not collision-free, especially with many periodic event-triggered data at traffic accident locations, busy intersections, or tightly spaced car platoons. To reduce sensing overhead and avoid possible collisions, resource pools or resources may be reserved by a local scheduler, such as an RSU as a proximate coordinator, a platoon lead, or a proximate lead, or a scheduling UE. The scheduler may periodically broadcast resource allocations for each vehicular UE or provide resource allocations at the request of the vehicular UE.

[0211] The scheduler may be pre-configured by the manufacturer or service provider, or may be configured by the gNB / eNB or V2X server, and may optionally be enabled and disabled by the gNB / eNB via a DCI over the Uu interface, or by an RSU, group lead, or proximity coordinator, or lead, over an SCI over a sidelink (PC5) interface.

[0212] The scheduler may statically configure resources or resource pools for the UE to select, for example, via a SL-RRC message on the PSSCH. The scheduler may semi-statically indicate resources or resource pools for the UE, for example, via a SL-MAC CE. The scheduler may semi-persistently assign resources or resource pools for the UE, for example, via SCI enablement or disablement. The scheduler may dynamically assign resources or resource pools for the UE, for example, via a SA SCI.

[0213] An example of local scheduling with a lead as a scheduler (e.g., an RSU as a coordinator or a lead in a group of neighbors, a platoon lead, etc.) is shown in FIG. 10A and FIG. 10B, which may include the following steps: At step 0, the vehicle UE may enter a group (e.g., a platoon led by a platoon lead, a nearby group led by a nearby lead, etc.) and establish a connection to the lead and other UEs in the group via group discovery and group joining procedures. The vehicle UE may also receive the SL-G-CRNTI as a group member ID or label in the group, or a location zone ID for proximity or range.

[0214] In step 1, the lead may be configured with or assigned with a shared or dedicated resource pool or resources, constantly or frequently collects the resource pool or resource status locally from all UEs and RSUs, and may reserve the resource pool or resources for the group if a shared resource pool is used.

[0215] In step 2, the higher layer or application layer of the vehicle UE may indicate that data is available for transmission, which may be periodic or aperiodic, repeat or retransmission with hybrid automatic repeat request HARQ feedback, etc.

[0216] In the first option (resource state based on multicast group basis) as shown in Figure 10A: In step 3A, the lead periodically broadcasts or beamsweeps resource allocations for group members, such as time and frequency resource pools for each UE in the group. The resource allocations may be carried in a new format SA SCI carried in the NR-PSCCH, or indicated by its NR-PSBCH, or in a multicast NR-PSSCH associated with or QCLed to each NR-PSSS / NR-SSSS / NR-PSBCH block, or indicated by a SA SCI carried in the NR-PSCCH. The resource allocations may be shared or dedicated for different communication types, such as broadcast, multicast, and unicast, and may be shared or dedicated among group members for each communication type. The resource allocations may be semi-statically enabled and disabled by the SCI, or may be dynamically indicated by the new format SA SCI.

[0217] In step 3B, the vehicular UE may select a resource pool or resource. One or more of the following actions may occur: The vehicular UE may select a resource pool or resource based on the resource pool or resource assigned to it (e.g., mapped to a group member ID SL-G-CRNTI for dedicated resources or mapped to a location zone ID for proximity or range-based resources) and transmit data carried on the NR-PSSCH on the mapped SCI carried on the NR-PSCCH accordingly. For shared resources, the vehicular UE may perform quick sensing and sidelink measurements, pass the selected resource and measurements to higher layers or applications, and / or the higher layers or applications may load data accordingly. In another example for shared resources, the vehicular UE may perform channel occupancy sensing, e.g., energy detection or RSSI-based, to check whether a channel or resource is available to transmit data.

[0218] In the second option (resource state based on request) as shown in Figure 10B, In step 3A, a vehicular UE, e.g., a transmitting or receiving UE, may transmit a request for resources or a request for scheduling. The request may be transmitted on default or reserved sidelink resources for emergency or scheduling requests allocated by the lead as scheduler. The request may be carried in a new format SCI on NR-PSCCH, or a new format SFCI on NR-PSSCH on NR-PSFCCH, or a beam associated with or QCLed to a selected NR-PSSS / NR-SSSS / NR-PSBCH block, or associated with a TCI state or RS index indicated to the vehicular UE.

[0219] In step 3B, the lead may send a response with a resource allocation or schedule in the resource pool or resources allocated by the lead or indicated in the UE's request. The response may include a group member ID, e.g., SL-G-CRNTI, assigned to the vehicular UE for group-based resource allocation for this vehicular UE, or a location zone ID for proximity or range-based resource allocation. The resource allocation may be indicated by a SA SCI carried on the NR-PSCCH scrambled with or carried with the group member ID or UE's sidelink ID, e.g., SL-CRNTI, or location zone-ID, or by a multicast or unicast NR-PSSCH indicated by the SA SCI carried on the NR-PSCCH.

[0220] In step 3C, the vehicular UE may select a resource pool or resource. One or more of the following may occur: the vehicular UE may transmit data on an assigned or scheduled resource (e.g., associated with the SL-G-CRNTI) if the resource is a dedicated resource; the vehicular UE may select a resource based on a resource pool or resource assigned to it (e.g., associated with the SL-G-CRNTI) if the resource is shared, and the UE may pass the selected resource and sidelink measurements to a higher layer or application, and / or the higher layer or application may load data accordingly.

[0221] For both the first and second option: In step 4A, the vehicular UE may broadcast emergency data. The vehicular UE may broadcast emergency trajectories and cooperative operations to all UEs locally on selected resources. All nearby UEs may receive the broadcast message on the assigned resources, e.g., broadcast response, or in case of configured broadcast monitoring, which may be indicated by a lead in step 3B. The same or different resource allocations may be used for repeating to the same receiver or beam sweeping to different receivers, as exemplified in steps 4B and 4C. Data may be carried on the broadcast NR-PSSCH, indicated by the SA SCI carried on the NR-PSCCH.

[0222] For multicast, UEs in the multicast group may receive the multicast message in response to the allocated resources, e.g., a broadcast or multicast response, or in the case of configured multicast monitoring, which may be indicated by the lead in step 3B.

[0223] For unicast, if a request is sent from the transmitting UE in step 3A as illustrated in FIG. 10B, the receiving UE of the unicast pair may accordingly receive a unicast message on the allocated resources, e.g., a broadcast, multicast, or unicast response to the unicast pair, or in the case of configured unicast monitoring, which may be indicated by the lead in step 3B; if a request is sent from the receiving UE in step 3A, the transmitting UE of the unicast pair may transmit a unicast message on the allocated resources, e.g., a broadcast, multicast, or unicast response to the unicast pair, as indicated by the lead in step 3B, and the receiving UE of the pair may receive the unicast message on the resources indicated by the lead in step 3B.

[0224] (Auxiliary resource allocation Scheduler allocation) The scheduler may be an RSU, platoon lead, or proximate lead as a proximate coordinator, or a scheduling UE that may be pre-configured by a manufacturer or service provider (e.g., a V2X service provider or network operator) for use when out of coverage or partially covered by a serving node, or may be selected or enabled and disabled by a serving or scheduler control network entity, e.g., when under network coverage and scheduler allocation is under network control. Herein, the serving node or scheduler control entity may be, for example, a serving gNB or a V2X server (e.g., a V2X control server in a core network or a V2X application server in a V2X service provider network). Furthermore, the scheduler may also be selected from a group of proximate candidate schedulers or schedulable entities of the scheduled UE.

[0225] The scheduler may be indicated or modified by the gNB via an RRC, MAC CE, physical channel (e.g., PDCCH, PDSCH, PUCCH, PUSCH, or new physical broadcast channel), or a combination thereof, over the Uu interface, or by an RSU or UE via an SL-RRC, SL-MAC CE, sidelink physical channel (e.g., NR-PSCCH, NR-PSFCH, NR-PSSCH, etc.), or a combination thereof, over the sidelink (PC5) interface. The scheduler may also be enabled and disabled or modified by the gNB via an RRC, MAC CE, or DCI over the Uu interface, or by an RSU or UE via an SL-RRC, SL-MAC CE, or SCI over the sidelink (PC5) interface. Communications between the serving scheduler and candidate schedulers, or between the scheduler and other UEs, may be carried over the sidelink (PC5) interface on SL-RRC, SL-MAC CE, sidelink physical channels (e.g., NR-PSCCH, NR-PSFCH, NR-PSSCH, etc.), or a combination thereof.

[0226] FIG. 17 shows an example of UE initiated network controlled scheduler selection, illustrated in the following steps.

[0227] In step 1, request to become a scheduler, i.e. decide to become a scheduler and send a request to become a scheduler to a gNB or V2X server, including UE context and capabilities, location or location zone, resource pool requirements and QoS requirements, as well as sidelink measurements such as interference, congestion, link quality, etc., and wait for a response.

[0228] In step 2, check the response. If no, go to step 5, if not, go to step 3.

[0229] In step 3, check if it is a rejection in response. If no, go to step 6, if not, go to step 4.

[0230] In step 4, adjust the capabilities, resource pool requirements, etc. for each rejection reason.

[0231] In step 5, a timeout t OutSchReq If no, go to step 1, if yes, do step 7 for termination.

[0232] In step 6, if it is a synchronization source UE, it starts broadcasting the scheduling indications carried periodically on its NR-PSBCH, on its NR-PSDCH, or on its broadcast NR-PSSCH.

[0233] In step 7, the scheduler selection is completed.

[0234] In an alternative example, network (e.g., gNB, V2X server, or scheduler selection controller) initiated scheduler selection is shown in FIG. 18, which is illustrated with the following steps:

[0235] In step 1, collect scheduler candidates, i.e., update the scheduler candidate list with UEs that want to be schedulers during procedures such as registration, attachment, etc., update the capability list of the scheduler candidates based on the UE capability indication, update the location or location zone of the scheduler candidates, collect sidelink channel occupancy, radio link quality, interference, etc. measured and reported by the scheduler candidates.

[0236] In step 2, check if a scheduler is needed. If no, go to step 1, if not, go to step 3.

[0237] In step 3, a scheduler is selected, i.e., a scheduler is selected from the candidate list based on the UE capabilities, location, resource pool requirements, QoS requirements, sidelink measurements, etc., and a request is sent to the selected scheduler and awaits a response.

[0238] In step 4, check if any response is received. If no, go to step 7, if not, go to step 5.

[0239] In step 5, check if there is a rejection in response. If yes, go to step 3 to select another scheduler, if not, go to step 6.

[0240] Step 6 enables the scheduler, for example as indicated in the RRC or MAC CE, or in the Downlink Control Information (DCI) sent to the scheduler.

[0241] In step 7, the timeout t OutSchReq If yes, go to step 3 to select another scheduler, if no, go to step 4 for response.

[0242] In an alternative example to network-controlled scheduler selection, an example of scheduler selection without network control is shown in Figures 19A and 19B, which illustrates the following steps:

[0243] In step 1, scan for a scheduling indication, which may be indicated by the scheduler's NR-PSBCH, NR-PSDCH, or broadcast NR-PSSCH.

[0244] In step 2, check if any scheduler is detected. If no, go to step 4, else go to step 3.

[0245] In step 3, if a scheduler is found, extract the scheduler's information, such as ID, resource pool, location or location zone, QoS requirements, etc., and update the scheduler list.

[0246] In step 4, a timeout t OutScanSch If yes, go to step 5, if no, go to step 1 to continue scanning for the scheduler.

[0247] In step 5, check if the scheduler list is empty. If yes, and there is no nearby scheduler, go to step 6B and make a request to the first nearby scheduler, if no, go to step 6A and make a request to another nearby scheduler.

[0248] In step 6A / 6B, request to become a scheduler, i.e., decide to become a scheduler as indicated by higher layers or application layers, and broadcast a request as a new scheduler with capabilities, resource pool configuration, QoS requirements, and location or location zone on common or default resources or resources for broadcasting in proximity. The request can be a special format SCI carried on NR-PSCCH, or a special format SFCI carried on NR-PSFCCH or broadcast NR-PSSCH. Wait for a response on common or default or broadcast resources, or resources indicated in the request.

[0249] Step 7A / 7B checks if there is any response. If yes, go to step 9A / 9B to check for rejection, if no, go to step 8A / 8B to check for timeout.

[0250] In step 8A / 8B, based on the upper layer parameters, a timeout t OutSchReqIf no, go to step 6A / 6B to request again to become the scheduler, if 8A is yes, go to step 15A to exit, if 8B is yes, go to 13B to check the UE list.

[0251] In step 9A / 9B, check if there is a rejection in response. If yes, proceed to step 12A / 12B to update the UE's context, if no, proceed to step 10A / 10B.

[0252] In step 10A / 10B, check whether one or more schedulers / UEs in the scheduler / UE list, e.g., schedulers or UEs that are nearby or within communication range, have responded yes. If yes, proceed to step 14.

[0253] In step 11A / 11B, update the UE list, update the scheduler list for step 11A. Update the UE list, e.g., schedulers or UEs that are nearby or within communication range, for step 11B based on the response. Then proceed to step 8A / 8B to check for timeout.

[0254] In step 12A / 12B, based on the response, update the UE list and scheduler list for 12A, update the UE list for step 12B, adjust the candidate scheduler capabilities, resource pool configuration requirements, QoS requirements, etc. Then proceed to step 8A / 8B to check the timeout.

[0255] In step 13B, check whether the UE list is empty. If yes, and there is no other UE, go to step 14 and become the first UE there as scheduler, if no, go to step 15B and end.

[0256] In step 14, it becomes the scheduler and starts broadcasting the scheduling indication periodically on its NR-PSBCH, NR-PSDCH, or broadcast NR-PSSCH.

[0257] A call flow for scheduler selection without network control is illustrated in FIG. 20A and FIG. 20B, which may include the following steps.

[0258] At step 0, configuration, i.e., the scheduler UE, other UEs, and other schedulers are configured with a common resource pool, a default resource pool, a broadcast resource pool, etc. The configuration can be done by the manufacturer or the service provider, or by the gNB or V2X server if under network coverage and network management.

[0259] In step 1, it decides to become a scheduler, i.e., the upper layer or application layer of a candidate scheduler UE may pass an indication to become the scheduler.

[0260] In step 2, a request "to become a scheduler" is broadcast, i.e., the candidate scheduler UE sends the request on sidelink common, default or broadcast resources. The request may include UE capabilities, location or location zone, resource pool requirements and QoS requirements, as well as sidelink measurements such as interference, congestion, link quality, etc. The request may be a new format SCI carried on NR-PSCCH or a new format SFCI carried on NR-PSFCCH or broadcast NR-PSSCH.

[0261] In step 3, other schedulers and / or other UEs responding to the request "to become a scheduler", i.e., nearby, may send responses on sidelink common, default, or broadcast resources, or on resources indicated in the request. The responses may be a new format SCI carried on the NR-PSCCH, or a new format SFCI carried on the NR-PSFCCH or broadcast NR-PSSCH. The candidate scheduler UEs may decode the responses and pass them on to their higher layers.

[0262] In step 4, any rejection is checked, i.e. the higher layer of the candidate scheduler UE may check any rejection carried in the response from other schedulers or UEs and, if available, the reason for the rejection, and then adjust the capabilities and context of the scheduler UE, adjust requirements for resource pool allocation, adjust QoS requirements, etc.

[0263] In step 5, broadcast a request "to become a scheduler", i.e., the candidate scheduler UE sends the request again on sidelink common, default or broadcast resources with the updated UE context and other information. The request may include the adjusted parameters from step 4.

[0264] In step 6, other schedulers and / or other UEs responding to the request "to become a scheduler", i.e., in the vicinity, may send responses on sidelink common, default or broadcast resources or resources indicated in the request. Candidate scheduler UEs may decode the responses and pass them on to their upper layers.

[0265] In step 7, it becomes the scheduler, i.e., it checks that there is no rejection in the response. It then becomes the scheduler.

[0266] In step 8, broadcast "scheduling indication", i.e., the new scheduler UE broadcasts the scheduling indication periodically on its NR-PSBCH, NR-PSDCH, or broadcast PSSCH. The scheduling indication on the NR-PSBCH may be a one-bit indication to flag whether the UE is a scheduler or not. The scheduling indication on the NR-PSDCH or NR-PSSCH may be used during discovery or association process. The scheduling indication on the NR-PSCCH or NR-PSSCH may be used by UEs that have already established a relationship with the scheduler UE to update the scheduler UE's context (e.g., it is a new scheduler) and other information such as the resource pool configuration managed by this new scheduler.

[0267] In step 9, the new scheduler is associated, i.e., the other UEs and / or schedulers either update the context of the new scheduler UE if a relationship has already been established via message exchange carried on NR-PSSCH, or enter the group or pair of the new scheduler or associate with the new scheduler if a relationship has not yet been established via message exchange carried on NR-PSDCH or NR-PSSCH for the discovery or association process.

[0268] An example of scheduler modification with network control is illustrated in the call flow shown in FIG. 21, which may include the following steps.

[0269] At step 0, upon connection to the network, i.e., scheduler 1 and scheduler 2 are registered as candidate schedulers and configured with shared or dedicated resource pools for the schedulers. Scheduler 1 is the serving scheduler and scheduler 2 is the candidate scheduler.

[0270] In step 1, a decision is made to relinquish the scheduler role, ie, a layer above scheduler 1 or an application layer indicates that it will relinquish the scheduler role.

[0271] In step 2, request to quit, i.e., scheduler 1 sends a request to the gNB or V2X server to quit the scheduler role. The request may be carried on a new format Physical Uplink Control Channel (PUCCH) or Physical Uplink Shared Channel (PUSCH) if sent to the gNB on the NR Uu interface.

[0272] In step 3, find the next scheduler, i.e., the gNB or V2X server checks the scheduler candidate list with the UE capabilities and state, such as location or location zone, as well as sidelink measurements reported by the candidate schedulers, and decides which candidate will be requested as the next scheduler.

[0273] In step 4, request the next scheduler, i.e., the gNB or V2X server sends a request to a candidate scheduler, e.g., scheduler 2, which may be carried on the new format Physical Downlink Control Channel (PDCCH) or Physical Downlink Shared Channel (PDSCH) when transmitted from the gNB on the NR Uu interface.

[0274] In step 5, the request to the next scheduler is responded to, i.e., the candidate scheduler, e.g., scheduler 2, may respond to the request with acceptance or rejection information that may be carried in the new format PUCCH or PUSCH. In case of rejection, the gNB or V2X server may reselect a candidate scheduler and send a request to the newly selected candidate scheduler.

[0275] In step 6, the scheduler modification is signaled, i.e., the gNB may send an enabling RRC, MAC CE, or DCI to the new scheduler (e.g., scheduler 2) and an disabling RRC, MAC CE, or DCI to the old scheduler (e.g., scheduler 1), and may broadcast to all UEs regarding the scheduler modification via the PDCCH, PDSCH, new physical broadcast channel, or a combination thereof. The V2X server may send a confirmation message to scheduler 1 and scheduler 2, respectively, to notify all UEs of the scheduler modification.

[0276] In step 7, the old scheduler is disassociated, i.e., the UE disassociates from the old scheduler, e.g., scheduler 1, by sending a notification to it on the sidelink, and may then remove the context of the old scheduler after a confirmation is received from the old scheduler.

[0277] In step 8, the UE is associated with a new scheduler, i.e., the UE may associate with a new scheduler, e.g., scheduler 2, by sending a pairing or association request to the new UE, and then save the context of the new scheduler received from the new scheduler's response.

[0278] The association and deassociation request and response messages over the sidelink interface may be carried on a new format NR-PSCCH with SCI, NR-PSFCH with SFCI, or NR-PSSCH with multiplexed SCI or SFCI, or a special mapped NR-PSSCH at higher layers.

[0279] An example of scheduler replacement without network control is illustrated in FIG. 22, which may include the following steps.

[0280] In step 1, decide to quit, i.e. higher layer or application layer indicates to quit scheduler role. Broadcast a request to candidate schedulers on common or default resources. The request can be carried in new format SCI on NR-PSCCH or new format SFCI on NR-PSFCCH or broadcast NR-PSSCH. Wait for a response on common or default resources or indicated in the request.

[0281] In step 2, check if there is any response. If yes, go to step 4 for handover, if no, go to step 3 to check for timeout.

[0282] In step 3, a timeout t OutQtReq If yes, go to step 5 and exit, if no, go to step 1 and resubmit the request.

[0283] In step 4, there is a handover to the new scheduler, i.e., the current scheduler may pass the scheduler context, other associated UE contexts, and resource pool configuration to the new scheduler.

[0284] End at step 5, i.e., if no candidate scheduler responds, hard stop without any context exchange.

[0285] The call flow for scheduler replacement without network control is illustrated in FIG. 23, which may include the following steps.

[0286] In step 0, the prerequisites, i.e., scheduler 1 and scheduler 2, are configured as scheduler candidates in a shared or dedicated resource pool. Scheduler 1 is the serving scheduler and scheduler 2 is the candidate scheduler.

[0287] In step 1, a decision is made to relinquish the scheduler role, ie, the upper layer of the current scheduler, for example scheduler 1, indicates that it will relinquish the scheduler role.

[0288] In step 2, a request to the candidate schedulers is broadcast, i.e., the current scheduler, e.g., scheduler 1, may broadcast a request to the candidate schedulers on common or default resources. The request may be carried in a new format SCI on the NR-PSCCH, or a new format SFCI on the NR-PSFCCH, or an SCI or SFCI multiplexed on the PSSCH or broadcast NR-PSSCH.

[0289] In step 3, a decision is made to become the next scheduler, i.e., a candidate scheduler, e.g., scheduler 2, may decode the request and pass it to the upper layer, which may decide to become the next scheduler.

[0290] In step 4, a response to the request is broadcast, i.e., the candidate scheduler, e.g., scheduler 2, broadcasts the response to the request on common or default resources. The response may be carried in a new format SCI on the NR-PSCCH or a new format SFCI on the NR-PSFCCH or broadcast NR-PSSCH.

[0291] In step 5, the response is acknowledged, i.e., the candidate scheduler, e.g., scheduler 2, may receive an acknowledgement from the current scheduler, from other UEs, and / or from other schedulers. The acknowledgement may be carried in a new format SCI on the NR-PSCCH, or a new format SFCI on the NR-PSFCCH or NR-PSSCH.

[0292] In step 6, the context is passed, i.e., the current scheduler, e.g., scheduler 1, passes the context, resource pool configuration, etc. to the candidate scheduler via the sidelink, which may be carried on the NR-PSSCH.

[0293] In step 7, the old scheduler is disassociated, i.e., the UE disassociates from the old scheduler, e.g., scheduler 1, by sending a notification to it on the sidelink, and may then remove the context of the old scheduler after a confirmation is received from the old scheduler.

[0294] In step 8, the UE is associated with a new scheduler, i.e., the UE may associate with a new scheduler, e.g., scheduler 2, by sending a pairing request to the new UE, and then save the context of the new scheduler received from the new scheduler's response.

[0295] (Resource allocation mode switching) Resource allocation may be done in different operating modes, e.g., sidelink resource allocation fully controlled by the gNB or eNB (e.g., Mode 1), sidelink resource allocation based on sidelink sensing and resource selection (e.g., Mode 2(a)), sidelink resource allocation based on pre-configuration or configuration from the gNB or eNB (e.g., Mode 2(c)), sidelink resource allocation managed by a scheduler, e.g., scheduling UE (e.g., Mode 2(d)). One or more modes in combination may be configured and enabled for a vehicular UE to communicate on the sidelink. The UE may also select or be instructed to switch from one mode to another.

[0296] A resource allocation mode may be configured, indicated, or modified by the gNB via RRC, MAC CE, physical channels (e.g., PDCCH, PDSCH, PUCCH, PUSCH, etc.), or a combination thereof, over the Uu interface, or by the RSU or UE via SL-RRC, SL-MAC CE, sidelink physical channels (e.g., NR-PSCCH, NR-PSFCH, NR-PSSCH, etc.), or a combination thereof, over the sidelink (PC5) interface. Resource allocation modes may also be enabled and disabled by the gNB via RRC, MAC CE, or DCI over the Uu interface, or by the RSU or UE via SL-RRC, SL-MAC CE, or SCI over the sidelink (PC5) interface.

[0297] The resource allocation mode may also be indicated by other signals or channels at the physical layer, such as NR-PSBCH, NR-PSDCH, NR-PSCCH, NR-PSFCH, NR-PSSCH, or a combination thereof.

[0298] An example of resource allocation mode switching, e.g., between sensing-based (e.g., mode 2(a)) and scheduling-based (e.g., mode 2(d)) with network control is illustrated in Figures 24A and 24B, which may include the following steps.

[0299] In step 0, connecting to a network, i.e., the UE and the scheduler are connected to the network and configured with a shared or dedicated resource pool. The scheduler is a candidate scheduler.

[0300] Step 1: V2X communication on sidelink, i.e., the UE communicates with other UEs on sidelink using a configured shared or dedicated sidelink resource pool. For a shared resource pool, the UE may need to sense and reserve for resource allocation, or the UE may need to sense the channel over the available resources for a more dynamic resource allocation.

[0301] In step 2, the scheduler becomes the scheduler, i.e., the scheduler is enabled by the gNB as a new scheduler with the assigned shared or dedicated resource pool.

[0302] UE initiated scheduler discovery for option 1: In step 3A, a "scheduling indication" is broadcast, i.e., the scheduler may periodically broadcast the scheduling indication on its NR-PSBCH / NR-PSDCH / NR-PSSCH.

[0303] In step 4A, the scheduler is discovered, i.e., the vehicle UE can decode the scheduler indication and pass it to its upper layer. The upper layer decides to enter the scheduler.

[0304] gNB initiated discovery for option 2: In step 3B, indicate scheduler, i.e., the gNB may send a scheduler indication to the UE via a broadcast (e.g., on the PDSCH or new broadcast channel), groupcast (e.g., on the PDSCH or new groupcast channel), or unicast (e.g., on the PDSCH) message to command the UE to enter the scheduler and switch to a scheduler-managed resource allocation mode. The gNB may send an indication by RRC, MAC CE, or DCI enablement to enable the scheduler to the UE or enable the new resource allocation mode for the UE and also enable the resource pool.

[0305] For both Option 1 and Option 2: In step 5, the vehicle UE may request to be associated with the scheduler, i.e., the vehicle UE may send a request on the NR-PSCCH, or NR-PSFCH or NR-PSSCH to the scheduler to join the scheduler's group or pair with the scheduler.

[0306] In step 6, the scheduler responds to the association request, i.e., the scheduler may respond to the UE's request to establish association, which may be carried on the NR-PSCCH or NR-PSFCH or NR-PSSCH.

[0307] For option 1, the UE selects resources that are configured or semi-persistently scheduled by the scheduler.

[0308] In step 7A, V2X communication on sidelink, i.e., the UE may communicate with other UEs on sidelink by selecting a shared or dedicated sidelink resource pool or resources configured or semi-statically assigned by the scheduler (e.g., indicated by an enabled SL-RRC, SL-MAC CE, or SCI).

[0309] For option 2, the scheduler dynamically allocates resources (eg, dynamic scheduling).

[0310] In step 7B, a request for resource allocation or scheduling, i.e., the UE sends a request to the scheduler for resources to send to or receive from other UEs on the sidelink.

[0311] In step 8B, resources are granted or scheduled, i.e., the scheduler may grant or schedule resources to the transmitting UE or both the transmitting UE and the receiving UE, as indicated by the SA SCI carried on the NR-PSCCH.

[0312] In step 9B, V2X communication on the sidelink, i.e., the UE communicates with other UEs using sidelink resources dynamically allocated by the scheduler via the SA SCI.

[0313] An example of resource management mode switching without network control is illustrated in FIG. 25A and FIG. 25B, which may include the following steps.

[0314] In step 0, pre-configuration or configuration, i.e., UEs and schedulers or scheduler candidates are configured with a shared or dedicated resource pool. Scheduler 1 is the serving scheduler and scheduler 2 is the candidate scheduler.

[0315] In step 1, V2X communication on sidelink, i.e., a vehicle UE communicates with other UEs on sidelink using resources semi-statically or dynamically allocated by scheduler 1.

[0316] In step 2, deassociate with the scheduler, i.e., the UE is deassociated with scheduler 1, which may be triggered by higher layers (e.g., leaving the proximity of scheduler 1) or timers (e.g., beam failure timer or out of sync timer). The UE may switch to a non-scheduler managed resource allocation mode as exemplified as option 1 and option 2 in the next steps.

[0317] For option 1, choose resources based on perception: In step 3A, the reserved or used resources are sensed, i.e., the UE may select the resources based on sensing (e.g., decoding SA SCI transmitted from other UEs in the vicinity of the reserved or used resources) and / or based on sidelink channel occupancy and quality measurements, etc.

[0318] In step 4A, V2X communication on sidelink, i.e., a vehicle UE communicates with other UEs on sidelink using resources selected by itself.

[0319] For option 2, select the resources based on your configuration: In step 3B (optional), collision avoidance channel sensing, i.e., optionally, particularly for configured shared resources, the UE may perform channel sensing using channel sensing such as listen-before-talk on the configured resources.

[0320] In step 4B, V2X communication on sidelink, i.e. the UE communicates with other UEs on sidelink using configured resources that are not occupied when channel sensing is used in step 3B.

[0321] For both options: In step 5, the scheduler, i.e., scheduler 2, becomes the new scheduler in the vicinity of the UE.

[0322] In step 6, broadcast "Scheduling Indication", i.e., Scheduler 2 may broadcast the Scheduling Indication periodically on its NR-PSBCH / NR-PSDCH / NR-PSSCH.

[0323] Step 7: Associate with discovered scheduler, ie, the UE discovers scheduler 2 and associates with the scheduler accordingly.

[0324] In step 8, V2X communication on sidelink, i.e., the vehicle UE switches resource allocation mode and communicates to other UEs on sidelink by using resources semi-statically or dynamically allocated by scheduler 2.

[0325] Request and response messages for different purposes as described herein may be carried on a new format PSCCH with SCI, an NR-PSFCH with SFCI, an NR-PSSCH with multiplexed SCI or SFCI, or a spatially mapped NR-PSSCH at higher layers.

[0326] (Example of resource allocation) NR supports many different numerologies that may include different numbers of slots in a subframe, e.g., one slot per subframe for 15 KHz subcarrier spacing, and two slots per subframe for 30 KHz subcarrier spacing. To simplify illustration, slots are used in the examples. However, the slot structure shown in the examples may also be applicable to subframes.

[0327] For resource allocation or scheduling in the sidelink with different slot and minislot structures, some examples are shown in Figures 11, 12, 13, and 14. Slot-based resource allocation or scheduling examples are shown in Figures 11, 12, and 13. Here, the scheduling assignment (SA) SCI in the NR-PSCCH is not necessarily adjacent to the associated NR-PSSCH carrying data in time, and may be on the same or different beams depending on whether the NR-PSCCH and NR-PSSCH are fully or partially quasi-co-located (QCLed), respectively, in the sidelink. A minislot-based resource allocation or scheduling example is shown in Figure 14. Here, the scheduling assignment (SA) SCI in the NR-PSCCH may be more efficient if it is adjacent to the associated NR-PSSCH carrying data in time and carried on the same beam in the sidelink.

[0328] 11 illustrates the broadcast, multicast, and unicast resources allocated or scheduled in different BWPs, e.g., BWP1 and BWP2, of a sidelink operating band using different numerologies. For example, BWP1 with bandwidth from RB / RBG / subchannel k2 to RB / RBG / subchannel N has a Sub-Carrier Space (SCS) of 15 KHz, and BWP2 with bandwidth from RB / RBG / subchannel 0 to RB / RBG / subchannel k1 has an SCS of 30 KHz.

[0329] As shown in FIG. 11, different slot structures may be formed based on the data being transmitted, the time line, and feedback from the receiving vehicle UE.

[0330] For example, slot “SL1_1” of BWP1 may optionally include a first symbol (depending on numerology, e.g., symbol length, and AGC decision time requirements) for the receiver’s Automatic Gain Control (AGC), which may be sequence-based or modulation-data-based design (e.g., using dummy data or randomly generated data or user data) for the preconditions of the receiver’s AGC settings, and a SA carried in the NR-PSCCH and its SideLink Demodulation Reference Signal (SL-DMRS) to indicate resource location for the associated NR-PSSCH (e.g., NR-PSSCH1 and NR-PSSCH2) carrying data. Two exemplary symbols herein as a control region for SCI (e.g., SCI1 for short latency unicast in NR-PSSCH1 and SCI2 for broadcast in NR-PSSCH2) and a SideLink Demodulation Reference Signal (SL-DMRS) for NR-PSSCH, a SideLink Channel State Information (SL-CSI-RS) for SideLink Channel State Information (SL-CSI) reporting, a SideLink Phase-tracking Reference Signal (SL-PTRS) for tracking frequency and / or phase, a SideLink Positioning Reference Signal (SL-PTRS) for position measurement, and a SideLink Positioning Reference Signal (SL-PRS) for position measurement. some symbols for data and / or reference signal (RS) transmission such as NR-PSSCH1 (SL-PRS), one symbol here (depending on the numerology, e.g., symbol length, and switching time of the vehicular UE) as a gap for e.g. the vehicular UE to switch from receiving to transmitting or vice versa, and optionally some symbols at the end when feedback is required on the sidelink from the receiving vehicular UE, e.g., HARQ on feedback SCI “SCI_FB1” for short latency unicast carried in NR-PSSCH1 (whose AGC signal is not shown for simplicity of illustration).and one symbol for ACK / NACK feedback. This slot structure as an independent type may have data or signal exchange in both directions between one transmitting vehicle UE and one or more receiving vehicle UEs, for example. For SA SCI and data NR-PSSCH, the resource mapping may be frequency first, e.g., fill with resource elements (REs) along the frequency dimension of the first symbol, then fill with REs along the frequency dimension of the second symbol, etc. For example, SA SCI1 is filled with the first symbol of the control region, and SA SCI2 is filled with the second symbol of the control region. Similarly, NR-PSSCH1 and NR-PSSCH2 are mapped in frequency first. The 1-bit HARQ ACK / NACK carried in SCI_FB1 may be a sequence-based design.

[0331] For example, slot "SL2_1" of BWP2 may include the first two symbols (e.g., with a larger SCS or narrower symbols, two symbols as an example herein) for AGC, three symbols as an example as a control region for SA SCIs carried on the NR-PSCCH and its SL-DMRS (e.g., SCI3 for multicast on NR-PSSCH3 and SCI4 for broadcast on NR-PSSCH4 in the next slot "SL2_2"), and several symbols for data and / or reference signal (RS) transmission, such as SL-DMRS, SL-CSI-RS, SL-PTRS, SL-PRS, etc., e.g., a data transmission region. Since SA SCI4 indicates inter-slot resource allocation or scheduling, gaps and feedback symbols may not be required herein. Slot "SL2_2", carrying a reciprocal slot assignment or scheduled broadcast transmission on NR-PSSCH4 from the same transmitting vehicle UE, may start with several symbols for NR-PSSCH4, then with symbols for the gap and three symbols, as an example herein, for HARQ feedback from all or some of the receiving vehicle UEs of the multicast message on PSSCH3 in the previous slot "SL2_1".

[0332] The multiple bits of the HARQ ACK / NACK from all or a portion of the receiving vehicle UEs may be multiplexed over the same or different symbols, which may be UE-specific sequence-based or modulation symbol-based designs, and are mapped to a group of RBs over different symbols in time or groups of RBs in frequency according to a time-first or frequency-first mapping. For example, the multiple HARQ feedbacks from the receiving UEs may be mapped in frequency first, such as UE1 and UE2 feedbacks in the first symbol for feedback, and UE3 and UE4 feedbacks in the second symbol for feedback, etc. The time-first mapping is, for example, filling the first RBG or first RB with the first symbol in time, then filling the second RBG or second RB with the second symbol in time, etc. The time-first mapping is exemplified herein for SA SCI3 and SCI4, and PSSCH3 and PSSCH4.

[0333] To maintain orthogonality, all UEs that transmit HARQ ACK / NACK to the transmitting UE need to be synchronized at the receiver of the transmitting UE, e.g., the Timing Advance (TA) caused by the signal propagation delay in the air needs to be properly adjusted. This is a typical case for the many-to-one feedback design of multicast. Since multicast is a receiver UE aware communication, e.g., communication is within a group, and UEs need to discover neighboring groups and perform a procedure to join the group to become a member of the group. Timing advance information can be exchanged between UEs in the group. For neighboring group based multicasting, the signal propagation delay may not vary significantly between group members in a very small area, and all group members are mostly synchronized with a common synchronization source, so TA can be handled well within a small group.

[0334] As shown in FIG. 11, different communications, such as unicast, multicast, and broadcast, are assigned or scheduled on corresponding SA SCIs in the control domain.

[0335] The SA SCI may carry a source ID for broadcast, e.g., SL-BA-RNTI for the application, SL-BT-RNTI for the transmitter. The SA SCI may carry a group ID for multicast, e.g., SL-M-RNTI for multicast, SL-G-RNTI for the group or group lead. The SA SCI may carry a UE sidelink ID or pair ID for unicast, e.g., SL-C-RNTI-1 for the first UE, SL-C-RNTI-2 for the second UE, or SL-C-RNTI-p for the pair. With the appropriate ID, the UE may detect and decode the desired SA SCI for the transmitted data.

[0336] As an example, a 2-bit communication type indication, e.g., com_type, may be included in the SA SCI, e.g., "00" for broadcast, "01" for multicast, and "10" for unicast. Also as an example, a 1-bit flag, e.g., periodicity, may be included in the SA SCI (e.g., "0" for aperiodic or event triggered, "1" for periodic), and optionally a field for a period, e.g., "period", indicating the duration of data traffic for resource reservation.

[0337] The SL-DMRS of the NR-PSCCH carrying the SA SCI or the SL-DMRS of the NR-PSSCH carrying data may also include a source ID for broadcast, a source ID or group ID for multicast, and a UE sidelink ID or paired sidelink ID for unicast, which may be used by the UE to identify the desired NR-PSCCH or the desired NR-PSSCH. The UE may assume that the SL-DMRS of the NR-PSCCH is quasi-co-located (QCLed) with the selected NR-PSSS / NR-SSSS / NR-PSBCH during synchronization and / or group or peer discovery procedures, or with the SL-CSI-RS during beam training and pairing. The QCL or transmission configuration indication (TCI) of the NR-PSSCH may be indicated by its associated NR-PSCCH.

[0338] For example, the SL-DMRS for the NR PSCCH or NR-PSSCH may be constructed by a Gold sequence using the ID as follows:

[0339]

number

[0340]

number

[0341]

number

[0342]

number

[0343]

number

[0344]

number

[0345] The SL-DMRS port of the NR-PSCCH may be configured by a gNB or an RSU such as a gNB via RRC in the case of network control, or by the RSU as a proximity coordinator, proximity lead, group lead, synchronization source UE, or scheduling UE during group discovery and group join or peer discovery and pairing procedure or association or connection procedure via SL-RRC in the case of no network control.

[0346] The SL-DMRS port of the NR-PSSCH may be signaled in the DCI by a gNB or a gNB-like RSU in the case of network control, or may be configured or signaled in the SCI by the RSU as a proximity coordinator, proximity lead, group lead, or synchronization source UE during group discovery and group join or peer discovery and pairing procedure in the case of no network control.

[0347] An example shown in Figure 11 is a control region for SA SCI and a data transmission region for data and / or RS in PDSCH. Different resource pools may be configured for the control region and the data transmission region, respectively (e.g., one or more resource pools for control and one or more resource pools for data).

[0348] FIG. 12 shows an example of aggregated slot scheduling in the sidelink, where the broadcast transmission in the PSSCH spans the slot boundary between slots SL1 and SL2, e.g., the data transmission region spans the slot boundary.

[0349] FIG. 13 shows an example of SL-CSI-RS acquisition, which may be configured by the gNB via RRC, or by the RSU, lead, or scheduling UE via SL-RRC, with multi-beam (spatial multiplexing) based sweeping, which may also be indicated by the SA SCI in slot SL1, e.g., SL-CSI-RS request indication in the SA SCI, and SL-CSI feedback (e.g., sidelink CSI report) in slot SL2, dynamically indicated by the transmitting UE via the SA SCI in slot SL1. Wide beam transmission for SL-CSI-RS may be indicated by the SA SCI in the control region of slot SL1 as an example for multicast area coverage. However, narrow multi-beam sweeping may also be applied to SL-CSI-RS in the data region shown in FIG. 13.

[0350] Narrow multi-beam sweeping for one-to-many SL-CSI-RS transmission (similar to multicast data in NR-PSSCH) is implemented over four symbols in the data domain as an example for multicast coverage. Also, CSI feedback in slot SL2 from all UEs or a portion of UEs in a group is exemplified by multiplexing on different symbols in time (e.g., TDMed), multiplexing on different RBs / RBGs / subchannels in frequency (e.g., FDMed), and / or multiplexing on different beams in space (e.g., spatial multiplexing or space division multiplexing (SDMed) on beams A, B, and C as shown in FIG. 13 at feedback position CSIFB1). The example shown in FIG. 13 has a multiplexing of 4×2×3=24 SL-CSI feedback for SL-CSI reports carried on modulation based feedback channels, e.g., feedback SCI carried on a new physical sidelink feedback channel or multiplexed on NR-PSSCH or carried on NR-PSSCH specially mapped at higher layers.

[0351] If UE-specific sequence-based spreading is applied to the CSI feedback resources (in either the time domain, the frequency domain, or both), the feedback of more UEs may be multiplexed via different codes, e.g., Code Division Multiplexed (CDMed), at the cost of more resources in time or frequency.

[0352] Since SL-CSI feedback is used to report sidelink radio channel conditions, it may be redundant to report channel conditions measured by beam pairs with quasi-co-located (QCLed) Type-A relationships, e.g., Doppler shift, Doppler spread, average delay, delay spread, etc. Thus, UEs in a group in a small area may have a QCL Type-A relationship with a QCL Type-A beam. In this scenario, only one UE of a QCL Type-A UE subgroup needs to feedback SL-CSI reports to further reduce the overhead of many-to-one CSI feedback.

[0353] The proposed mechanism for multicast CSI feedback is also applicable to multicast HARQ ACK / NACK implementations, either sequence-based or modulation-based.

[0354] Figure 14 shows minislot-based scheduling, where the NR-PSCCH carrying the SA SCI is adjacent to the NR-PSSCH carrying data in time, and thus the NR-PSCCH and NR-PSSCH share the same resource pool used for data and / or RS, such as SL-DMRS, SL-CSI-RS, SL-TPRS, SL-PRS, etc. In addition, for narrow beam-based sweeping, the PSCCH and PSSCH may be carried on the same beam.

[0355] As shown in FIG. 14, SA SCI1 indicates a small low latency and high reliability periodic data transmission carried on NR-PSSCH1 via a 2 symbol minislot repeated once and with a duration of 1 slot, SA SCI2 indicates medium size low latency periodic data carried on NR-PSSCH2 via 6 symbol minislots with a duration of 1 slot, SA SCI3 indicates medium size low latency event triggered data carried on NR-PSSCH3 via 6 symbol minislots, and SA SCI4 indicates a very small periodic data transmission carried on NR-PSSCH4 via 2 symbol minislots with a duration of i slots (where i>1).

[0356] For periodic transmissions, especially for frequent periodic transmissions, the receiver may have the AGC set appropriately and may not require an AGC signal for prerequisites of the receiver AGC circuit settings.

[0357] For event triggered transmission, an AGC signal may be required for preconditioning of receiver AGC circuit settings.

[0358] An example of resource allocation or scheduling for unicast is shown in Figure 15. Unicast can be initiated by a receiving UE using the SA SCI as shown in Figure 15A, or by a transmitting UE as shown in Figure 15B.

[0359] As shown in FIG. 15A, the receiving UE may initiate a unicast by sending a SA SCI to request or reserve a data transmission or to elicit data.

[0360] In BWP1, a data request or reserved SA SCI (e.g., SCI1 r) optionally with an AGC signal (e.g., AGC r) from the receiving UE is assigned in the control field of the first slot (e.g., SL1), and then data is transmitted in the second slot (e.g., SL2), e.g., on NR-PSSCH1 with an optional AGC signal (e.g., AGC t) and an optional SCI (e.g., SCI1 t) associated with the data for decoding. The receiving UE's HARQ ACK feedback may be at the end of slot SL2 or in slot 3, which may be indicated by the first SA SCI (e.g., SCI1 r).

[0361] In BWP2, a data request or reserved SA SCI (e.g., SCI2 r) with an optional AGC signal (e.g., AGC r) from the receiving UE is assigned in the control field of the first slot (e.g., SL1), and data is transmitted in the same slot, e.g., NR-PSSCH2 with an optional AGC signal (e.g., AGC t) and an optional SCI (e.g., SCI2 t) associated with the data for decoding. The HARQ NACK feedback of the receiving UE may be at the beginning of the second slot (e.g., SL2), and the retransmission in NR-PSSCH2 is in the same slot (e.g., SL2) that may also be indicated by the SA SCI (e.g., SCI2 r). This is an example of resource allocation or scheduling for low latency short data transmission.

[0362] As shown in FIG. 15B, the transmitting UE may initiate unicast by sending a request SCI for resource allocation or scheduling of data transmission.

[0363] In BWP1, a resource allocation or scheduling request SCI (e.g., SCI1 t) from a transmitting UE is assigned in the feedback field of a first slot (e.g., SL1), an SA SCI (e.g., SCI1 r) is transmitted in the control field of a second slot (e.g., SL2), and then data is transmitted in the same slot, e.g., on NR-PSSCH1, optionally with an SA SCI (e.g., SCI2 t) for decoding the associated data. A HARQ ACK feedback of a receiving UE is assigned in slot 3.

[0364] In BWP2, a data request SCI (e.g., SCI2t) optionally having an AGC signal (e.g., AGCt) from a transmitting UE is assigned in the first minislot of a first slot (e.g., SL1), a SA SCI (e.g., SCI2r) is transmitted in the fourth minislot of a first slot (e.g., SL1), and then data is transmitted in the first minislot of a second slot (e.g., SL2), e.g., on NR-PSSCH2, optionally having an SCI (e.g., SCI3t) for decoding the data. A HARQ ACK feedback of the receiving UE is assigned in the fourth minislot of the second slot. This is an example of resource allocation or scheduling for low latency short data transmission in a minislot.

[0365] (Sensing for periodic and aperiodic transmissions) An exemplary scheme of sensing for periodic and aperiodic data transmissions over a shared resource pool is shown in FIG. 16, which may have the following steps.

[0366] In step 1, the UE checks whether the planned data transmission is periodic or aperiodic, e.g., indicated by the higher layer parameter periodic, "1" for periodic and "0" for aperiodic, and whether the higher layer parameter period for the time interval of the periodicity is "1". If aperiodic, proceed to step 2A, otherwise proceed to step 2B for periodic data transmission.

[0367] In step 2A, the UE sets a sensing window size, e.g., window-size, based on a maximum time resource (e.g., max-transmission-time) for a typical or maximum Transport Block (TB) size for the V2X application, a repetition number (e.g., repetition_enable is “1” otherwise “0”) if it is enabled (e.g., repetition_enable is “1”, “0” otherwise), a possible retransmission time line (e.g., delay-retransmission), etc. For example, the window size may be estimated as follows: window-size=max-transmission-time+(repetition-number×max-transmission-time)×repetition_enable+(delay-retransmission+max.transmission-time)+window-adjustment Here, the window-adjustment is an additional time adjustment to the sensing window based on different QoS requirements, such as latency, priority, reliability, etc., for different nearby V2X services.

[0368] In step 2B, the UE sets a sensing window size, e.g., window-size, based on a maximum time resource for a typical or maximum transport block (TB) size for the V2X application, the number of repetitions if it is enabled, the possible retransmission time line, the period (e.g., period) for periodic transmission, the periodic transmission to ensure (e.g., trans-count), etc. For example, the window size may be estimated as follows: window-size=max.transmission-time+repetition-number×max.transmission-time(if enabled)+delay-for-retransmission+max.transmission-time+period×trans-count+window-adjustment Here, the window-adjustment is an additional time adjustment to the sensing window based on different QoS requirements, such as latency, priority, reliability, etc., for different nearby V2X services.

[0369] Compared with the aperiodic window size, the periodic sensing window size is much larger when the UE needs to conserve resources for the next few transmissions of periodic messages, e.g., trans-count. The longer the period, the larger the window size.

[0370] In step 3 for resource sensing, the UE senses the resources used and / or the resources reserved in the sensing window. There are several ways to implement the sensing mechanism.

[0371] If all SA SCIs within the sensing window can be decoded by the UE, the UE can extract the exact resources used and the resources reserved within the time of the sensing window. Thus, the UE can select the set of available resources required by its data transmission, which may be periodic or aperiodic (e.g., event-triggered).

[0372] If not all SA SCIs are decodable to the UE, e.g., the SCIs are scrambled with an ID, e.g., SL-BA-RNTI as a broadcast source ID for the V2X application, SL-BT-RNTI as a source ID for the broadcast transmitter, SL-M-RNTI as a multicast ID, SL-G-RNTI as a sidelink ID for the group or group lead, SL-C-RNTI for the sidelink ID of the UE, etc., or if the resources have already been scheduled or reserved by other UEs via the SA SCI, the UE may detect resource usage by measurements. For example, the Sidelink Reference Signal Received Power (SL-RSRP) or Sidelink Reference Signal Received Quality (SL-RSRQ) is measured from the SL-DMRS of the NR-PSCCH or NR-PSSCH. If the measured result exceeds a threshold configured by higher layers, e.g., Sense_Th SL-RSRP or Sense_Th SL-RSRQIf the resource used indicates a repeating pattern, the UE may assume that the pattern will continue the periodic transmission for a certain length of time in the near future, e.g., the patterned resource is reserved for the periodic transmission. Another method for measuring is an energy-based measurement on the NR-PSCCH and / or NR-PSSCH, e.g., a sidelink received signal strength indicator (SL-RSSI). To reflect resource usage in frequency, measurements for SL-RSRP, SL-RSRQ, or SL-RSSI may be based on a specific frequency unit, such as per RB, per RBG, or per subchannel, which may be configured via RRC or Sl-RRC. Similarly, for more precise usage in time, measurements for SL-RSRP, SL-RSRQ, or SL-RSSI may be based on a specific time unit, such as per symbol, per minislot, or per slot, which may also be configured via RRC or Sl-RRC. The energy-based measurements of NR-PSCCH or NR-PSCH may be combined with the SL-RSRP or SL-RSRQ of NR-PSCCH, or the SL-DMRS of NR-PSSCH, to improve the measured accuracy.

[0373] Another method is to combine results from the decoded SA-SCI, NR-PSCCH and / or NR-PSSCH SL-RSRP or SL-RSRQ measurements, and / or NR-PSCCH and / or NR-PSSCH energy measurements SL-RSSI, or a combination thereof.

[0374] The UE may maintain sensing of resources used and / or reserved in its sensing window and may maintain an update of the set of available resources for its upcoming aperiodic or periodic transmissions in a sensing window that slides over time.

[0375] In step 4, if higher layers indicate that new data is ready for transmission, e.g., a trigger to transmit new data, proceed to step 5, otherwise proceed to step 3 for sensing available resources.

[0376] In step 5 for resource selection, the UE selects a subset of resources from the set of available resources as candidate resources based on TB size, latency requirement, priority level, periodic or non-periodic (e.g., event triggered), channel congestion, etc. for the new data to be transmitted. Higher layers may select the resources to be used from the candidate resources. The UE may reserve the selected resources for its transmission or use the selected resources at least for the initial transmission without reservation to avoid reservation delays. For shared resource pools or resources, the UE may perform resource-sensing access before transmitting its data on the selected resources to avoid possible collisions with other UEs' transmissions on the same selected resources, e.g., using Listen-Before-Talk (LBT) based on a very short measurement window for energy-based SL-RSSI measurements. If the measurement value is less than a threshold, e.g., Measure_TH LBT If the resource is above T, the UE may assume that the resource is being used by another UE, and then the UE may LBT_offThe UE may back off with and resensing the access resource for that transmission. Whether access resource sensing is enabled for the data being transmitted, e.g., Acc_Reseource_En is 1 or 0, may be indicated to the UE by higher layers. For example, for very short latency transmissions or very high priority transmissions, access resource sensing may be disabled to save time, and for latency tolerant or low priority transmissions, access resource sensing may be enabled to avoid collisions with short latency or high priority transmissions. Another method for determining whether to sense access resources without an explicit indication (e.g., Acc_Resource_En) is based on latency budget (e.g., the time is very close to the transmission latency budget of the data and there is no time for sensing or the latency requirement is above a threshold for sensing) or based on priority level (e.g., the priority is above a priority threshold for sensing).

[0377] In step 6, the UE checks whether the maximum number of LBT-based access resource sensing (e.g., max-LBT) is reached or whether the maximum LBT timer for LBT-based access resource sensing (e.g., time-LBT) is timed out. If the UE reaches the maximum number of LBT-based access resource sensing or the UE is timed out for LBT-based access resource sensing, proceed to step 7 for preemption decision, otherwise proceed to step 8 to perform LBT-based access resource sensing over the selected resource for that transmission. If max-LBT=0 or time-LBT=0, the UE does not need to perform access resource sensing (e.g., another method to disable access resource sensing).

[0378] In step 7, the UE checks from higher layers whether preemption is enabled for higher priority transmissions (e.g., parameter pre-emption is "1"), or checks a priority level from higher layers that allows it to preempt other lower priority data traffic (e.g., parameter priority), or checks a latency requirement from higher layers that allows preemption to avoid delays (e.g., parameters latency_allowed or latency_max). The UE may then determine whether it can preempt resources scheduled or reserved by other UEs with higher latency, lower priority, or lower reliability for its high priority or low latency transmissions. The UE may also check the SL-RSRP, SL-RSRQ, or SL-RSSI to determine whether resources scheduled or reserved by other UEs can be preempted for its transmissions. If the UE can, as an example, preempt other UEs' scheduled or reserved resources for its urgent data transmission, it proceeds to step 13 for preemption transmission, otherwise it proceeds to step 17 for dropping the transmission with error reporting in case of outside latency budget, or proceeds to step 5 (not shown) to reselect candidate resources from the available resource set. The UE may explicitly indicate that the selected resources are preempted from other UEs' resources in its SA SCI or SCIs associated with its data transmission, e.g., pre-empted=1, or may imply preemption in its SA SCI or SCIs associated with its data transmission using a reserved priority value for the 3-bit priority field in the SCI, e.g., priority="111" or "000".

[0379] In step 8, the UE performs access resource sensing, eg, LBT-based sensing, over the selected resource to access the resource.

[0380] For different V2X services with different QoS requirements, LBT-based access resource sensing can be implemented in multiple ways, such as priority-based (e.g., higher priority, lower backoff, or no backoff time), adaptive-based (e.g., decreasing the backoff time each time an LBT fails), random-based (e.g., by randomly selecting a value within the backoff range), transmitter / receiver handshaking-based (e.g., to avoid hidden nodes), etc.

[0381] In step 9, if resources are sensed as available over the selected resource, proceed to step 12 to transmit data, otherwise proceed to step 10 for backoff.

[0382] In step 10, the UE may wait a backoff time, which may be randomly generated or priority-based, or may decrease each time the UE fails LBT-based resource sensing, where the backoff parameters of different backoff schemes may be configured and indicated by higher layers.

[0383] In step 11, the UE checks whether the back-off time expires. If so, it goes to step 6 to check whether it is timed out, and then in step 8, if it is not timed out, it performs LBT-based resource sensing again; otherwise, it continues to wait in step 10.

[0384] In step 12, the UE reserves the selected resources for the transmission or accesses the selected resources for the transmission of data, and may additionally reserve resources for aperiodic V2X messages (e.g., event-triggered messages) for repetition if enabled and retransmission if enabled, or for periodic V2X messages for repetition if enabled, retransmission if enabled and some new transmissions (e.g., as defined by the trans-count).

[0385] If the data transmission is periodic, the periodic transmission counter is decremented by 1 after a successful transmission (eg, trans-count=trans-count-1).

[0386] In step 13 for preemption transmission, the UE may select a reserved resource to be preempted based on TB size, latency requirement, priority level, periodic or event trigger, impact on the preempted UE, interference, congestion, etc., and transmit data via the preempted resource. The UE must broadcast a preemption indication (e.g., with a new format SCI for preemption notification, or with a preemption flag set "1" in the SA SCI, or with a saved priority value "111" or "000" in the SA SCI) on the reserved resource of the other preempted UE, or include the preemption in the SCI sent together with the data transmission to the receiver. The data transmission via the preempted resource may be LBT sensed based depending on the urgency and priority of the data to be transmitted.

[0387] In step 14, the UE checks whether there are any reserved transmissions, e.g., repeats, retransmissions, or new transmissions for periodic data, and if not, proceeds to step 18 to stop sensing or to step 1 to start sensing again depending on the operating mode indicated by higher layers (not shown), otherwise proceeds to step 15 to check whether the reserved resources are to be preempted.

[0388] In step 15, the UE checks whether there are any preemption indications broadcast by the UE that preempted the reserved resources in case of preemption monitoring as configured via RRC or Slk-RRC (e.g., in case of preemption monitoring or in case of scheduling monitoring, if there is no preemption indication, e.g., indicated by SCI, the UE proceeds to step 16 to check whether any reservation has been made, if not, with the reserved resources preempted, the UE proceeds to step 3 to resensing available resources in its sensing window. If the UE is enabled with preemption for high priority data, the UE may jump to step 7 for a new transmission using preemption as described for step 7 (not shown in FIG. 16).

[0389] In step 16, the UE checks whether the trans-count is above a threshold specified by higher layers for periodic data transmission on reserved resources or checks whether it is a repeat or retransmission on reserved resources. If it is not a reserved resource for a new periodic transmission or a repeat or retransmission, it goes to step 3 for window-based sensing to find candidate resources again, otherwise it goes to step 4 for a repeat, retransmission, or new data for periodic data transmission on reserved resources.

[0390] In step 17, the UE drops the transmission and reports a resource access error to higher layers, and then proceeds to step 18 or returns to step 5 to reselect candidate resources (not shown) or to step 3 to sense again (not shown).

[0391] At step 18, the sensing procedure may be terminated.

[0392] (resource selection and reselection) 26A, 26B, and 26C, the UE may perform channel sensing with a long time interval "sensing window 1" (e.g., having a length of X1 slots or X1 milliseconds) and a short time interval "sensing window 2" (e.g., having a length of X2 slots or X2 symbols, or X2 milliseconds). The UE may select resources for data transmission in a "selection window" of time interval (e.g., having a length of Y slots, or Y milliseconds).

[0393] An SA SCI (e.g., SCI1 in slot i) indicating resource reservation for an initial transmission (e.g., TB1 in slot i+1), a blind retransmission (e.g., a repetition for TB1 in slot i+2), and a new transmission for periodic traffic (e.g., for TB2) is shown in FIG. 26A.

[0394] An SCI (e.g., SCI1 for the initial transmission in slot i) that indicates resource reservation for an initial transmission (e.g., for TB1), a HARQ retransmission (e.g., a retransmission for TB1 in slot i+2), and HARQ feedback for a new transmission (e.g., for TB2) for periodic traffic (e.g., SFCI1 in slot i+1) is shown in FIG. 26B.

[0395] An SCI (e.g., SCI1 in an initial transmission in slot i) that is shown with resource reservation for blind retransmission (e.g., repetition for TB1 in slot i+1) is shown in FIG. 26C for low latency aperiodic traffic, e.g., event-triggered transmission.

[0396] As shown in FIG. 27, the UE may perform the following steps to select resources for transmitting data, e.g., a transport block (TB).

[0397] In step 1 (long sensing for available resources), the UE may sense available resources within the long sensing window by decoding the scheduling or resource reservation SCI carried in the NR-PSCCH and measuring the sidelink reference signal received power (SL-RSRP), such as the SL-RSRP of the PSCCH DMRS and / or the SL-RSRP of the PSSCH, over the scheduled or reserved resources. Resources that satisfy the following conditions may be excluded: Resources indicated by another UE in a Scheduling SCI or a Reserved SCI. These resources are allocated at the same time that the UE needs them to transmit any of its next data TBs. The resource is preempted by another UE with the preemption indicated in the SCI. The UE measures the average SL-RSRP of the DMRS of the NR-PSCCH and / or the NR-PSSCH over a subchannel or RB or a physical resource block (PRB) utilized for transmitting a TB associated with the scheduling SCI or the reserved SCI or the preemption SCI, and the measurement value is within a given threshold M th (e.g., cannot share the same resources, collision reduction).

[0398] In step 2 (Data Available), determine if new data TB is ready at time T0 for transmission from higher layers. If yes, go to step 3 to set the selection window, if not, go to step 1 to continue long sensing.

[0399] In step 3 (selection window), a selection window is set based on QoS requirements such as latency, priority, reliability, and duration for periodic traffic. The end of the selection window may be dictated by the maximum latency requirement for data TB transmission.

[0400] In step 4 (short sensing on candidate resources), sense available candidate resources within a short sensing window with finer granularity, especially for short latency data traffic. The measurements can be SL-RSRP of NR-PSCCH DMRS and / or NR-PSSCH DMRS, or sidelink received signal strength indicator (SL-RSSI) as an energy-based measurement. For very short latency resource selection, this short sensing can be similar to access resource sensing, e.g., listen-before-talk (LBT) based. The candidate resources can be single-slot resources, such as Candidate Single-Slot Resources (CSSR), or multiple symbol (e.g., one or more) resources, such as Candidate Multi-Symbol Resources (CMSR). Resources can consist of 1 to S adjacent subchannels or RBs or RBGs in a slot depending on the message size. The UE can select a set of CSSRs or CMSRs within a selection window spanning a number of slots or symbols, e.g., X2 slots or symbols.

[0401] In step 5 (threshold measurement), an initial threshold M Th Set the M Th The value of may be configured by higher layers based on QoS requirements such as priority, latency, reliability, coverage or zone, interference measurements, e.g., Sidelink SINR (SL-SINR), congestion measurements, etc.

[0402] In step 6 (initial candidate resource list), an initial available candidate resource list R is set with all available CSSRs or CMSRs from sensing. Resources that are not monitored by the UE in the sensing window are not included in list R.

[0403] In step 7 (measurement), measurements are made over the candidate resources, e.g., CSSR or CMSR of R. The measurements may be SL-RSSI or SL-RSRP or SL-SINR of NR-PSCCH and / or NR-PSSCH over the candidate resources.

[0404] In step 8 (update candidate resource list), the threshold M Th update the candidate resource list R by removing CSSRs or CMSRs with measured SL-RSSI or SL-RSRP or SL-SINR values ​​exceeding

[0405] In step 9 (Is R enough left?), check if the candidate resources left in list R are more than p% of the total resources, where p is configured by higher layers based on QoS requirements such as priority, latency, reliability, coverage or zone, etc., as well as interference and congestion levels. If yes, go to step 12 to measure for reporting, if not, go to step 10 to adjust the measurement threshold.

[0406] In step 10 (increasing the threshold), Th Inc dB (e.g., M Th =M Th +Th Inc ) to increase the threshold. Here, Th Inc is configured by higher layers based on QoS requirements such as priority, latency, reliability, communication range or zone, etc., as well as interference and congestion levels. Returning to step 11, it is checked whether the candidate resource list R needs to be reconfigured with the CSSR or CMSR collected from sensing.

[0407] In step 11 (Reconfigure R?), check whether to reset the candidate resource set R. If yes, go to step 6 to reset the candidate resource list with CSSR or CMSR collected from sensing, otherwise go to step 8 to update the candidate resource list with the adjusted threshold.

[0408] In step 12 (Measurement), perform measurements over the updated candidate resources of R and report to higher layers. The measurements can be a linear average of SL-RSSI or SL-RSRP or SL-SINR of NR-PSCCH and / or NR-PSSCH over CSSR or CMSR of R. Select the CSSR or CMSR with the minimum average of S-RSSI or SL-RSRP or SL-SINR and report them to higher layers.

[0409] In step 14 (selection), the higher layer selects resources from the reported candidate resources CSSR or CMSR based on QoS requirements such as TB size, priority, latency, reliability, coverage or zone, and interference, congestion measurements, or randomly selects candidate resources for the initial transmission. If blind retransmission (e.g., repetition) is enabled, the candidate resource (e.g., starting symbol) corresponding to the blind retransmission instance may also be selected. If HARQ feedback is enabled, the candidate resource corresponding to the HARQ feedback instance may also be selected, e.g., starting symbol for sidelink feedback control information (SFCI) based on the HARQ processing time line. For the number of HARQ processes h, the candidate resource corresponding to the HARQ retransmission may also be selected, e.g., for the set of selected initial transmission opportunities T0+T k (k=0,1,..,K is the index of the TB), and another set of HARQ retransmission opportunities T0+T k +T h where T h ≠0, and T h≦x, where x is based on the HARQ processing time budget of the UE. For Semi-Persistent Scheduling (SPS), e.g., for periodic transmission, the candidate resources corresponding to the next packet transmission are defined, e.g., by a Resource Counter (RC), where RC may be selected randomly within a range configured by higher layers, or may be selected based on priority, period, latency, communication range or zone, packet size, blind retransmission, HARQ retransmission, interference, congestion level, etc.

[0410] (Congestion Control) For sidelink congestion control, the UE may reserve resources or estimate a New Radio Channel Busy Ratio (NR-CBR) and a New Radio Channel occupancy Ratio (NR-CR) before transmitting or retransmitting a packet. The NR-CBR may provide an indication of the channel congestion level, and the CBR threshold M CBR The previous S CBR It may be calculated as the amount of subchannels or PRBs in a slot. NR-CR indicates the channel occupancy achieved by the transmitting UE. It is the amount of subchannels or PRBs that the transmitting UE can occupy in S CB This time interval can be calculated as the amount of subchannels or PRBs to occupy during the duration of a slot. This time interval is calculated based on the past and future S x The NR-CBR and NR-CB intervals may include 100 Mbps, 100 Mbps, and 200 Mbps slots. The NR-CBR and NR-CB intervals are illustrated in Figure 28. The NR-CBR and NR-CB intervals may be configured separately by higher layers for different QoS requirements, such as latency, priority, reliability, coverage or zone, and the like, as well as traffic characteristics and congestion levels within the system.

[0411] For congestion control, the channel occupancy threshold CR thA CR may be defined for the UE to manage its resource reservation and transmission. For different QoS requirements, different CRs may be defined. th The thresholds can be configured or signaled by higher layers. For example, priority, latency, reliability, communication range or zone, etc., can affect the CR for data packets. th The transmitting UE may use the Inter CBR The CBR interval may be configured or signaled by higher layers, and for each CBR interval, the transmitting UE may transmit at a maximum CR at a particular CBR level. th The CR for each CBR interval cannot exceed th The value of may vary depending on the QoS requirements of the packet, such as priority, latency, reliability, range or zone, etc.

[0412] When a transmitting UE reserves resources for a blind retransmission or HARQ retransmission, it measures the NR-CBR and calculates the NR-CR based on the CR th The UE checks whether the requirements are met and, as a result, th , the resources for retransmission can be adequately reserved without exceeding .

[0413] When the UE transmits or retransmits a packet, it measures the NR-CBR and determines whether the NR-CR is greater than or equal to the CR th Check whether the requirements are met. th If the value is higher than , it will be decided to set the CR to CR based on the UE's capabilities, data packet size, and data packet QoS requirements such as reliability, latency, priority, communication range or zone, etc., in the following example: th Can be reduced to less than: Dropping transmissions, i.e., the UE may reduce its NR-CR by dropping certain data packet transmissions based on its QoS requirements, such as priority, latency, reliability, coverage or zone, etc. For example, dropping data packet transmissions with low priority or long latency or low reliability, or outside the required coverage or zone. Reduce the number of retransmissions: A UE may reduce its CR by reducing blind or HARQ retransmissions of packets with low priority or low reliability or long latency requirements. Adjust the Modulation and Coding Scheme (MCS), i.e., the UE may reduce the CR by adjusting the MCS. For example, the UE may increase the MCS of a data packet to save subchannels or PRBs and / or symbols used for transmission; and / or Reduce Transmit Power (TP), i.e. the UE reduces its transmit power per minimum range requirement to lower all NR-CBR measurements and therefore its CR th The requirements can be met.

[0414] Similarly, the receiving UE may receive NR-CBR and / or CR th Based on the requirements, it may decide to drop the HARQ feedback or the CSI report. For example, the receiver UE may drop the NACK feedback for the HARQ ACK / NACK feedback, and the receiver UE may drop the CSI report when the channel variation is low.

[0415] An example of congestion control is shown in FIG. 29, which includes the following steps.

[0416] In step 1 (NR-CBR / NR-CR measurement), the SL-RSRP or SL-RSSI of the NR-PSCCH and / or NR-PSSCH is measured over resources during resource sensing and / or selection.

[0417] In step 2 (Data Available?), if a new data packet is available, go to step 3 to check its CRth requirement, otherwise go to step 1 to continue NR-CBR / NR-CR measurement.

[0418] Step 3 (CRth ?) and the measured CR is the maximum CR th If it is, proceed to step 4A for reduced resource reservation, otherwise proceed to step 4B for normal resource reservation.

[0419] In step 4A (reduced resource reservation), reduce resource reservation for transmission and / or retransmission, e.g., by increasing MCS, and reducing the number of blind retransmissions and / or HARQ retransmissions based on QoS requirements such as priority, latency, reliability, coverage or zone, and data packet size and current congestion level.

[0420] In step 4B (normal resource reservation), resources are reserved based on QoS requirements such as priority, latency, reliability, communication range or zone, and data packet size.

[0421] Step 5 (CR th (Exceeds CRth?) to check if CRth is exceeded before transmission or retransmission. If yes, go to step 6 for dropping the transmission, else go to step 8 for transmission or retransmission.

[0422] In step 6 (Drop transmission?), check if dropping the transmission or retransmission is allowed. If yes, go to step 7A for congestion control with dropping, if not, go to step 7B for congestion control without dropping.

[0423] In step 7A (congestion control with dropping), it is decided to drop the transmission. Go to step 9.

[0424] In step 7B (congestion controlled transmission without drops), adjustments such as increasing MCS and decreasing TP are made.

[0425] In step 8 (transmission), the data packet is transmitted or retransmitted with the adjusted MCS and / or TP.

[0426] In step 9 (Reselect resources?) it is checked whether previously reserved resources need to be cancelled and reselected for retransmissions or periodic transmissions. If yes, reset the reselection counter CR and go to step 1.

[0427] For mode 1, the gNB may request each UE periodically (e.g., the gNB determines the period) or upon request to report its measured CBR to sidelink congestion control.

[0428] 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 instructions, when executed by a processor, such as processor 118 or 91, cause the processor to perform and / or implement the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions and executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile media, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, although 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 memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other tangible or physical medium that may be used to store the desired information and that can be accessed by a computing system.

[0429] Below is a list of acronyms related to service layer technologies that may appear in the description above. Unless otherwise specified, the acronyms used herein refer to the corresponding terms listed below. ACK:ACKnowledgement BSM: Basic Safety Message CAM: Common Awareness Messages CE: Control Element DFN: Direct Frame Number EtrA: Emergency Trajectory Alignment HARQ: Hybrid Automatic Repeat Request LoA: Level of Automation LTE: Long Term Evolution MAC: Medium Access Control MIB: Master Information Block NACK: Negative ACKnowledgement NR:New Radio PLMN: Public Land Mobile Network NR-PSCCH: NR Physical Sidelink Control Channel NR-PSDCH: NR Physical Sidelink Discovery Channel NR-PSSCH: NR Physical Sidelink Shared Channel NR-PSSS: NR Primary Sidelink Synchronization Signal RAN: Radio Access Network RNTI: Radio Network Temporary Identifier RRC: Radio Resource Control SA: Sensing Assistant SCI: Sidelink Control Information SI: System Information NR-SSSS: Secondary Sidelink Synchronization Signal UE: User Equipment V2V: Vehicle-to-Vehicle V2X: Vehicle-to-everything

Claims

1. Receiving a configuration associated with a resource pool located in a sidelink bandwidth part; determining resource usage in the resource pool and one or more available resources by measuring a Sidelink Reference Signal Received Power (SL-RSRP); selecting one or more resources from the one or more available resources in the resource pool for one or more transmissions; transmitting data packets by transmission of a sidelink shared channel and by transmission of control information by transmission of a sidelink control channel using the selected resource or resources, wherein the sidelink shared channel and the sidelink control channel overlap in time and do not overlap in frequency; A method comprising:

2. Determining the one or more available resources in the resource pool includes setting a time interval for a sensing window, the time interval for the sensing window comprising: Periodic or aperiodic transmission, a latency requirement for said data packets; repetition for transmission of said data packets; and configured based on at least one of the retransmissions of the data packet per Hybrid Automatic Repeat Request (HARQ) feedback. The method of claim 1.

3. Determining the one or more available resources in the resource pool includes: sensing resource usage by decoding Sidelink Control Information (SCI) to schedule an initial transmission, preempt scheduled or reserved resources, or reserve at least one of one or more repetitions or one or more retransmissions per Hybrid Automatic Repeat Request (HARQ) feedback; Measuring at least one of a Sidelink Received Signal Strength Indicator (SL-RSSI), a channel busy rate, or a channel occupancy rate; and Resources that are not scheduled, reserved, and preempted; Resources that are within range or zone, or based on a determination that at least one of the SL-RSRP measurement of the resource or the SL-RSSI measurement of the resource is less than a threshold; Determining available resources The method of claim 1 , comprising at least one of:

4. Selecting the one or more resources includes determining a time interval for resource selection, the time interval for resource selection comprising: one or more of the priority, latency, or reliability of the data packets being transmitted; and Repeated, retransmission per Hybrid Automatic Repeat Request (HARQ) feedback, or next data packet transmission for periodic traffic The method of claim 1 , wherein the at least one of the following is determined based on at least one of the following:

5. Selecting the one or more resources comprises: selecting one or more resources based on at least one of a priority, a latency, a reliability, or a communication range or zone of the data packet to be transmitted, or an interference or congestion measurement; and Selecting one or more resources for at least one of a scheduling or reserved SCI, an initial transmission, a repetition, a Hybrid Automatic Repeat Request (HARQ) feedback, a retransmission per HARQ feedback, or a next data packet of periodic traffic. The method of claim 1 , comprising at least one of:

6. Transmitting the data packet includes: determining whether a congestion threshold has been exceeded based on the measured congestion level, the congestion threshold being based on at least one of a priority, a latency, a reliability, or a communication range or zone of the data packets being transmitted; Based on a determination that the congestion threshold has not been exceeded, transmitting the data packet; and Based on a determination that the congestion threshold has been exceeded, Dropping the transmission based at least on the congestion level or at least one of the priority, latency, reliability, or range of the data packets being transmitted; or adjusting a modulation and coding scheme or a transmission power level based on at least one of the congestion level or the priority, latency, reliability, or range of the data packet being transmitted, and sending at least one of an initial transmission, a repeat, or a retransmission of the data packet. and performing at least one of The method of claim 1 , comprising:

7. An apparatus comprising a processor and a memory, the memory storing computer-executable instructions that, when executed by the processor, cause the apparatus to perform operations, the operations being: receiving a configuration associated with a resource pool located in the sidelink bandwidth part; determining resource usage in the resource pool and one or more available resources by measuring a Sidelink Reference Signal Received Power (SL-RSRP); selecting one or more resources from the one or more available resources in the resource pool for one or more transmissions; transmitting data packets by transmission of a sidelink shared channel and by transmission of control information by transmission of a sidelink control channel using the selected resource or resources, wherein the sidelink shared channel and the sidelink control channel overlap in time and do not overlap in frequency; 13. An apparatus comprising:

8. Determining the one or more available resources in the resource pool includes setting a time interval for a sensing window, the time interval for the sensing window comprising: Periodic or aperiodic transmission, a latency requirement for said data packets; repetition for transmission of said data packets; and Retransmission of said data packet per Hybrid Automatic Repeat Request (HARQ) feedback The apparatus of claim 7, wherein the at least one of the following is set:

9. Determining the one or more available resources in the resource pool includes: sensing resource usage by decoding Sidelink Control Information (SCI) to schedule an initial transmission, preempt scheduled or reserved resources, or reserve at least one of one or more repetitions or one or more retransmissions per Hybrid Automatic Repeat Request (HARQ) feedback; Measuring at least one of a Sidelink Received Signal Strength Indicator (SL-RSSI), a channel busy rate, or a channel occupancy rate; and Resources that are not scheduled, reserved, and preempted; Resources that are within range or zone, or based on a determination that at least one of the SL-RSRP measurement of the resource or the SL-RSSI measurement of the resource is less than a threshold; Determining available resources The apparatus of claim 7 , comprising at least one of:

10. Selecting the one or more resources includes determining a time interval for resource selection, the time interval for resource selection comprising: one or more of the priority, latency, or reliability of the data packets being transmitted; and One or more of: repetition, retransmission per Hybrid Automatic Repeat Request (HARQ) feedback, or next data packet transmission for periodic traffic. The apparatus of claim 7, wherein the determination is based on at least one of:

11. The method of claim 10, further comprising: selecting one or more resources based on at least one of a priority, a latency, a reliability, or a communication range or zone of the data packet to be transmitted, or an interference or congestion measurement; and Selecting one or more resources for at least one of a scheduling or reserved SCI, an initial transmission, a repetition, a Hybrid Automatic Repeat Request (HARQ) feedback, a retransmission per HARQ feedback, or a next data packet of periodic traffic. The apparatus of claim 7 , comprising at least one of:

12. Transmitting the data packet includes: determining whether a congestion threshold has been exceeded based on the measured congestion level, the congestion threshold being based on at least one of a priority, a latency, a reliability, or a communication range or zone of the data packets being transmitted; Based on a determination that the congestion threshold has not been exceeded, transmitting the data packet; and Based on a determination that the congestion threshold has been exceeded, Dropping the transmission based at least on the congestion level or at least one of the priority, latency, reliability, or range of the data packets being transmitted; or adjusting a modulation and coding scheme or a transmission power level based on at least one of the congestion level or the priority, latency, reliability, or range of the data packet being transmitted, and sending at least one of an initial transmission, a repeat, or a retransmission of the data packet. and performing at least one of The apparatus of claim 7 , comprising:

13. A computer-readable storage medium storing instructions that, when executed by a processor, cause an apparatus to perform an operation, the operation comprising: receiving a configuration associated with a resource pool located in the sidelink bandwidth part; determining resource usage in the resource pool and one or more available resources by measuring a Sidelink Reference Signal Received Power (SL-RSRP); selecting one or more resources from the one or more available resources in the resource pool for one or more transmissions; transmitting data packets by transmission of a sidelink shared channel and by transmission of control information by transmission of a sidelink control channel using the selected resource or resources, wherein the sidelink shared channel and the sidelink control channel overlap in time but do not overlap in frequency; 23. A computer-readable storage medium comprising:

14. Determining the one or more available resources in the resource pool includes setting a time interval for a sensing window, the time interval for the sensing window comprising: Periodic or aperiodic transmission, a latency requirement for said data packets; repetition for transmission of said data packets; and Retransmission of said data packet per Hybrid Automatic Repeat Request (HARQ) feedback The computer-readable storage medium of claim 13 , wherein the at least one of the following is set:

15. Determining the one or more available resources in the resource pool includes: sensing resource usage by decoding Sidelink Control Information (SCI) to schedule an initial transmission, preempt scheduled or reserved resources, or reserve at least one of one or more repetitions or one or more retransmissions per Hybrid Automatic Repeat Request (HARQ) feedback; Measuring at least one of a Sidelink Received Signal Strength Indicator (SL-RSSI), a channel busy rate, or a channel occupancy rate; and Resources that are not scheduled, reserved, and preempted; Resources that are within range or zone, or based on a determination that at least one of the SL-RSRP measurement of the resource or the SL-RSSI measurement of the resource is less than a threshold; Determining available resources 14. The computer-readable storage medium of claim 13, comprising at least one of:

16. The method of claim 15, wherein selecting one or more resources includes determining a time interval for resource selection, the time interval for resource selection comprising: one or more of the priority, latency, or reliability of the data packets being transmitted; and One or more of: repetition, retransmission per Hybrid Automatic Repeat Request (HARQ) feedback, or next data packet transmission for periodic traffic. The computer-readable storage medium of claim 13 , wherein the determination is based on at least one of:

17. The method of claim 16, further comprising the steps of: selecting the one or more resources; selecting one or more resources based on at least one of a priority, a latency, a reliability, or a communication range or zone of the data packet to be transmitted, or an interference or congestion measurement; and Selecting one or more resources for at least one of a scheduling or reserved SCI, an initial transmission, a repetition, a Hybrid Automatic Repeat Request (HARQ) feedback, a retransmission per HARQ feedback, or a next data packet of periodic traffic.

14. The computer-readable storage medium of claim 13, comprising at least one of:

Images