Sidelink Access Control Mechanism for New Radio Systems

By using configuration mapping and comparison of channel load status in NR network, access control for V2X services and packets is achieved, which solves the problem of lack of congestion control in NR V2X transmission, and improves the stability and service quality of channel load.

CN113475102BActive Publication Date: 2025-06-20APPLE INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202080016235.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-03-27
Filing Date
2020-03-26
Publication Date
2025-06-20
Estimated Expiration
2040-03-26

AI Technical Summary

Technical Problem

In the new radio (NR) network, vehicles lack effective congestion control mechanisms on the side links for all (V2X) transmission, resulting in excessive channel load and affecting service quality.

Method used

By comparing the configuration mapping and channel load status, access control for V2X services and packets is realized, ensuring that when packets are transmitted on the side link channel, the requirements of channel load and service quality are met.

Benefits of technology

Effectively manage congestion problems in NR V2X transmission, ensure the stability of channel load and the improvement of service quality, and reduce signaling overhead and operational complexity.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113475102B_ABST
    Figure CN113475102B_ABST
Patent Text Reader

Abstract

A serving device (e.g., a user equipment (UE) or other network component) can operate based on a PC5 channel to generate sidelink communication with a peer UE vehicle-to-vehicle device to enable peer-to-peer communication as part of PC5 vehicle-to-everything (V2X) communication. An admission control scheme or a congestion control scheme can be implemented by determining a configuration mapping based on various criteria, including the priority of V2X services, the V2X packet quality of service (QoS) indication for each packet, or other criteria. The UE can determine whether a packet is authorized via the sidelink channel based on this configuration mapping.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 824,726, filed on Mar. 27, 2019, entitled “SIDELINK ADMISSION CONTROL MECHANISMS FOR NEW RADIOS SYSTEMS”, the entire content of which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless technologies and, more particularly, to new radio (NR) sidelink admission control mechanisms for vehicle - to - everything (V2X) or similar devices. Background Art

[0004] Mobile communications in the next - generation wireless communication system 5G or new radio (NR) networks will provide ubiquitous connectivity and access to information and the ability to share data globally. 5G networks and network slices will be a unified, service - based framework that aims to meet common and sometimes conflicting performance criteria and serve a highly diverse range of application domains from enhanced mobile broadband (eMBB) to massive machine - type communication (mMTC), ultra - reliable low - latency communication (URLLC), and other communications. Generally speaking, NR will evolve based on the 3rd Generation Partnership Project (3GPP) Long - Term Evolution (LTE) Advanced technology and additional enhanced radio access technologies (RATs) to achieve seamless and faster wireless connection solutions.

[0005] Some services have ultra-low latency, high data capacity, and strict reliability requirements because any failure or performance issue in the network can cause the service to fail, which in turn can lead to property damage and physical injury. One type of mobile communication includes vehicle communication, where vehicles transmit or exchange vehicle-related information. Vehicle communication can include vehicle-to-everything (V2X), which can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P), among others, where each can include user equipment (UE) or base station equipment such as a new radio node B (gNB), eNodeB (eNB), or other devices / nodes. For example, when referring to a V2X node herein, the node can include a new radio node B (gNB), eNodeB (eNB), user equipment (UE), roadside unit (RSU), drone, or other vehicle equipment or network equipment. In some cases, the vehicle-related information is intended for a single vehicle or other entity. In other cases (such as emergency alerts), the vehicle-related information is intended for a large number of vehicles or other device entities. Emergency alerts can include collision warnings, loss of control warnings, collision avoidance, pedestrian safety, and other coordination to ensure safe and efficient traffic flow, especially in vehicle-to-vehicle communication (e.g., cars, boats, drones, etc.). With the emergence of NR V2X use cases that are expected to be supported both within and outside the coverage area, there is a need to consider methods for defining effective mechanisms for congestion control among different UEs operating on the sidelink for V2X transmissions. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 is a block diagram illustrating an example of a user equipment (UE) that can be used in conjunction with various embodiments (aspects) described herein, the UE being communicatively coupled via a network to network components that are peer devices.

[0007] Figure 2 is an exemplary architecture of a network system according to various embodiments.

[0008] Figure 3 illustrates an exemplary architecture for V2X communication based on the PC5 and Uu interfaces according to various embodiments.

[0009] Figure 4 is a block diagram of vehicle-to-everything sidelink communication for processing an admission / congestion control scheme according to various embodiments described herein.

[0010] Figure 5 is a block diagram illustrating an exemplary process flow of vehicle-to-everything sidelink communication for an admission / congestion control scheme according to various embodiments described herein.

[0011] Figure 6It is another block diagram showing an exemplary process flow of vehicle-to-everything sidelink communication for an access / congestion control scheme according to various embodiments described herein.

[0012] Figure 7 A simplified block diagram of an exemplary user equipment wireless communication device or other network device / component according to the various aspects is shown. Detailed Description

[0013] It is well known that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0014] The present disclosure will now be described with reference to the accompanying drawings, where like reference numerals are used throughout to refer to like elements, and where the structures and devices shown are not necessarily drawn to scale. As used herein, the terms "component," "system," "interface," etc. are intended to refer to computer-related entities, hardware, software (e.g., in execution), and / or firmware. For example, a component can be a processor (e.g., a microprocessor, a controller, or other processing device), a process running on the processor, a controller, an object, an executable, a program, a storage device, a computer, a tablet, and / or a user equipment with a processing device (e.g., a mobile phone, etc.). By way of example, an application running on a server and the server can also be components. One or more components can reside in a process, and components can be located on one computer and / or distributed between two or more computers. Collections of elements or other collections of components may be described herein, where the term "collection" can be interpreted as "one or more."

[0015] In addition, these components can execute from various computer-readable storage media storing various data structures, such as using modules, for example. Components can communicate, such as via signals having one or more data packets, through local and / or remote processes (e.g., data from one component interacts with another component in a local system, a distributed system, and / or across a network such as the Internet, a local area network, a wide area network, or a similar network of other systems via signals).

[0016] As another example, a component can be a device with a specific function, and the specific function is provided by a mechanical component operated by an electrical or electronic circuit, where the electrical or electronic circuit can be operated by a software application or a firmware application executed by one or more processors. The one or more processors can be inside or outside the device, and can execute at least a part of the software or firmware application. As yet another example, a component can be a device that provides a specific function through electronic components without mechanical components; the electronic components can include one or more processors therein to execute at least part of the software and / or firmware that endows the electronic components with functions.

[0017] The use of the term "exemplary" is intended to present concepts in a concrete manner. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, "X employs A or B" is intended to mean any natural inclusive arrangement. That is, if X employs A; X employs B; or X employs both A and B, then in any of the foregoing cases, "X employs A or B" is satisfied. Additionally, the articles "a" and "an" used in this application and the appended claims should generally be construed to mean "one or more" unless otherwise specified or clearly indicated to be in the singular form from the context. Further, to the extent that the terms "comprising", "include", "having", "has", "with", or variants thereof are used in the detailed description and claims, such terms are intended to be inclusive in a manner similar to the term "including". Additionally, in the case of discussing one or more numbered items (e.g., "first X", "second X", etc.), generally, the one or more numbered items can be different or they can be the same, but in some cases, the context may indicate that they are different or indicate that they are the same.

[0018] As used herein, the term "circuit" can refer to, can be part of, or can include the following: a dedicated integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) that executes one or more software or firmware programs, combinational logic circuits, or other suitable hardware components that provide the described function, or an associated memory (shared, dedicated, or group) operably coupled to the circuit. In some embodiments, the circuit can be implemented in one or more software or firmware modules, or the functions associated with the circuit can be implemented by one or more software or firmware modules. In some embodiments, the circuit can include logic that can operate at least partially in hardware.

[0019] Consider various issues of PC5 vehicle-to-everything (V2X) communication between UEs via the PC5 sidelink using various access and congestion control schemes. A UE may autonomously determine authorization to provide packets on the PC5 link based on a configuration map, thereby establishing, configuring, or setting up the PC5 link for PC5 V2X communication as sidelink communication. A vehicle UE may implement access control based on whether to authorize a packet according to a comparison with the configuration map and various criteria. The criteria may include, for example, the QoS of the packet, the channel load status (e.g., channel busy ratio (CBR)), V2X services, sidelink frequency, PC5 quality indicator (PQI), one or more quality of service (QoS) criteria, transmission parameters, channel load status, or priority levels of V2X services. The processing circuitry may be further configured to determine whether to authorize transmission of a packet via the access stratum (AS) layer through the sidelink channel based on the priority level of the V2X service for V2X communication. V2X services may include platooning operations (e.g., a method of driving together in a platoon or convoy of vehicles), autonomous driving, sensor sharing, or intelligent transportation services (ITS). Other aspects and details of the present disclosure are further described below with reference to the drawings.

[0020] Figures 1A to 1C is a block diagram of a wireless communication network 100 according to one or more embodiments herein, for example, in which wireless communication devices (e.g., user equipment (UE) devices) may use unicast, multicast, and broadcast communication. Each device in the network includes vehicle-to-everything (V2X) circuitry 110, which includes memory storage and processing circuitry / components that include one or more processors configured to perform various types of V2X communication. For the purposes of this specification, when a "device" is described as performing some function, it is understood that the processor / component in the V2X device circuitry is performing that function.

[0021] A transmitting (TX) device (e.g., a Tx-UE or device 101) attempting to transmit data to one or more receiving (RX) devices in a wireless communication network first determines sidelink channel resources available for that purpose. In mode 1 (not shown), the TX device 101 requests sidelink channel resources from a manager device 100 that coordinates communication between devices in the network. The manager device 100 may be another UE device or a base station device (gNB, eNB, etc.). The manager device 100 provides the TX device with downlink (DL) control information (DCI) or a permission configuration of the sidelink configuration, and the TX device identifies the specific sidelink channel resources to be used by it to transmit data. These specific sidelink channel resources are selected from a resource pool allocated to the network.

[0022] Based on whether the TX device is to perform unicast, multicast, or broadcast transmission of data, the TX device determines (e.g., via higher layer signaling) a layer-1 destination identifier (L1 destination ID) that uniquely identifies one or more channels between the TX device 101 and a specific RX device (unicast identifier), a group of RX devices (multicast identifier), or all RX devices or Rx-UEs (broadcast identifier) in the wireless communication network. In one example, the channel identified by the L1 destination ID is the Physical Sidelink Control Channel (PSCCH).

[0023] In mode 2 ( Figures 1A to 1C shown), the TX device 101 selects sidelink channel resources to transmit data from a pre-allocated resource pool received a priori from a manager device or network component, rather than receiving an assignment or allocation of specific sidelink communication resources from the manager device 100.

[0024] In Figure 1A the unicast example, the TX device 101 may be configured to transmit data to the RX device 102 and not to other devices. To enable this “direct” communication, the TX device 101 may utilize the unicast L1 destination ID for device 102 to initiate communication with the RX device 102. The TX device 101 uses the PSCCH resources associated with the L1 destination ID for the RX device 102 to send sidelink control information (SCI). The SCI indicates to the RX device 102 how to subsequently receive the transport block (TB) of data from the TX device 101. For example, the SCI includes the unicast L1 destination ID for the RX device 102 and identifies the frequency and time resources of the Physical Sidelink Shared Channel (PSSCH) that are designated to be used for transmitting (and in some cases retransmitting) the TB. The SCI may also indicate whether the RX device provides feedback (such as an ACK / NACK indication) to confirm receipt of the TB or to indicate non-receipt of the TB. To this end, the SCI may include a Hybrid Automatic Repeat reQuest (HARQ) process identifier that uniquely identifies the TB for the RX device to use for providing feedback.

[0025] In Figure 1BIn the multicast example, the TX device 101 attempts to transmit data to a group G that includes several devices 102, 103, 104, and 105 (although there are only four devices in the shown group, there can be a different number of devices in the group). The multicast LI destination ID identifies the PSCCH channel for the SCI that is monitored by the devices in group G. To enable multicast communication, the TX device 101 determines the LI destination ID for group G. The TX device 101 uses the PSCCH resources associated with the LI destination ID for group G to send the SCI. The SCI indicates to the devices in group G how to subsequently receive the TB from device 101. For example, the SCI includes the multicast L1 destination ID for group G and identifies the frequency and time resources of the physical sidelink shared channel (PSSCH) that are designated to be used for transmitting and retransmitting (in some cases) the TB.

[0026] The SCI can indicate multicast option 1 or 2, which indicate whether and how the RX devices in group G provide feedback. In multicast option 1, when feedback is enabled, the only type of feedback provided by the RX devices is NACK, and in some examples, when a particular RX device is outside the communication range specified in the SCI, that RX device does not provide any feedback. In multicast option 2, when feedback is enabled, the RX devices provide both ACK / NACK feedback. The SCI can include a hybrid automatic repeat request (HARQ) process identifier that uniquely identifies the TB for the RX devices to use for providing feedback.

[0027] In Figure 1C the broadcast example, the TX device 101 attempts to transmit data to all devices in the network. The broadcast L1 destination ID identifies the PSCCH channel for the SCI that is monitored by all devices in the network. To enable broadcast communication, device 101 determines the broadcast L1 destination ID for the network. The TX device 101 uses the PSCCH resources associated with the broadcast LI destination ID for the network to send the SCI. The SCI indicates to the devices in the network how to subsequently receive data from device 101. For example, the SCI includes the broadcast L1 destination ID and identifies the frequency and time resources of the physical sidelink shared channel (PSSCH) that are designated to be used for transmitting and retransmitting (in some cases) the TB.

[0028] Configurable for two operation modes for V2X communication, namely via PC5 and via LTE-Uu. LTE-Uu can be unicast or Multimedia Broadcast Service (MBMS). These two operation modes can be independently used by the UE for transmission and reception (e.g., the UE can use MBMS for reception without using LTE-Uu for transmission). The UE can also receive V2X messages via the LTE-Uu unicast downlink. For both of these operation modes, V2X devices (e.g., in different domains) can communicate with each other to exchange V2X messages. The interface between V2X application servers and the method of message exchange between V2X application servers are outside the scope of 3GPP.

[0029] Figure 2 An exemplary architecture of a network system 200 according to various embodiments is shown. The following description is provided for an example system 200 operating in conjunction with LTE system standards and 5G or NR system standards provided in 2GPP technical specifications. However, the exemplary embodiments are not limited in this regard, and the embodiments can be applied to other networks that benefit from the principles described herein, such as future 2GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and the like.

[0030] As Figure 2 shown, the system 200 includes UE 201a and UE 201b (collectively referred to as "UE 201"). In this example, the UE 201 is shown as a smart phone (e.g., a handheld touchscreen mobile computing device that can be connected to one or more cellular networks), but can also include any mobile or non-mobile computing device, such as consumer electronic devices, cellular phones, smart phones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument clusters (IC), head-up display (HUD) devices, on-board diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDT), electronic engine management systems (EEMS), electronic / engine control units (ECU), electronic / engine control modules (ECM), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or "smart" home appliances, machine type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, etc.

[0031] In some embodiments, any one of the UEs 201 can be an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE can utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a public land mobile network (PLMN), proximity services (ProSe), or device-to-device (D2D) communication, a sensor network, or an IoT network. The M2M or MTC data exchange can be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE can execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connection to the IoT network.

[0032] Multiple UEs 201 can be configured to connect to a radio access network (RAN) 210, e.g., communicatively coupled. In an embodiment, the RAN 210 can be a next-generation (NG) RAN or 5G RAN, an evolved UMTS terrestrial RAN (E-UTRAN), or a legacy RAN, such as UTRAN or GERAN. As used herein, the term "NG RAN" etc. can refer to the RAN 210 operating in an NR or 5G system 200, while the term "E-UTRAN" etc. can refer to the RAN 210 operating in an LTE or 4G system 200. The UEs 201 utilize connections (or channels) 202 and 204, respectively, each connection including a physical communication interface or layer (discussed further below in detail).

[0033] In this example, the connections 202 and 204 are shown as air interfaces to enable communicative coupling and can be consistent with a cellular communication protocol, such as a Global System for Mobile Communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a Cellular PTT (POC) protocol, a Universal Mobile Telecommunications Service (UMTS) protocol, a 2GPP LTE protocol, a 5G protocol, an NR protocol, and / or any one of the other communication protocols described herein. In an embodiment, the UEs 201 can directly exchange communication data via the ProSe interface 205. The ProSe interface 205 can alternatively be referred to as the SL interface 205 and can include one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0034] It is shown that UE 201b is configured to access AP 206 (also referred to as "WLAN node 206", "WLAN 206", "WLAN terminal 206", "WT 206", etc.) via connection 207. Connection 207 may include a local wireless connection, such as a connection consistent with any IEEE802.11 protocol, where AP 206 will include a wireless fidelity router. In this example, AP206 is shown as being connected to the Internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE 201b, RAN 210, and AP 206 may be configured to utilize LTE-WLAN aggregation (LWA) operations and / or LTE-WLAN radio-level operations integrated with an IPsec tunnel (LWIP). LWA operations may involve configuring UE 201b, which is in the radio resource control RRC_CONNECTED state, by RAN nodes 211a - 211b to utilize the radio resources of LTE and WLAN. LWIP operations may involve UE 201b using the WLAN radio resources (e.g., connection 207) via an IPsec protocol tunnel to authenticate and encrypt packets (e.g., IP packets) sent through connection 207. IPsec tunnel transport may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0035] RAN 210 may include one or more access nodes (ANs) or RAN nodes 211a and 211b (collectively referred to as "RAN nodes 211") enabling connections 202 and 204. As used herein, terms such as "access node", "access point", etc. may describe equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, transmit receive point (TRxP), or TRP, etc., and may include terrestrial stations (e.g., land access points) or satellite stations providing coverage within a geographical area (e.g., a cell). As used herein, terms such as "NG RAN node", etc. may refer to RAN nodes 211 (e.g., gNB) operating in an NR or 5G system 200, while terms such as "E-UTRAN node", etc. may refer to RAN nodes 211 (e.g., eNB) operating in an LTE or 4G system 200. According to various embodiments, RAN nodes 211 may be implemented as one or more of dedicated physical devices such as macrocell base stations and / or low-power (LP) base stations, where the LP base stations are used to provide femtocell base stations, picocell base stations, or other similar cells with a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to a macrocell.

[0036] In some embodiments, all or part of the plurality of RAN nodes 211 may be implemented as one or more software entities running on a server computer, as part of a virtual network that may be referred to as a Centralized RAN (CRAN) and / or a virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN function splitting such as Packet Data Convergence Protocol (PDCP) splitting, where the Radio Resource Control (RRC) and PDCP layers are operated by the CRAN / vBBUP, and the other L2 protocol entities are operated by the respective RAN nodes 211; Medium Access Control (MAC) / Physical (PHY) layer splitting, where the RRC, PDCP, Radio Link Control (RLC), and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by the respective RAN nodes 211; or "lower PHY" splitting, where the RRC, PDCP, RLC, MAC layers, and the upper part of the PHY layer are operated by the CRAN / vBBUP, and the lower part of the PHY layer is operated by the respective RAN nodes 211. This virtualization framework allows the idle processor cores of the RAN nodes 211 to execute other virtualized applications. In some specific implementations, individual RAN nodes 211 may represent respective gNB Distributed Units (DUs) connected to the gNB Central Unit (CU) via respective F1 interfaces. In these specific implementations, the gNB-DU may include one or more remote radio headers or RF front-end modules (RFEMs), and the gNB-CU may be operated by a server (not shown) located in the RAN 210 or by a pool of servers in a manner similar to the CRAN / vBBUP. Additionally or alternatively, one or more of the plurality of RAN nodes 211 may be a Next Generation eNB (ng-eNB), which is a RAN node that provides the E-UTRA user plane and control plane protocol terminations to a plurality of UEs 201 and is connected to the 5GC via the NG interface.

[0037] In a V2X scenario, one or more of the RAN nodes 211 may be or act as an RSU. The term "road side unit" or "RSU" may refer to any transportation infrastructure entity for V2X communication. The RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where the RSU implemented in or by the UE may be referred to as a "UE-type RSU", the RSU implemented in or by the eNB may be referred to as an "eNB-type RSU", the RSU implemented in or by the gNB may be referred to as a "gNB-type RSU", etc. In one example, the RSU is a computing device coupled to a radio frequency circuit located on the road side, and the computing device provides connectivity support to passing vehicle UEs 201 (vUE 201). The RSU may also include an internal data storage circuit for storing intersection map geometries, traffic statistics, media, and application software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate on the 5.9 GHz DSRC band to provide extremely low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. In addition or alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low-latency communication and other cellular communication services. In addition or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communication. Some or all of the computing device and the radio frequency circuit of the RSU may be encapsulated in a weather-resistant package suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or a backhaul network.

[0038] Any one of the RAN nodes 211 may terminate the air interface protocol and may be the first point of contact for the UE 201. In some embodiments, any one of the RAN nodes 211 may perform various logical functions of the RAN 210, including but not limited to the functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0039] In an embodiment, multiple UEs 201 may be configured to communicate with each other or with any one of the RAN nodes 211 over a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as but not limited to OFDMA communication technology (e.g., for downlink communication) or single carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), but the scope of the embodiments is not limited in this regard. The OFDM signal may include multiple orthogonal subcarriers.

[0040] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 211 to the UE 201, and uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is the physical resources in the downlink in each time slot. For OFDM systems, such time-frequency plane representations are common practice, which makes wireless resource allocation intuitive. Each column and each row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one time slot in the radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this can represent the smallest amount of resources that can currently be allocated. Such resource blocks are used to transmit several different physical downlink channels.

[0041] According to various embodiments, the UE 201 and the RAN nodes 211 transmit data (e.g., transmit data and receive data) over a licensed medium (also referred to as "licensed spectrum" and / or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum" and / or "unlicensed band"). The licensed spectrum can include channels operating in a frequency range of approximately 400 MHz to approximately 2.8 GHz, while the unlicensed spectrum can include the 5 GHz band.

[0042] To operate in the unlicensed spectrum, the UE 201 and the RAN nodes 211 can use Licensed-Assisted Access (LAA), eLAA, and / or feLAA mechanisms to operate. In these implementations, the UE 201 and the RAN nodes 211 can perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations can be performed according to the Listen-Before-Talk (LBT) protocol.

[0043] LBT is a mechanism by which devices (e.g., multiple UEs 201, multiple RAN nodes 211, etc.) sense the medium (e.g., a channel or carrier frequency) and transmit when the medium is sensed as idle (or when a specific channel in the medium is sensed as unoccupied). The medium sensing operation may include a Clear Channel Assessment (CCA) that uses at least Energy Detection (ED) to determine whether there are other signals on the channel in order to determine whether the channel is occupied or clear. This LBT mechanism allows cellular / LAA networks to coexist with existing systems in the unlicensed spectrum and with other LAA networks. ED may include sensing RF energy on the expected transmission band over a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0044] Typically, existing systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as a UE 201, an AP 206, etc.) intends to transmit, the WLAN node may first perform a CCA before transmission. Additionally, in the case where more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. This backoff mechanism can be a counter randomly introduced within the CWS that increases exponentially in the event of a collision and is reset to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to the CSMA / CA of WLANs. In some specific implementations, the LBT process for a downlink (DL) or uplink (UL) transmission burst (including Physical Downlink Shared Channel (PDSCH) or Physical Uplink Shared Channel (PUSCH) transmission) may have an LAA contention window with a length that can vary between X and Y extended CCA (ECCA) slots, where X and Y are the minimum and maximum values of the contention window size (CWS) for LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μs); however, the size of the CWS and the maximum channel occupancy time (MCOT) (e.g., transmission burst) may be based on government regulatory requirements.

[0045] The LAA mechanism is based on the Carrier Aggregation (CA) technology of the LTE-Advanced system. In CA, each aggregated carrier is called a Component Carrier (CC). A CC can have a bandwidth of 1.4, 2, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, so the maximum aggregated bandwidth is 100 MHz. In a Frequency Division Duplexing (FDD) system, for DL and UL, the number of aggregated carriers can be different, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, each CC can have a different bandwidth from other CCs. In a Time Division Duplexing (TDD) system, the number of CCs and the bandwidth of each CC are usually the same for DL and UL.

[0046] CA also includes individual serving cells to provide each CC. The coverage of the serving cells can be different. For example, because the CCs on different frequency bands will experience different path losses. The Primary Serving Cell or PCell can provide the Primary Component Carrier (PCC) for both UL and DL, and can handle Radio Resource Control (RRC) and Non-Access Stratum (NAS) related activities. Other serving cells are called SCell, and each SCell can provide a single Secondary Component Carrier (SCC) for both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require the UE 201 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCell can operate in the unlicensed spectrum (referred to as "LAA SCell"), and the LAA SCell is assisted by the PCell operating in the licensed spectrum. When the UE is configured with more than one LAA SCell, the UE can receive UL authorization on the configured LAA SCell, indicating different PUSCH start positions within the same subframe.

[0047] The PDSCH carries user data and higher layer signaling to the UE 201. The Physical Downlink Control Channel (PDCCH) carries information such as the transmission format and resource allocation related to the PDSCH channel, etc. It can also notify the UE 201 about the transmission format, resource allocation, and Hybrid Automatic Repeat Request (HARQ) information related to the uplink shared channel. Generally, downlink scheduling (allocating control and shared channel resource blocks to the UEs 201b within the cell) can be performed at any of the RAN nodes 211 based on the channel quality information fed back from any of the UEs 201. The downlink resource allocation information can be sent on the PDCCH for each UE used (e.g., allocated to) the UEs 201.

[0048] The PDCCH uses control channel elements (CCEs) to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruples, and then a sub-block interleaver can be used to permute them for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets of four physical resource elements, called resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the DCI and the channel conditions, one or more CCEs can be used to transmit the PDCCH. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8).

[0049] Some embodiments can use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments can utilize an extended (E)-PDCCH that uses PDSCH resources for control information transmission. One or more enhanced CCEs (ECCEs) can be used to transmit the EPDCCH. Similar to the above, each ECCE can correspond to nine sets of four physical resource elements, called enhanced resource element groups (EREGs). In some cases, an ECCE can have a different number of EREGs.

[0050] Multiple RAN nodes 211 can be configured to communicate with each other via an interface 212. In an embodiment where the system 200 is an LTE system, the interface 212 can be an X2 interface 212. The X2 interface can be defined between two or more RAN nodes 211 (e.g., two or more eNBs, etc.) connected to the evolved packet core (EPC) or the core network 220, and / or between two eNBs connected to the EPC 220. In some specific implementations, the X2 interface can include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U can provide a flow control mechanism for user data packets transmitted through the X2 interface and can be used to convey information about the delivery of user data between eNBs. For example, the X2-U can provide specific sequence number information about user data transmitted from the master eNB (MeNB) to the secondary eNB (SeNB); information about the successful in-sequence delivery of PDCP packet data units (PDUs) from the SeNB to the UE 201 for user data; information about PDCP PDUs not delivered to the UE 201; information about the current minimum desired buffer size at the SeNB for transmitting user data to the UE; and so on. The X2-C can provide access mobility functions within LTE, including context transfer from the source eNB to the target eNB, user plane transmission control, etc.; load management functions; and inter-cell interference coordination functions.

[0051] In an implementation where system 200 is a 5G or NR system, interface 212 can be an Xn interface 212. The Xn interface is defined between two or more RAN nodes 211 (e.g., two or more gNBs, etc.) connected to 5GC 220, between a RAN node 211 (e.g., gNB) connected to 5GC 220 and an eNB, and / or between two eNBs connected to 5GC 220. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U can provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. Xn-C can provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for UE 201 in the connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in the connected mode between one or more RAN nodes 211. This mobility support can include context transfer from an old (source) serving RAN node 211 to a new (target) serving RAN node 211; and control of the user plane tunnel between the old (source) serving RAN node 211 and the new (target) serving RAN node 211. The protocol stack of Xn-U can include a transport network layer built on the Internet Protocol (IP) transport layer, and a GPRS tunneling protocol (GTP-U) layer of the user plane on top of the User Datagram Protocol (UDP) or IP layer, or both, for carrying user plane PDUs. The Xn-C protocol stack can include an application layer signaling protocol (referred to as the Xn application protocol (Xn-AP)) and a transport network layer built on the Stream Control Transmission Protocol (SCTP). SCTP can be on top of the IP layer and can provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other specific implementations, the Xn-U protocol stack and / or the Xn-C protocol stack can be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0052] RAN 210 is shown as communicatively coupled to a core network - in this embodiment, communicatively coupled to core network (CN) 220. CN 220 may include a plurality of network elements 222, which are configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 201) connected to CN 220 via RAN 210. Components of CN 220 may be implemented in one physical node or separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV may be used to virtualize any one or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instance of CN 220 may be referred to as a network slice, and a logical instance of a part of CN 220 may be referred to as a network sub-slice. A network function virtualization (NFV) architecture and infrastructure may be used to virtualize one or more network functions onto physical resources that include a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, an NFV system may be used to perform a virtual or reconfigurable implementation of one or more evolved packet core (EPC) components / functions.

[0053] Generally, application server 230 may be an element that provides applications that use IP bearer resources with the core network (e.g., Universal Mobile Telecommunications System Packet Service (UMTS PS) domain, LTE PS data services, etc.). Application server 230 may also be configured to support one or more communication services for UE 201 via EPC or CN 220 (e.g., VoIP sessions, PTT sessions, group communication sessions, social network services, etc.).

[0054] In an embodiment, CN 220 may be a 5GC (referred to as "5GC 220", etc.), and RAN 210 may be connected to CN 220 via NG interface 212. In some examples, NG interface 212 may be divided into two parts: a Next Generation (NG) User Plane (NG-U) interface 214, which carries traffic data between RAN node 211 and User Plane Function (UPF); and an S1 Control Plane (NG-C) interface 215, which is a signaling interface between RAN node 211 and Access and Mobility Management Function (AMF). Core network CN 220 may also be 5GC 220.

[0055] In an embodiment, CN 220 may be a 5G CN (referred to as "5GC 220", etc.), while in other embodiments, CN 220 may be an EPC. In the case where CN 220 is an EPC (referred to as "EPC 220", etc.), RAN 210 may be connected to CN 220 via S1 interface 212. In an embodiment, S1 interface 212 may be divided into two parts: S1 user plane (S1-U) interface 214, which carries traffic data between RAN node 211 and S-GW; and S1-MME interface 215, which is a signaling interface between RAN node 211 and MME.

[0056] Figure 3 An exemplary architecture for V2X communication based on PC5 and Uu interfaces according to various embodiments is shown. In Figure 3 it, UE A (which may be the same as or similar to UE 201a in Figure 2 ) uses the subscription of PLMN A, and UE B (which may be the same as or similar to UE 201b in Figure 2 ) uses the subscription of PLMN B; UE A may roam in PLMN B, while UE B does not roam. V2X application server 306A may be connected to multiple PLMNs. For example, one V2X application server may be connected to V2X control function 306B in PLMN A and V2X control function in PLMN B in Figure 3 . V2X control functions 306A to 306E are generally referred to as V2X control function 306.

[0057] There are two operation modes for V2X communication, namely operation modes via PC5 and via Uu interface. The Uu interface (or simply "Uu") may be an LTE-Uu or NR-Uu interface. Communication via the Uu interface may be unicast and / or MBMS. These two operation modes can be independently used by the UE for transmission and reception. For example, the UE may use MBMS for reception without using the Uu interface for transmission. The UE may also receive V2X messages via Uu unicast downlink. For both operation modes, V2X application servers (e.g., in the same or different domains) may communicate with each other to exchange V2X messages. Any suitable interface between V2X application servers may be used, and any suitable mechanism may be used to exchange messages between V2X application servers. For both operation modes, the V2X service does not require the ProSe discovery feature ("ProSe direct discovery", see, for example, 3GPP TS 23.303, clause 5.3). The ProSe discovery feature may be used by V2X-capable UEs, but this depends on the UE implementation. According to regional regulations, lawful interception requirements may also apply to V2X services. In addition, in some specific implementations, it may be possible by making the V2X application logic / server communicate withFigure 3 Some of the entities shown are co-located to use one or more RSU (e.g., RAN node 211), e.g., co-locating the V2X application logic / server with one or more vUE 201, RAN node 201, and / or LGW.

[0058] As Figure 3 shown, V2X communication may involve the following reference points: V1 reference point between the V2X application in the UE (e.g., UE 201, such as UE A to D) and the V2X application server; V2 reference point between the V2X application server in the operator network and the V2X control functions 306 310, where the V2X application server may be connected to the V2X control functions 306 310 belonging to multiple public land mobile networks (PLMN); V3 reference point between the UE 201 and the V2X control function 306 in the UE home PLMN, which is based on the service authorization and configuration part of the PC3 reference point defined in clause 5.2 of 3GPP TS 23.303 and is applicable to both PC5-based and Uu interface-based V2X communication and optionally multimedia broadcast and multicast service (MBMS) and Uu interface-based V2X communication; V4 reference point between the home subscriber server (HSS) 320 and the V2X control functions 306 310 in the operator network; V5 reference point between the V2X applications in the UE (UE A to D, such as Figure 2 the UE 201) of the present specification; V6 reference point between the V2X control function 306 310 in the home public land mobile network (HPLMN) and the V2X control function 306 310 in the visited public land mobile network (VPLMN); PC5 reference point between the UEs in the user plane of ProSe direct communication for V2X services; S6a reference point, in addition to the relevant functions discussed herein and / or in 3GPP TS 23.401, the V2X service S6a reference point is used to download V2X service-related subscription information to the mobility management entity (MME) 330 or notify the MME 330 during the evolved UTRAN (E-UTRAN) attachment procedure that the subscription information in the HSS 320 has changed; S1 reference point for the control plane (S1-MME), in addition to the relevant functions discussed herein and / or in 3GPP TS 23.401 for S1-MME for V2X services, it is also used to transfer V2X service authorization from the MME 330 to the eNodeB (e.g., Figure 2RAN node 211); the xMB reference point between the V2X application server (e.g., content provider) and the Broadcast Multicast Service Center (BM-SC), and this reference point is defined in 3GPP TS 26.348; the MB2 reference point between the V2X application server and the BM-SC, and this reference point is defined in 3GPP TS 23.468; the SGmb / SGi-mb / M1 / M3 reference points within the MBMS system, and this reference point is defined in 3GPP TS 23.246; and the Uu interface reference point between the UE 201 and the E-UTRAN 340.

[0059] The V2X control function 306 is a logical function for network-related actions required for V2X (e.g., operated by one or more physical or virtual computing elements). According to specific implementations, one or more logical V2X control functions 306 that support V2X services may exist in each PLMN. If multiple V2X control functions 306 are deployed within the same PLMN (e.g., for load reasons), a suitable mechanism (e.g., through database lookups, etc.) may be employed to locate the specific V2X control function 306 for a specific vUE. The V2X control function 306 is used to provide the necessary parameters for the UE to use V2X communication. It is used to provide the PLMN-specific parameters to the UE that allow the UE to use V2X in that specific PLMN. The V2X control function 306 is also used to provide the parameters required when the UE "is not served by the E-UTRAN". The V2X control function 306 may also be used to obtain the V2XUSD from the V2X application server via the V2 reference point for the UE to receive MBMS-based V2X traffic. The V2X control function 306 may also obtain the parameters required for V2X communication via the PC5 reference point from the V2X application server via the V2 reference point. The V2X control function 306 of the HPLMN is discovered by interacting with the Domain Name Service (DNS) function. The FQDN of the V2X control function 306 in the home PLMN may be pre-configured in the UE, provided by the network, or self-constructed by the UE, e.g., derived from the PLMN ID of the HPLMN. The IP address of the V2X control function 306 in the home PLMN may also be provided to the UE.

[0060] The UE exchanges V2X control information with the V2X control function 306 via the V3 reference point, and performs various procedures for V2X communication via the PC5 reference point and / or the Uu interface reference point. The UE also supports the configuration of parameters for V2X communication (e.g., destination layer 2 ID, radio resource parameters, V2X application server address information, mapping between service type and V2X frequency). These parameters can be pre-configured in the UE, or provided by the V2X control function 306 in the HPLMN via the V3 reference point by sending signaling if within coverage. The UE may be provided with a V2X user service domain (USD) for receiving MBMS-based V2X traffic via the existing MBMS service notification mechanism, or provided by the V2X control function 306, or provided by the V2X application server via the V1 reference point. The UE may be configured with a V2X server USD for receiving V2X application server information via MBMS.

[0061] In an implementation where the Uu interface is the NR-Uu interface, the NR-Uu interface supports authorization for having multiple active UL configurations in a given BWP in a given cell, with no more than one being used simultaneously for transmission by the UE. Downlink control information (DCI) is used to identify the authorization for type 2 UL configurations to be activated or deactivated. The UE may report auxiliary information to the gNB, including at least UE-related geographical information such as location, and report Uu and SL V2X traffic periodicity, timing offset, and message size at least for periodic traffic. Rel-15 NR does not support multicast / broadcast via the Uu interface. There are two techniques for Uu multicast / broadcast in 3GPP: Multimedia Broadcast Single Frequency Network (MBSFN) and Single Cell Point-to-Multipoint (SC-PTM), both of which are supported in LTE. In some cases, NR Uu multicast / broadcast is beneficial at least in terms of resource utilization for V2X use cases. In these implementations, NR Uu may allocate NR SL resources for the following cases: (i) licensed carriers are shared between NR Uu and NR SL; and (ii) carriers are dedicated to NR SL. Resource allocation mode 1 supports the following techniques: dynamic resource allocation; and configured grant types 1 and 2.

[0062] To support V2X SL communication, the RRC layer provides at least the following functions in Uu: obtaining V2X-specific SIBs; establishing an RRC connection for V2X SL communication: for a UE configured by the upper layer to transmit V2X SL communication and having data to transmit, at least include the frequency for SL communication in the V2X-specific SIB without including the transmission resource pool for that frequency, where the UE is configured to establish an RRC connection in case of transmitting on that frequency; configuring the resource allocation mode for V2X communication in SL, including resource allocation mode 1 and mode 2, which can be configured to be used simultaneously for the UE and the network-provided resource pool, where the UE autonomously selects the sidelink grant for "sidelink unicast / multicast / broadcast" via broadcast system information and / or dedicated signaling, and at least when this configuration is provided by a system information block (SIB) (e.g., reusing the valid area of a new radio (NR) SIB), a mode 2 resource configuration can be provided for a given validity area, where the UE does not need to obtain a new mode 2 resource configuration when moving within the validity area.

[0063] Mobility management through the access and mobility management function (AMF) involves, during handover, performing the transmission and reception of V2X sidelink (SL) communication at least based on the configuration of the target cell's exceptional transmission resource pool and reception resource pool available to the UE during handover provided in the handover command. Cell selection and reselection for V2X SL communication are performed at least based on the following criteria and configurations: Carrier frequencies that can (pre)-configure V2X SL resource configurations or inter-frequency configurations can be provided; Frequencies that provide inter-frequency V2X SL configurations are prioritized during cell (re)selection; And how to minimize the interruption of V2X SL transmission and reception during cell reselection depends on the UE implementation. Mobility management (e.g., through the AMF) also involves the reporting of UE SL information; SL-related measurements and reports include: measurement and reporting of the channel busy rate (CBR), and reporting of location information; and at least reporting UE assistance information for traffic patterns (periodicity, offset, and packet size) for periodic traffic.

[0064] The V2X application server (V2X access stratum (AS)) can communicate with Figure 2is the same as or similar to the application server 230. The V2X AS receives uplink data from the UE via the corresponding unicast channel and delivers the data to the UEs in the target area using unicast delivery and / or MBMS delivery. The V2X AS includes a mapping from geographical location information to an appropriate target Multimedia Broadcast Multicast Service Area Identifier (MBMS SAI) for broadcasting, a mapping from geographical location information to an appropriate target 3GPP ECGI for broadcasting, and a mapping from the E-UTRAN cell global identifier (ECGI) provided by the UE to an appropriate target MBMS SAI for broadcasting. The V2X AS provides the appropriate ECGI and / or MBMS SAI to the BM-SC. The V2X AS is also pre-configured with local MBMS (L.MBMS) information (e.g., IP multicast address, multicast source (SSM), C-TEID), and is pre-configured with the IP address of L.MBMS and the port number of the user plane. The V2X AS sends the L.MBMS information to the BM-SC, requests the BM-SC to allocate / deallocate a set of Temporary Mobile Group Identities (TMGIs), and requests the BM-SC to activate / deactivate / modify the MBMS bearer. The V2X AS provides the V2X User Service Description (USD) to the V2X control function 306 for the UE to receive MBMS-based V2X traffic, provides the parameters for V2X communication via the PC5 reference point to the V2X control function 306, and provides the parameters for V2X communication via the PC5 reference point to the UE.

[0065] In addition to the functions discussed herein and defined in 3GPP TS 23.401 and 3GPP TS 23.246, the MME obtains subscription information related to V2X as part of the subscription data and provides an indication of the UE authorization status regarding V2X usage to the E-UTRAN 340.

[0066] In addition to the functions defined in 3GPP TS 23.246 and 3GPP TS 23.468, the BM-SC receives the L.MBMS information from the V2X application server and sends the L.MBMS information to the MBMS gateway (MBMS-GW).

[0067] In addition to the functions defined in 3GPP TS 23.246, the MBMS-GW skips the allocation process for IP multicast distribution, e.g., allocating an IP multicast address if / when the MBMS-GW is to receive the L.MBMS information from the BM-SC.

[0068] In the case of V2X for resource allocation, congestion control, in-device coexistence, power control, sidelink radio bearer (SLRB) configuration, and admission control, quality of service (QoS) management is related to V2X. As specified in 3GPP TS 23.501, QoS management of the Uu interface is based on QoS parameters (e.g., 5G QoS indicator (5QI), allocation / retention priority (ARP), recursive quantization analysis (RQA), guaranteed flow bit rate (GFBR), maximum flow bit rate (MFBR), notification control, and maximum packet loss rate). Admission control is performed before establishing a QoS flow that corresponds to a radio bearer. In the case of insufficient free resources, a QoS flow can be rejected or an existing QoS flow can be pre-empted according to its ARP. Assuming the QoS flow is accepted, it will be further processed in the network according to other QoS parameters. The 5QI value corresponds to multiple QoS characteristics, namely resource type (e.g., guaranteed bit rate (GBR), latency-critical GBR, or non-GBR), priority level, packet delay budget, packet error rate, average window, and maximum data burst volume (only for the latency-critical GBR resource type). The physical layer parameters related to QoS management are the priority, latency, reliability, and minimum required communication range of the traffic being delivered (as defined by the upper layer). Data rate requirements are also supported in the AS. SL congestion metrics, and at least in resource allocation mode 2, a mechanism for congestion control can be supported, where the SL congestion metric is reported to the gNB. For SL unicast, multicast, and broadcast, the upper layer provides the QoS parameters of the V2X packet to the AS. For example, for V2X sidelink transmissions in SL unicast, multicast, and broadcast, the SLRB can be (pre)-configured according to clause 7 of 3GPP TR 38.885. For NR SL unicast, the PC5 QoS flow to SLRB mapping is performed in the service data adaptation protocol (SDAP) layer of the UE. Some SLRB configurations for unicast, including at least the sequence number (SN) length, radio link control (RLC) mode, and PC5 QoS profile associated with each SLRB, can be notified by one UE to the peer UE in the SL when they are (pre)-configured at the UE.

[0069] A UE or the network (NW) (e.g., RAN node 211) can perform admission control directly on the QoS flow associated with a given V2X service, which is mapped to a radio bearer. The admission control can apply to both UE autonomous resource allocation / selection and resource allocation scheduled by the gNB. Admission control decisions can be made based on the required QoS characteristics of the incoming flow described herein (e.g., data rate, packet delay budget (PDB), reliability, ARP, and channel congestion). According to the UE's subscription data, the mobile network operator (MNO) can provide different priority handling to different UEs running the same service. ARP can be used to reflect such differences. For example, when the channel is congested, the NW / UE can discard QoS flows with high ARP in favor of newly arrived QoS flows with low ARP.

[0070] Admission control in the Uu interface can be based on explicit bearer requests and configuration signaling. In addition or alternatively, when in the gNB scheduling mode (e.g., mode 1), admission control for SL (such as V2X SL transmission) can be based on explicit bearer requests and configuration signaling. For mode 1, explicit admission control signaling can be used to request / configure / reject / preempt SL QoS flows between the UE and the gNB. In these embodiments, the UE can notify the gNB of the presence of a new incoming QoS flow, and the gNB can accept / reject the UE's request or even preempt other ongoing flows / bearers. For UE autonomous resource allocation / selection, the (pre)configuration can provide different congestion thresholds for different QoS attributes, such that the transmitting UE can perform admission control based on the (pre)configured rules. For mode 2, the transmitting UE follows the (pre)configured criteria (e.g., provided via RRC / SIB) to perform admission control on incoming SL QoS flows. In the autonomous mode, packet-level preemption between UEs can also be used.

[0071] In a first embodiment, admission control for V2X SL can be based only on per-service ("per-service admission control"). In these embodiments, once the UE decides to initiate a specific V2X service, the UE checks whether it is authorized to perform V2X transmission at the frequency of interest. In these embodiments, the NW (e.g., gNB) configures the mapping between a specific V2X service and the carrier frequency, and the mapping indicates the specific services for which the UE is not authorized to perform V2X transmission. In such embodiments, the UE refers to the mapping to determine whether V2X transmission is allowed at the frequency of interest based on the V2X service type of the V2X transmission. In some embodiments, the mapping can be configured by the NW using dedicated RRC signaling, broadcast system information. In other embodiments, the mapping can be hard-coded in the UE (e.g., in a universal integrated circuit card (UICC) or eUICC, etc.). Note that this type of per-service admission control does not consider the dynamic channel conditions on the sidelink.

[0072] In a second implementation, admission control for V2X SL can be based only on per-packet ("per-packet admission control"). In these implementations, the UE determines whether it can initiate any V2X transmission on a given sidelink frequency based on an NW (e.g., RAN node 211) authorization, regardless of the V2X service initiated at the UE. In these implementations, the UE is further configured to have a CBR-QoS criterion (e.g., a CBR-QoS criterion mapped to a Tx parameter table) mapped by the NW to a Tx parameter configuration. In such implementations, a specific point in the mapping table corresponding to no transmission (e.g., an unused or reserved value) can be reserved. When V2X transmission is allowed, the UE then performs SL measurements on the channel conditions and determines the channel load status (e.g., CBR). Subsequently, this information can optionally be used together with the QoS information for each packet passed down to the AS layer and the CBR-QoS criterion configured by the NW to determine for each packet whether it can be transmitted.

[0073] In some second implementations, the NW can indicate only the QoS information, regardless of the current channel load status. In these implementations, the PQI and any additional QoS decisions (e.g., delay tolerance or reliability threshold) can be indicated as QoS information. In some implementations, the QoS information can indicate whether transmission of a specific PQI value is allowed or not. This is because, in some cases, since the PC5 quality indicator (PQI) is a combination of several QoS factors, a simple comparison may or may not always be feasible. The QoS information can be indicated via system information broadcast for a given Tx pool or via a dedicated RRC configuration. In these implementations, for example, UE 201 (or any of UEs A to D) may not transmit any V2X packets with a QoS other than the QoS indicated in the configuration mapping.

[0074] In other second embodiments, the channel load status may be considered. In these embodiments, the CBR-PQI-Tx parameter table may be configured at UE201 (or any one of UEs A to D), and UE 201 (or any one of UEs A to D) queries the configuration table of the packet to determine the exact Tx parameters to be applied to the packet. The Tx parameters may include, for example, modulation and coding scheme (MCS) index, TX power, number of potential retransmissions, and / or other similar Tx parameters. This allows for a more finely tuned control of the congestion level based on the packet's V2X QoS indicator / indication (VQI) (and / or other packet parameters). For example, even if the channel load is relatively high, packets with a very high priority VQI may be allowed to be transmitted, but the transmission of another packet with a lower priority VQI from the same or different services may be prohibited. In these embodiments, in addition to the priority, other QoS factors may also be considered. To achieve this behavior, a specific point in the mapping table corresponding to no transmission (e.g., an unused or reserved value) may be reserved, which essentially means that regardless of the PQI of the V2X packet, the UE cannot transmit the packet through the sidelink interface.

[0075] In a third embodiment, the admission control for V2X SL may be based on a combination of per-service and per-packet ("per-service / per-packet admission control"). These embodiments consider the QoS of V2X services and V2X packets together with the channel load status. In these embodiments, when a V2X service is initiated, the UE may utilize the current load status of the channel to determine whether the V2X service has been initiated. This may be achieved by the NW configuring the mapping between the V2X service and the channel load (e.g., CBR) in addition to the mapping between the V2X service and the sidelink frequency as in the first embodiment. In this way, even if the UE is allowed to transmit on a specific V2X frequency for a specific V2X service, but if the channel load is too high, the UE may not be allowed to generate a packet and submit it to the AS layer for transmission. In these embodiments, the NW may configure the mapping of V2X service-frequency and the mapping of V2X service-CBR jointly or separately. If the transmission of a high-priority service is allowed based on the above criteria, a per-packet congestion control mechanism is further applied to the packets of that service to ensure that only the essential packets are transmitted through the SL interface. The services in these embodiments may also refer to new QoS flows from the higher layer that belong to the initiated service. The QoS flow has a QoS flow indicator / indication (QFI) (or 5QI) that can be used to determine the priority of the packet.

[0076] Reference Figure 4, the figure shows a block diagram of a system 400 that can be employed at a UE / V2X 101 (such as UE 201 or UE A to D) capable of direct peer-to-peer communication or at a participating / peer entity 440, including gNB 210 or other vUE 102. The system 400 can include a processor 410 that includes processing circuitry and associated interfaces (e.g., a communication interface for communicating with communication circuitry 420, a memory interface for communicating with memory 440, etc.) and communication circuitry 420 (e.g., including circuitry for wired and / or wireless connections, such as a transmitter circuitry (e.g., associated with one or more transmit chains) and / or a receiver circuitry (e.g., associated with one or more receive chains)). The transmitter circuitry and receiver circuitry of transceiver 420 can employ common or different circuit elements or a combination thereof. Memory 440 can include any of a variety of storage media and can store instructions or data associated with one or more of processor 410 or communication circuitry 420. In an implementation, signaling or messaging between different implementations of system 400 can be generated by processor 410, transmitted by communication circuitry 420 via a suitable interface or reference point (e.g., PC5, etc.), received by communication circuitry 420, and processed by processor 410.

[0077] When UE 101 is authorized to use V2X services over a 4GPP network, the UE can receive V2X configuration information. This authorization is done by the V2X function in the core network, and as part of the authorization process, the V2X function can send, for example, a list of preferred air interface technologies. Alternatively, the V2X configuration can be performed by an application server that is not part of the core network. UE101 can employ one or more channel quality measurements, such as power measurements or other measurements related to sidelink communication, for direct peer-to-peer communication.

[0078] The V2X UE can be located in a given coverage area within a cell covered by gNB 210, which supports 5G, LTE, and dedicated short range communication (DSRC) roadside unit (RSU) functionality. These UEs 440 can notify the gNB / RSU of which V2X communication radio access technology (RAT) they support. Based on this information, the network can select an access technology for the UE to use. The system 400 includes vehicle / traffic participant entities 440. The vehicle / traffic participant entities 440 include one or more pedestrian devices (P-UE) 422, infrastructure entities 424 (e.g., RAN 220), vehicle entities 426, or other network devices / components. The V2X UE 101 can also include one or more antennas 408 for communication, which includes sidelink communication 414 with vehicle / traffic participant entities or peer devices 440.

[0079] Vehicle communication between the V2X UE 101 and any vehicle / pedestrian device entity 440 can utilize cooperative sensing including information from other vehicles, sensors, etc. to process and share information to provide vehicle services such as collision warnings, autonomous driving, etc. The V2X UE 101 is configured to acquire, select, or determine QoS attributes associated with sidelink communication. The communication / communication configuration herein may include transmission resources, frame structure design, transmit power for broadcasting (communication), subframe structure, modulation and coding scheme (MCS), number of occupied subchannels / transmission time interval (TTI), resource reservation interval / cycle, transmission range of each transmission block (TB), channel busy rate (CBR), channel occupancy ratio (CR), CR limit (CR_limit), associated LTE parameters in 4GPP, etc. For example, the frame structure has parameters including sampling rate, frame length, subframe length, subcarrier spacing, and cyclic prefix length, and is based on the obtained success rate.

[0080] The sensing operation can be a simplified sensing process for V2X UE resource selection, aiming to reduce complexity and power consumption. Generally speaking, the principles of the sensing and resource selection process can be used for sidelink communication management. The resource (re)selection triggers utilized herein may include a resource reselection counter, probabilistic reselection based on the probability of reselection of one or more resources, and one or more reselection trigger conditions, which include whether the UE 101, for example, skips transmission in a preconfigured / pre-determined number of resource reservation cycles. Specifically, modifications to resource exclusion operations and the sidelink (SL) received signal strength indication (SL-RSSI) average or other sidelink channel indications of non-excluded resources can be considered. Such indications can provide information, for example, on whether the sidelink signal or sidelink synchronization reference has been lost or is unavailable for initial sidelink synchronization.

[0081] The embodiments herein include various mechanisms, which include enhanced NR sidelink communication operations between UEs having components, configurations, or processes for resource allocation, using the PC5 channel 414, to enable device-to-device (D2D) communication or sidelink communication among one or more of the UE 101, V-UE 426, or other networked devices 440 for direct communication between these devices. In PC5 V2X communication, there can be several different combinations between the source UE and the peer UE, including one or more of the following: V2V, V2P, V2I, RSU, or other UEs as UEs or V-UEs, which coordinate with each other as peers to participate in direct peer / sidelink communication.

[0082] With the emergence of NR V2X use cases that are expected to be supported both within and outside the coverage area, a method for defining an effective mechanism for congestion control among different UEs operating on the sidelink for V2X transmissions needs to be considered. To this end, various embodiments provide for performing admission control at the AS layer for the autonomous resource selection mode in V2X transmissions, either per packet, per V2X service, or both per packet and per service, where the UEs decide and select their own resources for V2X sidelink communication based on a configuration mapping that is V2X configuration information.

[0083] Various embodiments enable peer devices (e.g., vehicle-to-vehicle device communication) to perform an admission control scheme or a congestion control scheme over the NR sidelink. Compared with existing solutions, the embodiments discussed herein reduce the signaling overhead and the complexity of operations.

[0084] Most NR V2X use cases such as platooning and advanced driving, as V2X services, are expected to be somewhat agnostic to network coverage. In other words, any given vUE 101 (e.g., Figure 3 UEs A to D or other UEs such as vUE 201) performing V2X transmissions for a given V2X service can be within or outside the coverage area at any given time. Additionally, the quality of service (QoS) expected to be provided to vUEs 101, 102 should not be significantly affected based on their coverage status.

[0085] NR V2X includes two different resource allocation / scheduling operation modes on the sidelink: Mode 1 and Mode 1. In Mode 1 or the first mode, the gNB 210 or BS, for example, can schedule SL resources for the UEs for SL transmissions. In Mode 2 or the second mode, the UE 101 can autonomously or independently determine transmission resources within the SL resources configured by the gNB 210, BS network or pre-configured SL resources, such that the BS does not schedule the SL.

[0086] Although the operations in Mode 1 can be under the control of the BS or gNB 210, for Mode 2, in order to ensure the above QoS requirements, some mechanisms for admission control need to be developed, where all V2X transmissions via shared sidelink resources take into account the channel load status. In LTE, such congestion control mechanisms consider the ProSe per-packet priority (PPPP) (ProSe per-packet priority, defined for V2X on the PC5 connection in clause 5.4.6.1 of TS 24.404) and the channel busy rate CBR to control the transmission Tx parameters in sidelink communication, such as the Tx power at each peer device like each UE 102 or vUE 201, 426, or UE A to D. This ensures that the network (NW) can still mediate the transmission of V2X packets based on the priority of V2X packets in a somewhat decentralized manner, as in Mode 2.

[0087] For NR, similar congestion control metrics are expected to be defined (e.g., based on the average on subchannels of the Tx resource pool), and they can be regarded as an indication of the current channel load status. In addition, the NR V2X QoS mechanism has been redesigned from scratch to be more robust and comprehensive than the simplified PPP and ProSe per-packet reliability (PPPR) metrics in LTE. Any given packet is expected to have a PC5 quality indicator ((PQI), where PC5 refers to the sidelink interface between peer UEs) and an additional identifier associated with it, such as the PC5 QoS flow ID (QFI) (which can be directly mapped to the PQI or defined as a scalar value). The QFI can be mapped or mapped to specific QoS requirements to be met when transmitting the packet. Therefore, at least the PQI can be regarded as the QoS determinant for the packet.

[0088] In the case where the above information is available at one or more vUEs, admission control can be performed at the AS layer. In addition to the packet itself, the V2X service that generates a given packet can also be considered during the admission control process to determine whether the packet can be transmitted via the AS layer in sidelink transmission. In this regard, different consideration factors can be configured when determining or configuring authorized / unauthorized transmissions, including admission control per V2X service only, admission control per packet only, or admission control based on both per packet and per service control.

[0089] In one embodiment, once a given V2X UE 101 decides to initiate a specific V2X service, the vUE 101 first checks whether it is authorized to perform V2X transmissions on the sidelink frequency of interest. This operation can be based on the V2X service or V2X service type, which can include the priority level of the V2X service, including one or more services such as queuing operations, autonomous driving, sensor sharing, intelligent transportation services (ITS), etc. The NW or gNB 101 can configure the mapping as a configuration mapping or configuration mapping table 450 between the specific V2X service and the carrier frequency, such as the V2X to SL carrier mapping table 452, so that according to such a mapping, if not allowed, the UE or vUe 101, 102, etc. are prohibited from performing any V2X transmissions for the specific V2X service. The mapping 450 can be configured by the NW via either dedicated RRC signaling or broadcast system information, or the mapping can be hard-coded as predefined in this specification. This type of per-V2X service access control does not consider the dynamic channel conditions on the sidelink.

[0090] Therefore, in other embodiments, the access control scheme can consider each packet and the associated QoS of each packet. In this embodiment, for example, the UE or vUe 101, 102, etc. still determine or check whether they can initiate any V2X transmissions on a given PC5 sidelink frequency based on the NW authorization via the configuration mapping table 450. However, this is independent of the V2X service initiated at the UE or vUe 101, 102, etc. Additionally, the UE or vUe 101, 102, etc. can also be a configuration mapping 456, where the CBR-QoS standard is mapped by the network to one or more TX parameter configurations. If V2X transmission is allowed, the UE then performs sidelink measurements for the channel conditions and determines the channel load status (e.g., CBR). In addition or alternatively, this information can be used together with the QoS information of each packet passed down to the AS layer and the CBR-QoS standard mapped by the NW configuration mapping 454 to determine (for each packet) whether it can be transmitted. There can be at least two methods or schemes for implementing this per-packet access control.

[0091] In the first method, for example, the NW may only indicate QoS information, i.e., regardless of the current channel load state, the PQI (and any additional QoS decisions, such as latency tolerance or reliability threshold) may be indicated via system information broadcast for a given Tx pool or a set of sidelink communication V2X participants 440 or via a dedicated RRC configuration configured from a higher layer, where the UE or vUe 101, 102, etc. cannot transmit any V2X packets with a QoS other than the indicated QoS. Since the PQI may specifically be a combination of several QoS factors, a simple comparison may or may not always be feasible, and an exact indication of which PQI values are exactly allowed / not allowed to be transmitted may be conveyed via a configuration mapping 450 without or without the need for mappings 452 and 454.

[0092] In the second method, since this method may also consider the channel load state, it may be flexible, and a CBR-PQI-Tx parameter table 458 may be configured at the UE or vUe 101, 102, etc. For example, the vUE 101 queries this table 458 for each packet to determine the exact TX parameters (e.g., MCS index, TX power, number of potential retransmissions, etc.) to be applied to the packet. This allows for a more finely tuned control of the congestion level based on the V2X QoS indicator / identifier (VQI) of each packet. For example, even if the channel load (or CBR) is relatively high or sufficient to meet a priority threshold, a packet with a VQI that corresponds to a very high priority may be allowed to be transmitted, but another packet (from the same or a different V2X service) with a VQI indicating a lower priority, not meeting the priority threshold, or a different low priority threshold may be prohibited from being transmitted. In addition to priority, other QoS factors / criteria may also be considered. Additionally, in order to implement the behavior in the configuration mapping 450 (e.g., QoS / CBR to Tx parameters (parameters) 456, etc.), a specific point in the mapping table 450 corresponding to no transmission (e.g., unused or reserved values) may be reserved, which essentially means that regardless of the PQI of the V2X packet, the UE 101, etc. cannot transmit the packet via the sidelink interface.

[0093] In another embodiment, combinations of factors or configuration maps 450 may also be considered such that configuration maps 452 and 454 are considered simultaneously, along with potentially other factors or mapping criteria (e.g., 456 or 458). For example, when determining whether a packet can be transmitted via the AS layer as part of, for example, SL communication, both the QoS of the V2X service and the V2X packet can be considered together with the channel load status (e.g., CBR) that can be defined or considered. In this case, for example, when initiating a V2X service, a UE 101 etc. can utilize the current load status of channel 414 or otherwise determine whether the V2X service has been authorized or initiated. This can be achieved by the NW configuring a map 450 between the V2X service and the channel load (e.g., CBR) 452, for example, additionally or in combination considering the map between the V2X service and the sidelink frequency, as when only considering the configuration map 450 related to the V2X service type (e.g., 452 or 454). Even if it may be allowed to transmit a V2X service on a V2X frequency, if, for example, the channel load is too high or meets a channel load threshold, generating and submitting a packet to the AS layer for transmission may not be allowed. The NW can achieve this behavior by configuring either the V2X service - frequency map 452 or the V2X service - CBR map 454 jointly or separately. For example, if the transmission of a high - priority service is allowed based on the above criteria, a per - packet congestion control mechanism can be further applied (e.g., via map 456 or 458) to the packets of that service to ensure that only essential packets are transmitted via the sidelink interface. The V2X service can also refer to new or different QoS flows from the higher layer that belong to the initiated V2X service, for example, having one or more different V2X QoSs. The flow can have a QoS flow ID (QFI) which can be used to determine the priority of the packet and the mapping when compared with one or more configuration maps 450.

[0094] While V2X services that consider admission control or congestion control only on channel 414 for SL communication may be fairly simple and lightweight in terms of complexity and signaling overhead, it does not necessarily consider the channel load state or CBR. Each packet control scheme only considers the packet QoS for admission control, regardless of the corresponding V2X service itself. In addition or alternatively, considering the mapping 452 of V2X services to SL carriers or the mapping 454 of V2X services to channel loads, with or without the packet-based mappings 456 or 458, may not be preferred for cases where the channel conditions change rapidly. First, this may seem to cover all infrastructure and include each packet's V2X service and QoS in consideration, which is expected to be more useful if it is assumed that typical V2X services may generate V2X packets only within a narrow QoS band / range. Specifically, if the V2X service "priority" itself is not fully captured by the QoS / PQI of the V2X packets generated by the V2X service, a combination of both packet and service consideration factors can be utilized. In the most general case, if any V2X service can generate packets covering the entire QoS / PQI range, the combination of configured mappings may result in some services that would otherwise be allowed by other implementations being prohibited, even if these services have high-priority packets to be sent. From the perspective of signaling overhead, considering two or more configured mappings 450 seems to have the most overhead, as the mapping between the service and CBR may also be indicated.

[0095] Although the methods described in this disclosure are shown and described herein as a series of acts or events, it should be understood that the order of such acts or events shown is not to be construed in a limiting sense. For example, some acts may occur in a different order and / or concurrently with other acts or events than those shown and / or described herein. Additionally, not all of the acts shown may be required to implement one or more aspects or embodiments of the present specification. Further, one or more of the acts depicted herein may be carried out in one or more separate acts and / or phases. For ease of description, reference may be made to the above figures. However, the methods are not limited to any specific implementation or example provided within this disclosure and may be applied to any of the systems disclosed herein.

[0096] Reference Figure 5 , which shows an exemplary process flow 500 for a network device or component (e.g., UE 101, gNB 211, or other network component) to perform admission / congestion control operations for V2X communication between UE peer devices on a sidelink channel.

[0097] At 510, process flow 500 includes performing an access control scheme via a processing circuit. This may include determining a configuration map at 520. At 530, the process flow includes generating a determination as to whether to authorize the transmission of a PC5 packet for V2X communication over a sidelink channel based on the configuration map and one or more criteria. At 540, the process flow may include transmitting the PC5 packet over a sidelink channel of a new radio (NR) sidelink based on the determination.

[0098] Process flow 500 may also include determining whether to authorize the transmission of a PC5 packet based on the V2X service of the V2X communication and the sidelink frequency corresponding to the configuration map. Alternatively or in addition, process flow 500 may include determining whether to authorize the transmission of a PC5 packet based on a QoS factor associated with the PC5 packet and one or more dynamic channel conditions mapped to transmission parameters on the sidelink channel.

[0099] For example, the one or more dynamic channel conditions may include a channel load status or a channel busy rate (CBR). The QoS factor (or criterion) may include a QoS criterion, including at least one of: a PC5 quality indicator (PQI) value, a priority of the V2X service, a priority of the PC5 packet, or a V2X QoS indication (VQI). The V2X service may include at least one of the following: queuing operation, autonomous driving, sensor sharing, or intelligent transportation service (ITS), and wherein the transmission parameters include a modulation and coding scheme (MCS) index, a transmission power, or a number of potential retransmissions.

[0100] Other implementations of process flow 500 may include processing a first configuration map and a second configuration map jointly or independently of each other as the configuration map, where the first configuration map includes the V2X service of the V2X communication mapped to the sidelink frequency, and the second configuration map includes one or more V2X services mapped to the channel load status. Here, if the first configuration map fails due to a packet of an unauthorized service, the process flow may abort. For example, if it is authorized, the second configuration map or an additional configuration map may be compared with the packet to determine whether to further fine-tune the authorization / admission for sidelink transmission.

[0101] The one or more criteria may include at least one of the following: one or more dynamic channel conditions on the sidelink channel, PC5 quality indication (PQI), one or more quality of service (QoS) factors, or one or more transmission parameters. Then, a determination as to whether the one or more transmission parameters are applied to the PC5 packet may be performed based on at least one of the VQI, PQI, or CBR of the PC5 packet mapped in the configuration map.

[0102] On the other hand, points of the configuration mapping that are reserved and not used for transmission, or value ranges of any parameter in this document that are reserved and not used for transmission, can be identified as unused or reserved values on the sidelink channel.

[0103] Reference Figure 6 , which shows an exemplary process flow 600 for a network device or component (e.g., UE 101, gNB 210, or other network components) to perform admission / congestion control operations for V2X communication between UE peer devices on the NR sidelink channel.

[0104] At 610, the process flow 600 includes implementing V2X communication using the sidelink channel of the NR sidelink channel based on an admission control scheme or a congestion control scheme.

[0105] At 620, a configuration mapping is determined based on one or more criteria. At 630, an indication of whether to authorize the transmission of one or more packets is generated based on the configuration mapping. The configuration mapping can be determined as a configuration mapping table based on the one or more criteria, including at least one of per-packet or per-V2X service and at least one of the priority levels of the QoS factors of the one or more packets or the priority levels of the V2X services.

[0106] In one embodiment, the process flow 600 may further include configuring a first configuration mapping table that includes a mapping of V2X services to sidelink frequencies. A second configuration mapping table may be configured to include a second mapping of V2X services to the channel busy rate of the sidelink channel. An indication of whether to use the first configuration mapping table, the second configuration mapping table, or both the first configuration mapping table and the second configuration mapping table to determine whether to authorize the transmission of the one or more packets via the access stratum (AS) may be provided.

[0107] Reference Figure 7, the figure shows a block diagram of a user equipment wireless communication device (UE) or other network device / component (e.g., UE1, UE2, UE3, UE4, or other participating entities) configured to perform direct peer-to-peer communication according to various aspects described herein. UE device 700 includes: one or more processors 710 (e.g., one or more baseband processors), the one or more processors including processing circuitry and associated interfaces; transceiver circuitry 720 (e.g., including RF circuitry, which may include transmitter circuitry (e.g., associated with one or more transmit chains) and / or receiver circuitry (e.g., associated with one or more receive chains), and the transmitter circuitry and receiver circuitry may employ common circuit elements, different circuit elements, or a combination thereof); and a memory 730 (which may include any of a variety of storage media and may store instructions and / or data associated with one or more of the processor 710 or the transceiver circuitry 720).

[0108] In various embodiments (aspects) discussed herein, signals and / or messages may be generated and output for transmission, and / or the transmitted messages may be received and processed. Depending on the type of signal or message generated, output for transmission (e.g., by processor 710, processor 710, etc.) may include one or more of the following operations: generating a set of associated bits encoding the content of the signal or message; encoding (e.g., may include adding a cyclic redundancy check (CRC) and / or encoding via turbo codes, low density parity check (LDPC) codes, tail-biting convolutional codes (TBCC), etc.); scrambling (e.g., based on a scrambling seed); modulating (e.g., via one of binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), or some form of quadrature amplitude modulation (QAM), etc.); and / or resource mapping (e.g., mapping to a scheduled set of resources, mapping to a set of time and frequency resources authorized for uplink transmission, etc.). Depending on the type of signal or message received, processing (e.g., by processor 710) may include one or more of the following operations: identifying the physical resources associated with the signal / message, detecting the signal / message, resource element group deinterleaving, demodulating, descrambling, and / or decoding.

[0109] As used in this specification, the term "processor" can generally refer to any computing processing unit or device, including but not limited to a single-core processor; a single processor with software multi-threaded execution capabilities; a multi-core processor; a multi-core processor with software multi-threaded execution capabilities; a multi-core processor with hardware multi-threading technology; a parallel platform; and a parallel platform with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, a programmable logic controller, a complex programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions and / or processes described herein. A processor can utilize nanoscale architectures, such as but not limited to molecule- and quantum-dot-based transistors, switches, and gates, to optimize space usage or enhance the performance of a mobile device. A processor can also be implemented as a combination of computing processing units.

[0110] Embodiments (implementations) can include subject matter such as a method, an apparatus for performing actions or blocks of the method, and at least one machine-readable medium that includes instructions that, when executed by a machine (e.g., a processor with a memory, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc.), cause the machine to perform actions of a method, an apparatus, or a system for concurrent communication using multiple communication technologies according to the embodiments and examples described herein.

[0111] In a first set of embodiments, Embodiment 1 includes an admission control method that includes: determining or causing to determine whether to allow transmission of a packet via a sidelink (SL) based on a configuration mapping table; and when transmission of the packet via the SL is allowed, transmitting or causing to transmit the packet via the SL.

[0112] Embodiment 2 includes the method according to Embodiment 1 and / or some other embodiments herein, where the mapping table includes a mapping of services to carrier frequencies and indicates services authorized and / or unauthorized for SL transmission, and the method includes: identifying or causing to identify a trigger to initiate a service; when the service is authorized for SL transmission according to the mapping table, determining or causing to determine that transmission of the packet via the SL is allowed; and when transmission of the packet via the SL is allowed, transmitting or causing to transmit the packet on a carrier frequency corresponding to the service in the mapping table.

[0113] Embodiment 3 includes the method according to Embodiment 2 and / or some other embodiments herein, further including: determining or causing to determine that a service is authorized for SL transmission based on the service type associated with the packet.

[0114] Example 4 includes the method according to Example 1 and / or some other embodiments herein, and further includes: determining or causing to determine whether to authorize the transmission of packets on the SL frequency, regardless of the initiated service.

[0115] Example 5 includes the method according to Example 4 and / or some other embodiments herein, wherein when allowing the transmission of packets via SL, the method includes: performing or causing to perform SL measurements on the channel conditions of the SL channel at the SL frequency.

[0116] Example 6 includes the method according to Examples 4 to 5 and / or some other embodiments herein, wherein determining to allow the transmission of packets via SL includes: determining or causing to determine to allow the transmission of packets via SL based on QoS information and the current channel load status.

[0117] Example 7 includes the method according to Examples 4 to 5 and / or some other embodiments herein, wherein determining to allow the transmission of packets via SL includes: determining or causing to determine to allow the transmission of packets via SL based on QoS information, regardless of the current channel load status.

[0118] Example 8 includes the method according to Example 7 and / or some other embodiments herein, wherein determining to allow the transmission of packets via SL includes: when the packet has a worse QoS than the QoS requirements indicated by the QoS information, determining or causing to determine to allow the transmission of packets via SL; and when the packet has a QoS equivalent to or better than the QoS requirements indicated by the QoS information, determining or causing to determine not to allow the transmission of packets via SL.

[0119] Example 9 includes the method according to Examples 7 to 8 and / or some other embodiments herein, wherein the QoS information indicates zero or more of a PC5 quality indicator (PQI), a delay tolerance, and a reliability threshold.

[0120] Example 10 includes the method according to Example 9 and / or some other embodiments herein, wherein the QoS information indicates one or more PQI values that allow or do not allow transmission.

[0121] Example 11 includes the method according to Examples 7 to 10 and / or some other embodiments herein, wherein the QoS information is indicated in the received system information broadcast for a transmission (Tx) pool or in the RRC configuration of the received radio resource control (RRC) message.

[0122] Example 12 includes the method according to Example 6 and / or some other embodiments herein, and further includes: determining or causing to determine the channel load status of the SL channel based on a channel busy rate (CBR) value.

[0123] Example 13 includes the method according to Example 6, 12, and / or some other embodiments herein, wherein the mapping table includes a mapping of CBR to QoS criteria (or PQI) to Tx parameters, and further includes: determining or causing to determine one or more Tx parameters corresponding to the CBR and / or PQI in the mapping table to be applied to the packet.

[0124] Example 14 includes the method according to Example 13 and / or some other embodiments herein, wherein the Tx parameters include one or more of an MCS index, Tx power, and the number of potential retransmissions.

[0125] Example 15 includes the method according to Examples 13 to 14 and / or some other embodiments herein, wherein the mapping table includes unused or reserved values that indicate that the packet cannot be transmitted via SL regardless of the PQI associated with the packet.

[0126] Example 16 includes the method according to Example 1 and / or some other embodiments herein, wherein the mapping table includes a mapping of service to carrier frequency to CBR, and indicates services authorized and / or unauthorized for SL transmission, and the method includes: identifying or causing to identify whether a service has been initiated based on the CBR corresponding to the service in the mapping table; when the service has been initiated and when the service is authorized for SL transmission, determining or causing to determine that packet transmission via SL is allowed according to the mapping table; when the service is authorized for SL transmission, applying or causing to apply a per-packet congestion control mechanism to the packets of the service; and when packet transmission via SL is allowed, transmitting or causing to transmit the packet on the carrier frequency corresponding to the service in the mapping table.

[0127] Example 17 includes the method according to Example 17 and / or some other embodiments herein, wherein the mapping of service to carrier frequency to CBR includes a first mapping and a second mapping, the first mapping is a mapping of service to carrier frequency, and the second mapping is a mapping of service to CBR, and wherein the first mapping and the second mapping are configured jointly or separately.

[0128] Example 18 includes the method according to Examples 1 to 17 and / or some other embodiments herein, further including: determining or causing to determine the mapping table or parameters for generating the mapping table based on information included in the received RRC message or information included in the broadcast system information message.

[0129] Example 19 includes the method according to Examples 1 to 17 and / or some other embodiments herein, further including: determining or causing to determine the mapping table or parameters for generating the mapping table based on information hard-coded in the memory circuit.

[0130] Embodiment 20 includes the method according to Embodiments 1 to 19 and / or some other embodiments herein, wherein the method is performed by baseband circuitry implemented by a user equipment (UE).

[0131] Embodiment 21 includes a method for admission and congestion control for V2X communication on a NR sidelink.

[0132] Embodiment 22 includes the method according to Embodiment 21 and / or some other embodiments herein, wherein multiple methods for implementing admission and congestion control are defined.

[0133] Embodiment 23 includes the method according to Embodiment 22 and / or some other embodiments herein, wherein the multiple methods for implementing admission and congestion control include for each V2X service where the NW provides authorization information to the vehicle UE in the form of a mapping between the V2X service and the carrier frequency, based on which the UE can determine whether to allow transmission for a given V2X service.

[0134] Embodiment 24 includes the method according to Embodiments 22 to 23 and / or some other embodiments herein, wherein the multiple methods for implementing admission and congestion control include for each V2X packet where the UE is configured with a channel busy rate to QoS to TX parameter configuration table, which can be used to determine whether a V2X packet can be transmitted.

[0135] Embodiment 25 includes the method according to Embodiment 24 and / or some other embodiments herein, wherein the NW only indicates QoS information in the form of specific VQI / PQI values, such that the UE is not allowed to transmit packets with these values regardless of the channel state.

[0136] Embodiment 26 includes the method according to Embodiment 25 and / or some other embodiments herein, wherein the NW indicates the QoS information in a cell-specific manner using system information or in a UE-specific manner via dedicated RRC signaling.

[0137] Embodiment 27 includes the method according to Embodiment 24 and / or some other embodiments herein, wherein the NW includes a mapping table from CBR to PQI values and TX parameter configuration to consider the channel load when allowing transmission of a given V2X packet.

[0138] Embodiment 28 includes the method according to Embodiments 22 to 24 and / or some other embodiments herein, wherein a combination of per-packet and per-service can be defined, where the network configures a channel load criterion mapped to a specific V2X service, such that the UE first checks whether a packet from a given service can be allowed to enter the system, and if the configuration allows, further applies the per-packet criterion to control transmission on the sidelink.

[0139] Embodiment 29 includes the method according to Embodiments 21 to 28 and / or some other embodiments herein, wherein the method is performed by baseband circuitry implemented by a user equipment (UE).

[0140] Embodiment 30 includes a method to be performed by a radio access network (RAN) node, the method comprising: determining or causing to determine a mapping table for sidelink admission control according to any one of Embodiments 1 to 29; generating or causing to generate a message to indicate the mapping table or parameters for generating the mapping table; and transmitting or causing to transmit the message to a user equipment (UE).

[0141] Embodiment 31 may include an apparatus comprising means for performing one or more elements of the method according to any one of Embodiments 1 to 30 or related thereto or any other method or process described herein.

[0142] Embodiment 32 may include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method according to any one of Embodiments 1 to 30 or related thereto or any other method or process described herein.

[0143] Embodiment 33 may include an apparatus comprising logic components, modules or circuits for performing one or more elements of the method according to any one of Embodiments 1 to 30 or related thereto or any other method or process described herein.

[0144] Embodiment 34 may include the method, technique or process according to any one of Embodiments 1 to 30 or related thereto, or a part or component thereof.

[0145] Embodiment 35 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, technique or process according to any one of Embodiments 1 to 30 or related thereto or a part thereof.

[0146] Embodiment 36 may include a signal according to any one of Embodiments 1 to 30 or related thereto, or a part or component thereof.

[0147] Embodiment 37 may include a datagram, packet, frame, segment, protocol data unit (PDU) or message according to any one of Embodiments 1 to 30 or related thereto, or a part or component thereof, or otherwise described in the present disclosure.

[0148] Example 38 may include a signal encoded with data as described in or related to any one of Examples 1 to 30, or a part or component thereof, or otherwise described in the present disclosure.

[0149] Example 39 may include a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any one of Examples 1 to 30, or a part or component thereof, or otherwise described in the present disclosure.

[0150] Example 40 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process as described in or related to any one of Examples 1 to 30, or a part thereof.

[0151] Example 41 may include a computer program that includes instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process as described in or related to any one of Examples 1 to 30, or a part thereof.

[0152] Example 42 may include a signal in a wireless network as shown and described herein.

[0153] Example 43 may include a method of communicating in a wireless network as shown and described herein.

[0154] Example 44 may include a system for providing wireless communication as shown and described herein.

[0155] Example 45 may include a device for providing wireless communication as shown and described herein.

[0156] Example 50 is a device adopted in a user equipment (UE), including: a processing circuit configured to: implement vehicle-to-everything (V2X) communication using a sidelink channel of a new radio (NR) sidelink based on an admission control scheme or a congestion control scheme; execute an admission control scheme or a congestion control scheme, including: determining a configuration mapping; and determining whether to authorize transmission of a packet through the sidelink channel based on the configuration mapping.

[0157] Example 51 includes the subject matter according to Example 50, wherein the configuration mapping is based on at least one of the following: V2X service, packet of V2X communication, sidelink frequency, PC5 quality indicator (PQI), one or more quality of service (QoS) criteria, transmission parameters, channel load status, or priority level of V2X service.

[0158] Example 52 includes the subject matter according to any one of Examples 50 to 51, wherein the processing circuitry is further configured to determine whether to authorize transmission of a packet via a sidelink channel through an access stratum (AS) layer based on the priority of a V2X service of V2X communication.

[0159] Example 53 includes the subject matter according to any one of Examples 50 to 52, wherein the V2X service includes at least one of the following: platooning operation, autonomous driving, sensor sharing, or intelligent transportation service (ITS).

[0160] Example 54 includes the subject matter according to any one of Examples 50 to 53, wherein the processing circuitry is further configured to generate a comparison of the packet to be transmitted with a configuration mapping based on a PC5 quality indicator (PQI) or one or more quality of service (QoS) criteria to determine whether to authorize transmission of the packet through the sidelink channel at a sidelink frequency.

[0161] Example 55 includes the subject matter according to any one of Examples 50 to 54, wherein the processing circuitry is further configured to determine whether to authorize transmission of a packet through the AS layer based on the V2X service associated with the sidelink frequency mapped to the configuration mapping.

[0162] Example 56 includes the subject matter according to any one of Examples 50 to 55, wherein the processing circuitry is further configured to receive the configuration mapping via radio resource control (RRC) signaling or broadcast system information.

[0163] Example 57 includes the subject matter according to any one of Examples 50 to 56, wherein the processing circuitry is further configured to: perform sidelink measurements of one or more channel conditions of the sidelink channel; determine a channel load status or a channel busy rate (CBR) based on the sidelink measurements; and determine whether to authorize transmission of a packet through the sidelink channel based on the one or more QoS criteria and the channel load status or CBR of the configuration mapping.

[0164] Example 58 includes the subject matter according to any one of Examples 50 to 57, wherein the configuration mapping includes one or more mapped transmission parameters, one or more PQIs, and one or more CBRs, and the processing circuitry is further configured to determine whether to authorize transmission of a packet through the sidelink channel based on a comparison of the V2X QoS indication (VQI) of the packet with the configuration mapping.

[0165] Example 59 includes the subject matter according to any one of Examples 50 to 58, wherein the processing circuitry is further configured to: determine a priority of a packet based on a V2X service or a QoS flow ID (QFI) belonging to a V2X service; and determine authorization to transmit the packet via an AS layer for transmitting V2X communication as peer-to-peer communication to another vehicle UE (vUE) device based on a mapping of the V2X service to a sidelink frequency, a mapping of the V2X service to a CBR, or both a mapping of the V2X service to a sidelink frequency and a mapping of the V2X service to a CBR.

[0166] Example 60 is a tangible computer-readable storage device storing executable instructions that, in response to execution, cause one or more processors of a vehicle user equipment (vUE) to perform operations including: performing an admission control scheme via processing circuitry, including: determining a configuration mapping; generating a determination of whether to authorize transmission of a PC5 packet for V2X communication via a sidelink channel based on the configuration mapping and one or more criteria; and transmitting the PC5 packet via a sidelink channel of a new radio (NR) sidelink based on the determination.

[0167] Example 61 includes the subject matter according to Example 60, the operations further including at least one of: determining whether to authorize transmission of the PC5 packet based on a V2X service of the V2X communication and a sidelink frequency corresponding to the configuration mapping; or determining whether to authorize transmission of the PC5 packet based on a QoS factor associated with the PC5 packet and one or more dynamic channel conditions mapped to one or more transmission parameters on the sidelink channel.

[0168] Example 62 includes the subject matter according to any one of Examples 60 to 61, wherein the one or more dynamic channel conditions include a channel load state or a channel busy rate (CBR), wherein the QoS factor includes QoS criteria including at least one of: a PC5 quality indicator (PQI) value, a priority of the V2X service, a priority of the PC5 packet, or a V2X QoS indicator (VQI), wherein the V2X service includes at least one of: queuing operation, autonomous driving, sensor sharing, or intelligent transportation service (ITS), and wherein the transmission parameter includes at least one of: a modulation and coding scheme (MCS) index, a transmission power, or a number of potential retransmissions.

[0169] Example 63 includes the subject matter according to any one of Examples 60 to 62, the operations further including: processing a first configuration mapping and a second configuration mapping jointly or independently as the configuration mapping, wherein the first configuration mapping includes a V2X service of the V2X communication mapped to a sidelink frequency, and the second configuration mapping includes one or more V2X services mapped to a channel load state.

[0170] Example 64 includes the subject matter according to any one of Examples 60 to 63, wherein the one or more criteria include at least one of the following: one or more dynamic channel conditions on a sidelink channel, a PC5 quality indication (PQI), one or more quality of service (QoS) factors, or one or more transmission parameters.

[0171] Example 65 includes the subject matter according to any one of Examples 60 to 64, and the operations further include: determining one or more transmission parameters to be applied to a PC5 packet based on at least one of a VQI, a PQI, or a CBR of the PC5 packet mapped by a configuration mapping.

[0172] Example 66 includes the subject matter according to any one of Examples 60 to 65, and the operations further include: identifying points in the configuration mapping that are reserved and not used for transmission as unused or reserved values on the sidelink channel.

[0173] Example 67 is a tangible computer-readable storage device that stores executable instructions that, in response to execution, cause one or more processors of a vehicle user equipment (vUE) or a next-generation node B (gNB) to perform operations including: implementing vehicle-to-everything (V2X) communication using a sidelink channel of a new radio (NR) sidelink based on an admission control scheme or a congestion control scheme; determining a configuration mapping based on one or more criteria; and indicating whether to authorize transmission of one or more packets over the sidelink channel based on the configuration mapping.

[0174] Example 68 includes the subject matter according to Example 67, and the operations further include: determining a configuration mapping table of the configuration mapping based on the one or more criteria, the one or more criteria including at least one of per-packet or per-V2X service and at least one of a priority level of a quality of service (QoS) factor of the one or more packets or a priority level of a V2X service.

[0175] Example 69 includes the subject matter according to any one of Examples 67 to 68, and the operations further include: configuring a first configuration mapping table that includes a mapping of V2X services to sidelink frequencies; configuring a second configuration mapping table that includes a second mapping of V2X services to a channel busy rate of a sidelink channel; and providing an indication of whether to use the first configuration mapping table, the second configuration mapping table, or both the first configuration mapping table and the second configuration mapping table to determine whether to authorize transmission of one or more packets via an access stratum (AS) layer.

[0176] In addition, various aspects or features described herein can be implemented as a method, apparatus, or article of manufacture using standard programming and / or engineering techniques. As used herein, the term "article of manufacture" is intended to encompass a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media can include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., EPROMs, cards, sticks, key drives, etc.). Additionally, the various storage media described herein can represent one or more devices and / or other machine-readable media for storing information. The term "machine-readable media" can include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data. Additionally, a computer program product can include a computer-readable medium having one or more instructions or codes that are operable to cause a computer to perform the functions described herein.

[0177] A communication medium embodies computer-readable instructions, data structures, program modules, or other structured or unstructured data in a data signal such as a modulated data signal, e.g., a carrier wave or other transmission mechanism, and includes any information delivery or transmission medium. The term "modulated data signal" or signal refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0178] Exemplary storage media can be coupled to a processor such that the processor can read information from, and write information to, the storage media. In an alternative, the storage media can be integrated with the processor. Additionally, in some aspects, the processor and the storage media can reside in an ASIC. Further, the ASIC can reside in a user terminal. In an alternative, the processor and the storage media can reside in the user terminal as discrete components. Additionally, in some aspects, the processes and / or actions of a method or algorithm can reside as code and / or instructions in one or any combination or collection on a machine-readable medium and / or a computer-readable medium and can be incorporated into a computer program product.

[0179] In this regard, while the subject matter disclosed herein has been described in connection with various embodiments and the corresponding drawings, it should be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments to perform the same, similar, alternative, or substitute functions of the disclosed subject matter without departing from the described embodiments. Accordingly, the disclosed subject matter should not be limited to any single embodiment described herein, but should be construed in accordance with the breadth and scope of the following appended claims.

[0180] In particular, with respect to the various functions performed by the above-described components (components, devices, circuits, systems, etc.), unless otherwise specified, the terms used to describe such components (including references to "means") are intended to correspond to any component or structure that performs the specified function of the described component (e.g., functionally equivalent), even if not structurally equivalent to the disclosed structure that performs the function in the exemplary specific implementations of the present disclosure shown herein. Additionally, although a particular feature has been disclosed with respect to only one of several specific implementations, for any given or particular application, such feature may be combined with one or more other features of one or more other specific implementations, which may be desirable and advantageous.

Claims

1. A baseband processor, the baseband processor comprising: A processing circuit configured to perform operations when executing instructions stored in a memory, the operations including: Implement vehicle-to-everything (V2X) communication using a sidelink channel based on an access control scheme; Execute the access control scheme, including: Determine a configuration mapping of V2X services associated with a packet to associated sidelink frequencies; Determine authorization to transmit the packet via an access stratum (AS) layer over the sidelink channel at the associated sidelink frequency based on the configuration mapping, the priority of the V2X service, the carrier frequency associated with the packet, and at least one of a PC5 quality indicator (PQI) or one or more quality of service (QoS) criteria; Wherein the V2X service includes at least one of the following: platooning operation, autonomous driving, sensor sharing, or intelligent transportation service (ITS); and In response to determining authorization to transmit the packet over the sidelink channel, provide the packet to an interface with a radio frequency circuit for transmission.

2. The baseband processor according to claim 1, wherein the configuration mapping includes a configuration mapping between one or more V2X services and one or more carrier frequencies.

3. The baseband processor according to any one of claims 1 or 2, wherein the operation further comprises: Receive the configuration mapping via radio resource control (RRC) signaling or broadcast system information, or determine the configuration mapping based on information hard-coded in a memory circuit coupled to the baseband processor.

4. The baseband processor according to any one of claims 1 or 2, wherein the operation further comprises: Perform sidelink measurements of one or more channel conditions of the sidelink channel; Determine a channel load status or a channel busy rate (CBR) based on the sidelink measurements; And Determine whether to authorize transmission of the packet over the sidelink channel based on one or more QoS criteria and the channel load status or the CBR of the configuration mapping.

5. The baseband processor according to any one of claims 1 or 2, wherein the configuration mapping includes one or more mapped transmission parameters, one or more PQIs, and one or more CBRs, and the operation further comprises determining whether to authorize transmission of the packet through the sidelink channel based on a comparison of the V2X QoS indication (VQI) of the packet with the configuration mapping.

6. The baseband processor according to any one of claims 1 or 2, wherein the operation further comprises: Determine the priority of the packet based on a V2X service or a QoS flow ID (QFI) belonging to the V2X service; And Determine authorization to transmit the packet via the AS layer based on a mapping of V2X service to sidelink frequency, a mapping of V2X service to CBR, or both the mapping of V2X service to sidelink frequency and the mapping of V2X service to CBR, for transmitting the V2X communication as peer-to-peer communication to another vehicle UE (vUE) device.

7. A user equipment (UE), the user equipment (UE) comprising: A radio frequency (RF) circuit; And One or more processors configured to execute instructions stored in a memory to cause the UE: Execute an access control scheme, including: Determine a configuration mapping between one or more vehicle-to-everything (V2X) services and one or more carrier frequencies; Generate a determination of whether to authorize transmission of the PC5 packet over the sidelink channel based on a quality of service (QoS) factor associated with a PC5 packet of V2X communication, one or more dynamic channel conditions mapped to one or more transmission parameters on the sidelink channel, the configuration mapping, and one or more criteria; Wherein the one or more criteria include the V2X service associated with the PC5 packet and the carrier frequency associated with the PC5 packet; Wherein the one or more dynamic channel conditions include a channel load status or a channel busy rate (CBR); wherein the QoS factor includes a QoS criterion, and the QoS criterion includes at least one of the following: a PC5 quality indicator (PQI) value, a priority of the V2X service, a priority of the PC5 packet, or a V2X QoS indicator (VQI), wherein the V2X service includes at least one of the following: queuing operation, autonomous driving, sensor sharing, or intelligent transportation service (ITS), and wherein the transmission parameter includes at least one of the following: a modulation and coding scheme (MCS) index, a transmission power, or a number of potential retransmissions; and transmit the PC5 packet via the side - link channel of a new radio (NR) side - link based on the determination.

8. The UE according to claim 7, wherein the one or more processors further cause the UE to: Determine whether to authorize the transmission of the PC5 packet based on the V2X service of the V2X communication and the sidelink frequency corresponding to the configuration mapping.

9. The UE according to any one of claims 7 or 8, wherein the one or more processors further cause the UE to: Process the first configuration mapping and the second configuration mapping jointly or independently as the configuration mapping, wherein the first configuration mapping includes the V2X service of the V2X communication mapped to the sidelink frequency, and the second configuration mapping includes one or more V2X services mapped to the channel load state.

10. The UE according to claim 8, wherein the one or more criteria include at least one of the following: one or more dynamic channel conditions on the sidelink channel, PQI, one or more QoS factors, or one or more transmission parameters.

11. The UE according to any one of claims 7 or 8, wherein the one or more processors further cause the UE to: Determine one or more transmission parameters to be applied to the PC5 packet based on at least one of the VQI, PQI, or CBR of the PC5 packet mapped by the configuration mapping.

12. The UE according to any one of claims 7 or 8, wherein the one or more processors further cause the UE to: Identify the points in the configuration mapping that are reserved and not used for transmission as unused or reserved values on the sidelink channel.

13. The UE according to any one of claims 7 or 8, wherein the configuration mapping is determined based on one or more of the following: radio resource control (RRC) signaling, broadcast system information, or information hard-coded in the memory circuit of the UE.

14. A tangible computer-readable storage medium, the tangible computer-readable storage medium comprising executable instructions that, upon execution, cause one or more processors of a vehicle user equipment (vUE) or a next-generation node B (gNB) to perform operations, the operations including: Implement vehicle - to - everything (V2X) communication by using the side - link channel of a new radio (NR) side - link based on an admission control scheme or a congestion control scheme; Determine a configuration mapping based on one or more criteria; Determine a configuration mapping table of the configuration mapping based on the one or more criteria, the one or more criteria including at least one of per - packet or per - V2X service and at least one of a priority level of a quality of service (QoS) factor of the one or more packets or a priority level of the V2X service; Configure a first configuration mapping table, the first configuration mapping table including a mapping of V2X services to side - link frequencies; Configure a second configuration mapping table, the second configuration mapping table including a second mapping of V2X services to a channel busy rate of the side - link channel; Provide an indication of whether to use the first configuration mapping table, the second configuration mapping table, or both the first configuration mapping table and the second configuration mapping table to determine whether to authorize transmission of the one or more packets via an access stratum (AS) layer; and Indicate whether to authorize transmission of one or more packets via the side - link channel based on the configuration mapping.

Citation Information

Patent Citations

  • Improved support of quality of service for v2x transmissions

    EP3273634A1

  • Methods for controlling the Vehicle to everything communication and Apparatuses thereof

    KR1020170053573A