Congestion control in the sidelink intermediate layer framework

Abstract

Methods, systems, and devices for wireless communications are described. In some cases, an application enabler layer (e.g., a vehicle-to-everything (V2X) application enabler (VAE) layer) may identify a congestion control configuration that includes capabilities for collecting operational information. The application enabler layer may receive operational information from a group of user equipment (UE) based on these capabilities. The application enabler layer may then generate congestion control instructions for one or more UEs in the group of UEs based on the received operational information. Additionally or alternatively, an application enabler architecture layer (e.g., a vertical service enabler architecture layer (SEAL)) may identify a congestion control configuration that includes capabilities for collecting operational information and monitor the sidelink performance of the group of UEs based on these capabilities. The application enabler architecture layer may identify a congestion state of a communication type based on monitoring the sidelink performance.

Description

Technical Field

[0001] The following relates generally to wireless communications, and more particularly to congestion control for a sidelink midlayer framework. Background Art

[0002] Wireless communication systems have been widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, broadcasting, etc. These systems can support communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include fourth generation (4G) systems (e.g., long term evolution (LTE) systems, advanced LTE (LTE-A) systems, or LTE-A Pro systems) and fifth generation (5G) systems (which may be referred to as new radio (NR) systems). These systems may use techniques such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), or discrete Fourier transform spread orthogonal frequency division multiplexing (DFT-S-OFDM). A wireless multiple access communication system may include one or more base stations or one or more network access nodes, each of which simultaneously supports communication of multiple communication devices (or may be referred to as user equipment (UE)).

[0003] Some wireless systems may support sidelink communications (e.g., vehicle-to-vehicle (V2V), vehicle-to-everything (V2X) systems, etc.), where a UE may communicate with other UEs on allocated sidelink resources. As information sharing between sidelink devices increases and more UEs use sidelink communications, improved techniques for managing sidelink congestion may be needed to ensure efficient use of sidelink service applications within the system. Summary of the invention

[0004] The described technology relates to improved methods, systems, devices and apparatuses for supporting congestion control of a sidelink intermediate layer framework. In general, the described technology provides collection and analysis of the state of sidelink communications in a system so that a user equipment (UE) or an intermediate layer in the network (e.g., based on functions associated with the intermediate layer performed by a server or network node) can better determine whether the sidelink communication is experiencing congestion and how to alleviate the congestion (if any). Congestion monitoring can be performed on sidelink resources (e.g., sidelink resources used by devices in a vehicle-to-everything (V2X) system). The network intermediate layer for monitoring and managing congestion can include at least a V2X application enabler (VAE) layer, a vertical service enabler architecture layer (SEAL) layer, or both.

[0005] As described herein, the VAE and SEAL enhancement frameworks can introduce support for side link congestion detection and congestion management. The described techniques may include: the VAE layer understands and collects information about one or more applications running at a specific location, in a specific group, for a specific service (e.g., queues, sensor sharing, or intersection assistance, etc.), and also collects information about UE (e.g., vehicle) maneuvers (e.g., left turn, right turn, straight, lane change, merge, etc.). In addition, the SEAL layer can manage and monitor resources based on PC5 communication status, PC5 communication statistics, the number of unicast links, PC5 quality of service (QoS) information, and the like. Based on the collected information, the VAE layer can determine whether the service type can be subject to congestion control according to the determined algorithm. In addition, based on the collected information, the SEAL layer can also perform analysis to determine whether a certain type of communication is facing problems or may face problems in the future, and provide such information to the VAE layer.

[0006] The described technology can support status monitoring and congestion detection when some UEs are not in coverage but communicate with other UEs (e.g., via PC5). In the case where the UE is not in coverage, the VAE can indicate the relay or aggregation of service level status reports to the UEs in coverage, so that the UEs outside the coverage can report congestion information to the UEs in coverage. The VAE can also configure how to distribute congestion control instructions through the system. Other considerations for VAE and SEAL congestion services include: different UEs use different public land mobile networks (PLMNs). In this case, the VAE or SEAL server can be universal, or it can be placed on the user plane and accessible from different PLMNs. Alternatively, a SEAL server-to-server interface can be created so that a UE out of coverage can communicate with its home PLMN (HPLMN) VAE or SEAL server via the UE in coverage and its corresponding SEAL server. Therefore, side link congestion can be efficiently detected and managed.

[0007] A method of wireless communication is described. The method may include: identifying a congestion control configuration at an application enabler layer, the congestion control configuration including a capability for collecting operational information; receiving the operational information from a group of user equipment (UE) according to the capability; and generating a congestion control instruction for one or more UEs in the group of UEs based on the received operational information.

[0008] An apparatus for wireless communication is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions are executable by the processor to cause the apparatus to: identify a congestion control configuration at an application enabler layer, the congestion control configuration including a capability for collecting operational information; receive the operational information from a group of user equipment (UE) according to the capability; and generate a congestion control instruction for one or more UEs in the group of UEs based on the received operational information.

[0009] Another apparatus for wireless communication is described. The apparatus may include: means for identifying, at an application enabler layer, a congestion control configuration, the congestion control configuration including a capability for collecting operational information; means for receiving the operational information from a set of user equipment (UE) according to the capability; and means for generating congestion control instructions for one or more UEs in the set of UEs based on the received operational information.

[0010] A non-transitory computer-readable medium storing code for wireless communication is described. The code may include instructions executable by a processor to: identify a congestion control configuration at an application enabler layer, the congestion control configuration including a capability for collecting operational information; receive the operational information from a set of user equipment (UE) according to the capability; and generate a congestion control instruction for one or more UEs in the set of UEs based on the received operational information.

[0011] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, units, or instructions for: sending an operation information request to a subset of the group of UEs within network coverage; and receiving the operation information from the group of UEs based on the operation information request.

[0012] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the operation information request may also include: an operation, feature, unit, or instruction for sending a reporting configuration for reporting the operation information to the subset of the group of UEs, wherein the reporting configuration includes relay instructions based on the coverage level of each UE in the group of UEs.

[0013] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the reporting configuration includes aggregation instructions associated with the relaying instructions.

[0014] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, units, or instructions for detecting congestion of a service type based on received operational information, wherein the congestion control instructions for the one or more UEs in the group of UEs may be associated with the service type and based on the detected congestion.

[0015] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, means, or instructions for sending the congestion control instructions to a UE in the group of UEs, the UE being within network coverage.

[0016] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the congestion control instruction may also include: operations, features, units, or instructions for sending an instruction distribution configuration for relaying the congestion control instruction to the UE.

[0017] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the congestion control instruction may also include: operations, features, units, or instructions for sending instruction distribution configuration to the UE via a user plane, a control plane, system information, radio resource control signaling, or a combination thereof.

[0018] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, units, or instructions for receiving congestion control information for one or more UEs in the group of UEs from an application enabler architecture layer, wherein generating the congestion control instructions for the one or more UEs in the group of UEs may be based on the received congestion control information.

[0019] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, units, or instructions for: identifying an operation information map based on the received congestion control information; and sending an operation information trigger with relay instructions to a subset of the group of UEs within the network coverage based on the operation information map.

[0020] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the operational information includes location-specific application information, sidelink group-specific information, connected vehicle service-specific information, UE mobility information, or a combination thereof.

[0021] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the congestion control instructions include message generation rate adjustments, application communication mode adjustments, prioritization of underlying communication types, or a combination thereof.

[0022] In some examples of the methods, devices, and non-transitory computer-readable media described herein, the application enabler layer includes a vehicle networking application enabler layer that communicates with a public vehicle networking server shared by a group of public land mobile networks or a vehicle networking server accessible from each of the group of public land mobile networks on a user plane.

[0023] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, identifying at the application enabler layer the congestion control configuration including the ability to collect operational information in the application enabler layer includes: executing instructions associated with the application enabler layer at an application server to identify the congestion control configuration, and the application enabler layer includes a connected vehicle application enabler layer.

[0024] A method of wireless communication is described. The method may include: identifying a congestion control configuration at an application enabler architecture layer, the congestion control configuration including a capability for collecting operational information; monitoring a sidelink performance of a group of user equipment (UE) based on the capability; and identifying a congestion state of a communication type based on monitoring the sidelink performance.

[0025] An apparatus for wireless communication is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions are executable by the processor to cause the apparatus to: identify a congestion control configuration at an application enabler architecture layer, the congestion control configuration including a capability for collecting operational information; monitor sidelink performance of a group of user equipment (UE) based on the capability; and identify a congestion state of a communication type based on monitoring the sidelink performance.

[0026] Another apparatus for wireless communication is described. The apparatus may include: means for identifying a congestion control configuration at an application enabler architecture layer, the congestion control configuration including a capability for collecting operational information; means for monitoring sidelink performance of a group of user equipment (UE) based on the capability; and means for identifying a congestion state of a communication type based on monitoring the sidelink performance.

[0027] A non-transitory computer-readable medium storing code for wireless communication is described. The code may include instructions executable by a processor to: identify a congestion control configuration at an application enabler architecture layer, the congestion control configuration including capabilities for collecting operational information; monitor sidelink performance of a group of user equipment (UE) based on the capabilities; and identify a congestion state of a communication type based on monitoring the sidelink performance.

[0028] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, means, or instructions for managing sidelink operations of the communication type based on identifying the congestion state.

[0029] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, means, or instructions for sending congestion control information for one or more UEs in the group of UEs to an application enabler layer based on identifying the congestion state.

[0030] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, means, or instructions for receiving congestion control instructions for the one or more UEs in the group of UEs from the application enabler layer based on sending the congestion control information.

[0031] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the congestion control instruction includes a priority level for the underlying communication type.

[0032] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the congestion control information includes an underlying communication type.

[0033] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, identifying the congestion state of the communication type may also include operations, features, units, or instructions for: identifying potential congestion of the communication type based on a prediction based on monitoring the side link performance; and sending congestion control information for one or more UEs in the group of UEs to an application enabler layer based on identifying the potential congestion state.

[0034] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, monitoring the side link performance of the group of UEs may also include: operations, features, units, or instructions for receiving one or more side link status reports from a UE in the group of UEs, wherein the UE relays the one or more side link status reports from one or more UEs out of coverage of the group of UEs.

[0035] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the one or more sidelink status reports include an aggregated status report from each UE in the group of UEs.

[0036] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, units, or instructions for: identifying a state information mapping based on monitoring the side link performance; and sending a performance information request with relay instructions to a subset of the group of UEs within network coverage based on the state information mapping.

[0037] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the sidelink performance includes sidelink communication status, sidelink communication statistics, sidelink quality of service information, or a combination thereof.

[0038] In some examples of the methods, devices, and non-transitory computer-readable media described herein, the application enabler layer includes a vehicle networking application enabler layer that communicates with a public vehicle networking server shared by a group of public land mobile networks or a vehicle networking server accessible from each of the group of public land mobile networks on a user plane.

[0039] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, identifying at the application enabler architecture layer the congestion control configuration including the ability to collect operational information in the application enabler architecture layer includes: executing instructions associated with the application enabler architecture layer at an application server to identify the congestion control configuration, and the application enabler architecture layer includes a vertical service enabler architecture layer having an inter-server interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 An example of a system for wireless communications in accordance with aspects of the present disclosure is shown.

[0041] Figure 2 An example of a distributed wireless communication system according to aspects of the present disclosure is shown.

[0042] Figure 3 An example of a middle-tier framework according to aspects of the present disclosure is shown.

[0043] Figure 4 An example of a process flow according to aspects of the present disclosure is shown.

[0044] Figure 5 and Figure 6 A block diagram of a device according to aspects of the present disclosure is shown.

[0045] Figure 7 A block diagram of a communications manager in accordance with aspects of the present disclosure is shown.

[0046] Figure 8A diagram of a system including devices according to aspects of the present disclosure is shown.

[0047] Figures 9 to 14 A flow chart depicting a method according to aspects of the present disclosure is shown. DETAILED DESCRIPTION

[0048] A user equipment (UE) is able to communicate directly with other UEs via sidelink communications. For example, a UE may communicate with a second UE via a sidelink in a vehicle-to-everything (V2X) system. In some cases, sidelink communications (specifically, V2X communications) may become congested. The technology described herein relates to the introduction of congestion control services for sidelink (e.g., PC5) communications, because previous designs of the V2X application enabler (VAE) and vertical service enabler architecture layer (SEAL) frameworks did not address congestion monitoring or management. Previous designs of the VAE and SEAL frameworks focused on security services. Such congestion control aspects should be appropriately incorporated into the VAE and SEAL frameworks to make the system available in congested areas, because as the number of UEs increases, important times and locations for V2X service usage may be located in high congestion areas (e.g., rush hour traffic, intersections, etc.). The current V2X intermediate layer (i.e., VAE and SEAL) framework may not include services for UE communication status monitoring and congestion detection or the resulting congestion management.

[0049] According to the technology described in this article, the VAE and SEAL frameworks can be enhanced to support the detection of congestion and the management of congestion. The described technology involves introducing congestion monitoring and management for the VAE and SEAL layers (e.g., based on functions associated with layers executed by servers, devices, or network nodes). Due to the nature of sidelink (e.g., PC5) communications, state monitoring and congestion detection may support scenarios where some UEs are not within coverage but communicate with other UEs via PC5. Specifically, the VAE layer understands and should collect information about applications running at a specific location, in a specific group, for a specific service (e.g., queue, sensor sharing, or intersection assistance, etc.), and also collects information about UE (e.g., vehicle) speed and / or directional maneuvers (e.g., left turn, right turn, straight, lane change, merge, etc.). The SEAL layer can manage and monitor resources based on PC5 communication status, PC5 communication statistics, the number of unicast links, PC5 quality of service (QoS) information, etc. Based on the collected information, the VAE layer can determine whether the service type can be subject to congestion control (and adjust the message generation rate) according to the determined algorithm. Additionally, based on the information collected, the SEAL layer may also perform analysis to determine if a certain type of communication is facing problems or may face problems in the future, and provide such information to the VAE layer.

[0050] In the case where the UE is not within the coverage of the base station, the VAE server can instruct the UE within the coverage to relay or aggregate the service level status report for transmission to the UE outside the coverage, so that the UE outside the coverage can report congestion information to the UE within the coverage according to the instruction. The VAE can also configure how to distribute congestion control instructions through the V2X system (for example, the UE within the coverage can multicast instructions to the UE outside the coverage). Other considerations for congestion services at the VAE and SEAL include: different UEs use different public land mobile networks (PLMNs). In this case, the VAE or SEAL server can be universal (for example, placed in a V2X slice shared by multiple PLMNs), or it can be placed on the user plane and accessible from different PLMNs. Alternatively, a SEAL server-to-server interface can be created so that a UE outside the coverage can communicate with its home PLMN (HPLMN) VAE or SEAL server via the UE within the coverage and its SEAL server.

[0051] According to the technology described herein, the VAE can identify a congestion control configuration that includes the ability to collect operational information from a sidelink UE. The VAE can then receive operational information from multiple UEs based on these capabilities, and the VAE can generate congestion control instructions for one or more of the multiple UEs based on the received operational information. In addition, the SEAL can identify a congestion control configuration that includes the ability to collect operational information from the sidelink UE, and the SEAL can monitor the sidelink performance of multiple UEs based on these capabilities, and can identify the congestion state of a certain type of communication based on monitoring the sidelink performance. Therefore, the VAE and SEAL framework enhancements can improve congestion relief in sidelink communications by using congestion control services to appropriately collect communication status information and transmit congestion relief parameters to distributed systems. It should be noted that although the collection and relief of congestion for sidelink communications is described herein with reference to the V2X system, various aspects of the present disclosure may also be applicable to other systems that support sidelink communications or other systems in which various UEs communicate directly with each other.

[0052] Aspects of the disclosure are initially described in the context of wireless communication systems. Aspects of the disclosure are further depicted and described by and with reference to apparatus diagrams, system diagrams, and flow diagrams related to reclaiming resources based on sidelink feedback.

[0053] Figure 1An example of a wireless communication system 100 according to aspects of the present disclosure is shown. The wireless communication system 100 may include one or more base stations 105, one or more UEs 115, and a core network 130. In some examples, the wireless communication system 100 may be a long term evolution (LTE) network, an advanced LTE (LTE-A) network, an LTE-A Pro network, or a new radio (NR) network. In some examples, the wireless communication system 100 may support enhanced broadband communications, ultra-reliable (e.g., mission-critical) communications, low-latency communications, communications with low-cost and low-complexity devices, or any combination thereof.

[0054] Base stations 105 may be dispersed throughout a geographic area to form wireless communication system 100, and may be devices of different forms or with different capabilities. Base stations 105 and UEs 115 may communicate wirelessly via one or more communication links 125. Each base station 105 may provide a coverage area 110 over which UEs 115 and base stations 105 may establish one or more communication links 125. Coverage area 110 may be an example of a geographic area in which base stations 105 and UEs 115 may support transmission of signals according to one or more radio access technologies.

[0055] UEs 115 may be dispersed throughout the coverage area 110 of the wireless communication system 100, and each UE 115 may be stationary, mobile, or both at different times. UEs 115 may be devices of different forms or with different capabilities. Figure 1 Some example UEs 115 are shown in FIG. 1. The UEs 115 described herein can communicate with various types of devices such as other UEs 115, base stations 105, or network devices (e.g., core network nodes, relay devices, integrated access and backhaul (IAB) nodes, or other network devices), such as Figure 1 as shown in .

[0056] Base stations 105 may communicate with core network 130, or with each other, or both. For example, base stations 105 may interact with core network 130 via one or more backhaul links 120 (e.g., via S1, N2, N3, or other interfaces). Base stations 105 may communicate with each other via backhaul links 120 (e.g., via X2, Xn, or other interfaces) directly (e.g., directly between base stations 105) or indirectly (e.g., via core network 130), or both. In some examples, backhaul links 120 may be or include one or more wireless links.

[0057] One or more of the base stations 105 described herein may include or be referred to by a person of ordinary skill in the art as: a base station transceiver, a radio base station, an access point, a radio transceiver, a Node B, an eNodeB (eNB), a next generation Node B or a giga Node B (any of which may be referred to as a gNB), a Home Node B, a Home eNodeB or other appropriate terminology.

[0058] UE 115 may include or may be referred to as a mobile device, a wireless device, a remote device, a handheld device or a user device, or some other appropriate terminology, where "device" may also refer to a unit, a station, a terminal or a client, etc. UE 115 may also include or may be referred to as a personal electronic device, such as a cellular phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, or a personal computer. In some examples, UE 115 may include or may be referred to as a wireless local loop (WLL) station, an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a machine type communication (MTC) device, etc., which may be implemented in various items such as home appliances, or vehicles, meters, etc.

[0059] The UE 115 described herein can communicate with various types of devices, such as other UEs 115, which sometimes act as relays, and base stations 105 and network devices including macro eNBs or gNBs, small cell eNBs or gNBs, or relay base stations, among other examples, such as Figure 1 as shown in .

[0060] The UE 115 and the base station 105 can communicate with each other wirelessly via one or more communication links 125 through one or more carriers. The term "carrier" can refer to a set of radio spectrum resources with a specified physical layer structure to support the communication link 125. For example, the carrier used for the communication link 125 may include a portion of the radio spectrum band (e.g., bandwidth portion (BWP)) that operates according to one or more physical layer channels for a given radio access technology (e.g., LTE, LTE-A, LTE-A Pro, NR). Each physical layer channel can carry acquisition signaling (e.g., synchronization signals, system information), control signaling for coordinating the operation of the carrier, user data, or other signaling. The wireless communication system 100 can use carrier aggregation or multi-carrier operation to support communication with the UE 115. According to the carrier aggregation configuration, the UE 115 can be configured with multiple downlink component carriers and one or more uplink component carriers. Carrier aggregation can be used with frequency division duplex (FDD) and time division duplex (TDD) component carriers.

[0061] In some examples (e.g., in a carrier aggregation configuration), a carrier may also have acquisition signaling or control signaling for coordinating operations with respect to other carriers. A carrier may be associated with a frequency channel (e.g., an Evolved Universal Mobile Telecommunications System Terrestrial Radio Access (E-UTRA) Absolute Radio Frequency Channel Number (EARFCN)) and may be located based on a channel raster for UE 115 discovery. A carrier may operate in a standalone mode, in which case a UE 115 may perform initial acquisition and connection via the carrier, or a carrier may operate in a non-standalone mode, in which case a different carrier (e.g., the same or different radio access technology) is used to anchor the connection.

[0062] The communication link 125 shown in the wireless communication system 100 may include an uplink transmission from the UE 115 to the base station 105, or a downlink transmission from the base station 105 to the UE 115. A carrier may carry downlink or uplink communications (e.g., in FDD mode) or may be configured to carry both downlink and uplink communications (e.g., in TDD mode).

[0063] A carrier may be associated with a particular bandwidth of a radio spectrum, and in some examples, the carrier bandwidth may be referred to as the "system bandwidth" of the carrier or wireless communication system 100. For example, the carrier bandwidth may be one of a plurality of determined bandwidths of a carrier for a particular radio access technology (e.g., 1.4, 3, 5, 10, 15, 20, 40, or 80 megahertz (MHz)). Devices of the wireless communication system 100 (e.g., base stations 105, UEs 115, or both) may have a hardware configuration that supports communications on a particular carrier bandwidth, or may be configured to support communications on one of a set of carrier bandwidths. In some examples, the wireless communication system 100 may include a base station 105 or UE 115 that supports simultaneous communications via carriers associated with multiple carrier bandwidths. In some examples, each served UE 115 may be configured to operate on a portion (e.g., subband, BWP) or all of the carrier bandwidth.

[0064] The signal waveform transmitted through the carrier wave may be composed of multiple subcarriers (e.g., using multi-carrier modulation (MCM) techniques such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform spread OFDM (DFT-S-OFDM)). In a system using MCM techniques, a resource element may be composed of a symbol period (e.g., the duration of a modulation symbol) and a subcarrier, where the symbol period is inversely proportional to the subcarrier spacing. The number of bits carried by each resource element may depend on the modulation scheme (e.g., the order of the modulation scheme, the coding rate of the modulation scheme, or both). Therefore, the more resource elements received by the UE 115 and the higher the order of the modulation scheme, the higher the data rate of the UE 115. Wireless communication resources may refer to radio spectrum resources, time resources, and spatial resources (e.g., spatial layers or beams), and the use of multiple spatial layers may further increase the data rate or data integrity used to communicate with the UE 115.

[0065] One or more digital schemes for a carrier may be supported, where the digital scheme may include a subcarrier spacing (Δf) and a cyclic prefix. A carrier may be divided into one or more BWPs having the same or different digital schemes. In some examples, a UE 115 may be configured with multiple BWPs. In some examples, a single BWP for a carrier may be active at a given time, and communication of the UE 115 may be restricted to the one or more active BWPs.

[0066] The time interval for base station 105 or UE 115 may be expressed as a multiple of a basic time unit (eg, which may be referred to as T s =1 / (Δf max ·N f ) seconds sampling period), where Δf max It can represent the maximum supported subcarrier spacing, N f The maximum supported discrete Fourier transform (DFT) size may be indicated. The time intervals of the communication resources may be organized according to radio frames, where each radio frame has a specified duration (e.g., 10 milliseconds (ms)). Each radio frame may be identified by a system frame number (SFN) (e.g., ranging from 0 to 1023).

[0067] Each frame may include multiple consecutively numbered subframes or time slots, and each subframe or time slot may have the same duration. In some examples, the frame may be divided (e.g., in the time domain) into subframes, and each subframe may be further divided into multiple time slots. Alternatively, each frame may include a variable number of time slots, and the number of time slots may depend on the subcarrier spacing. Each time slot may include multiple symbol periods (e.g., depending on the length of the cyclic prefix appended to each symbol period). In some wireless communication systems 100, the time slots may be further divided into multiple micro-time slots containing one or more symbols. In addition to the cyclic prefix, each symbol period may contain one or more (e.g., N f ) sampling periods. The duration of a symbol period may depend on the subcarrier spacing or the operating band.

[0068] A subframe, slot, mini-slot, or symbol may be the smallest scheduling unit (e.g., in the time domain) of the wireless communication system 100, which may be referred to as a transmission time interval (TTI). In some examples, the TTI duration (e.g., the number of symbol periods in a TTI) may be variable. Additionally or alternatively, the smallest scheduling unit of the wireless communication system 100 may be dynamically selected (e.g., in a burst of a shortened TTI (sTTI)).

[0069] Physical channels may be multiplexed on a carrier according to various techniques. For example, physical control channels and physical data channels may be multiplexed on a downlink carrier using one or more of a time division multiplexing (TDM) technique, a frequency division multiplexing (FDM) technique, or a hybrid TDM-FDM technique. A control region (e.g., a control resource set (CORESET)) for a physical control channel may be defined by a plurality of symbol periods and may extend over a system bandwidth or a subset of a system bandwidth of a carrier. One or more control regions (e.g., CORESETs) may be configured for a group of UEs 115. For example, one or more of the UEs 115 may monitor or search a control region for control information according to one or more search space sets, and each search space set may include one or more control channel candidates with one or more aggregation levels arranged in a cascaded manner. The aggregation level for a control channel candidate may refer to the number of control channel resources (e.g., control channel elements (CCEs)) associated with the encoded information for a control information format having a given payload size. The search space sets may include a common search space set configured for transmitting control information to multiple UEs 115 and a UE-specific search space set for transmitting control information to a specific UE 115 .

[0070] Each base station 105 can provide communication coverage via one or more cells (e.g., macro cells, small cells, hot spots or other types of cells or any combination thereof). The term "cell" can refer to a logical communication entity used for communication with the base station 105 (e.g., via a carrier), and can be associated with an identifier (e.g., a physical cell identifier (PCID), a virtual cell identifier (VCID), etc.) used to distinguish adjacent cells. In some examples, a cell can also refer to a geographic coverage area 110 or a portion of a geographic coverage area 110 (e.g., a sector) on which a logical communication entity operates. Depending on various factors (e.g., the capabilities of the base station 105), such a cell can range from a smaller area (e.g., a structure, a subset of a structure) to a larger area. For example, a cell can be or include a building, a subset of a building, or an external space between or overlapping a geographic coverage area 110, etc.

[0071] A macro cell typically covers a relatively large geographic area (e.g., a radius of several kilometers), which allows unrestricted access to UEs 115 that have a service subscription with a network provider that supports macro cells. Compared to macro cells, small cells can be associated with low-power base stations 105, and small cells can operate in the same or different (e.g., licensed, unlicensed) frequency bands as macro cells. Small cells can provide unrestricted access to UEs 115 that have a service subscription with a network provider, or can provide restricted access to UEs 115 associated with the small cell (e.g., UEs 115 in a closed subscriber group (CSG), UEs 115 associated with users in a home or office). A base station 105 can support one or more cells, and can also support communication on one or more cells using one or more component carriers.

[0072] In some examples, a carrier may support multiple cells, and different cells may be configured based on different protocol types (e.g., MTC, narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB)) that may provide access to different types of devices.

[0073] In some examples, the base stations 105 may be mobile, thus providing communication coverage for mobile geographic coverage areas 110. In some examples, different geographic coverage areas 110 associated with different technologies may overlap, but the different geographic coverage areas 110 may be supported by the same base station 105. In other examples, overlapping geographic coverage areas 110 associated with different technologies may be supported by different base stations 105. For example, the wireless communication system 100 may include a heterogeneous network in which different types of base stations 105 provide coverage for various geographic coverage areas 110 using the same or different radio access technologies.

[0074] The wireless communication system 100 may support synchronous or asynchronous operation. For synchronous operation, the base stations 105 may have similar frame timing, and transmissions from different base stations 105 may be approximately aligned in time. For asynchronous operation, the base stations 105 may have different frame timing, and in some examples, transmissions from different base stations 105 may not be aligned in time. The techniques described herein may be used for both synchronous and asynchronous operation.

[0075] Some UEs 115, such as MTC or IoT devices, may be low-cost or low-complexity devices and may provide automated communication between machines (e.g., via machine-to-machine (M2M) communication). M2M communication or MTC may refer to data communication technology that allows devices to communicate with each other or with a base station 105 without human intervention. In some examples, M2M communication or MTC may include communication from a device with an integrated sensor or meter that measures or captures information and relays the information to a central server or application that may make use of the information or present the information to a person interacting with the application. Some UEs 115 may be designed to collect information or implement automated behavior of a machine or other device. Examples of applications for MTC devices include: smart metering, inventory monitoring, water level monitoring, equipment monitoring, healthcare monitoring, wildlife monitoring, weather and geological event monitoring, fleet management and tracking, remote security sensing, physical access control, and transaction-based service billing.

[0076] Some UEs 115 may be configured to employ an operating mode that reduces power consumption, such as half-duplex communication (e.g., a mode that supports unidirectional communication by sending or receiving but does not support sending and receiving simultaneously). In some examples, half-duplex communication may be performed at a reduced peak rate. Other power saving techniques for UE 115 include entering a power saving deep sleep mode when not participating in active communications, operating on a limited bandwidth (e.g., according to narrowband communications), or a combination of these techniques. For example, some UEs 115 may be configured to operate using a narrowband protocol type, wherein the narrowband protocol type is associated with a specified portion or range (e.g., a subcarrier or resource block (RB) set) within a carrier, within a guard band of a carrier, or outside a carrier.

[0077] The wireless communication system 100 can be configured to support ultra-reliable communication or low-latency communication or various combinations thereof. For example, the wireless communication system 100 can be configured to support ultra-reliable low-latency communication (URLLC) or mission-critical communication. UE115 can be designed to support ultra-reliable, low-latency or critical functions (e.g., mission-critical functions). Ultra-reliable communication may include private communication or group communication, and may be supported by one or more mission-critical services (e.g., mission-critical push-to-talk (MCPTT), mission-critical video (MCVideo), or mission-critical data (MCData)). Support for mission-critical functions may include prioritizing services, and mission-critical services may be used for public safety or general commercial applications. The terms ultra-reliable, low-latency, mission-critical, and ultra-reliable low-latency may be used interchangeably herein.

[0078] In some examples, UE 115 can also communicate directly with other UE 115 via a device-to-device (D2D) communication link 135 (e.g., using a peer-to-peer (P2P) or D2D protocol). One or more UEs 115 using D2D communication can be located within the geographic coverage area 110 of the base station 105. Other UEs 115 in the group can be located outside the geographic coverage area 110 of the base station 105, or cannot receive transmissions from the base station 105. In some examples, the group of UEs 115 communicating via D2D communication can utilize a one-to-many (1:M) system in which each UE 115 transmits to each other UE 115 in the group. In some examples, the base station 105 facilitates the scheduling of resources for D2D communication. In other cases, D2D communication is performed between UEs 115 without involving the base station 105.

[0079] In some systems, the D2D communication link 135 can be an example of a communication channel (e.g., a sidelink communication channel) between vehicles (e.g., UE 115). In some examples, vehicles can communicate using vehicle-to-everything (V2X) communication, vehicle-to-vehicle (V2V) communication, or some combination of these. Vehicles can signal information related to traffic conditions, signal scheduling, weather, safety, emergency situations, or any other information related to the V2X system. In some examples, vehicles in a V2X system can communicate with roadside infrastructure (V2I) such as a roadside unit (RSU), or use vehicle-to-network (V2N) communication to communicate with the network via one or more network nodes (e.g., base station 105), or both. In some examples, vehicles in a V2X system can communicate with pedestrians or other vulnerable road users using vehicle-to-pedestrian (V2P) communication.

[0080] The core network 130 may provide user authentication, access authorization, tracking, Internet Protocol (IP) connection, and other access, routing or mobility functions. The core network 130 may be an evolved packet core (EPC) or a 5G core (5GC), which may include at least one control plane entity (e.g., a mobile management entity (MME), an access and mobility management function (AMF)) for managing access and mobility, and at least one user plane entity (e.g., a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)) for routing packets or interconnecting to an external network. The control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management of UE 115 served by a base station 105 associated with the core network 130. User IP packets may be transmitted via a user plane entity, which may provide IP address allocation, routing, filtering, QoS implementation, and other functions. The user plane entity may be connected to a network operator IP service 150. These operator IP services 150 may include access to the Internet, an intranet, an IP Multimedia Subsystem (IMS), or packet-switched streaming services. In some examples, the user plane entity may also provide non-IP-based services (e.g., unstructured PDU session types, Ethernet PDU session types, or non-IP PDN connections) to the UE 115.

[0081] Some of the network devices (e.g., base stations 105) may include subcomponents such as access network entities 140, which may be examples of access node controllers (ANCs). Each access network entity 140 may communicate with the UE 115 through one or more other access network transport entities 145, which may be referred to as radio heads, smart radio heads, or transmission / reception points (TRPs). Each access network transport entity 145 may include one or more antenna panels. In some configurations, the various functions of each access network entity 140 or base station 105 may be distributed among various network devices (e.g., radio heads and ANCs) or may be combined in a single network device (e.g., base station 105).

[0082] The wireless communication system 100 may operate using one or more frequency bands, typically in the range of 300 megahertz (MHz) to 300 gigahertz (GHz). Typically, the region from 300 MHz to 3 GHz is referred to as the very high frequency (UHF) region or decimeter band, due to its wavelengths ranging from approximately one decimeter to one meter in length. UHF waves may be blocked or redirected by buildings and environmental features, but these waves may penetrate structures sufficiently for macro cells to provide service to UEs 115 located indoors. Transmissions using UHF waves may be associated with smaller antennas and shorter distances (e.g., less than 100 kilometers) compared to transmissions using the lower frequencies and longer wavelengths of the high frequency (HF) or very high frequency (VHF) portions of the spectrum below 300 MHz.

[0083] The wireless communication system 100 may also operate in the super high frequency (SHF) region using a frequency band from 3 GHz to 30 GHz (also referred to as a centimeter wave band), or in the extremely high frequency (EHF) region of the spectrum (e.g., from 30 GHz to 300 GHz), which is also referred to as a millimeter wave band. In some examples, the wireless communication system 100 may support millimeter wave (mmW) communications between the UE 115 and the base station 105, and the EHF antenna of the corresponding device may be even smaller and more compact than the UHF antenna. In some examples, this may facilitate the use of antenna arrays within the device. However, the propagation of EHF transmissions may suffer from greater atmospheric attenuation and shorter transmission distances than SHF or UHF transmissions. The techniques disclosed herein may be employed in transmissions using one or more different frequency regions, and the designated use of frequency bands across these frequency regions may differ by country or regulatory agency.

[0084] The wireless communication system 100 can utilize licensed and unlicensed radio spectrum bands. For example, the wireless communication system 100 can employ license assisted access (LAA), LTE unlicensed (LTE-U) radio access technology, or NR technology in unlicensed bands such as the 5 GHz industrial, scientific, and medical (ISM) band. When operating in an unlicensed radio spectrum band, devices such as base stations 105 and UEs 115 can employ carrier sensing to achieve conflict detection and avoidance. In some examples, operations in unlicensed bands can be based on a carrier aggregation configuration combined with component carriers operating in a licensed band (e.g., LAA). Operations in unlicensed spectrum can include downlink transmissions, uplink transmissions, P2P transmissions, or D2D transmissions, among other examples.

[0085] Base station 105 or UE 115 may be equipped with multiple antennas that may be used to employ techniques such as transmit diversity, receive diversity, multiple-input multiple-output (MIMO) communications, or beamforming. Antennas based on 105 or UE 115 may be located in one or more antenna arrays or antenna panels that may support MIMO operations or transmit beams or receive beamforming. For example, one or more base station antennas or antenna arrays may be located at the same antenna assembly (e.g., an antenna tower). In some examples, antennas or antenna arrays associated with base station 105 may be located at different geographic locations. Base station 105 may have an antenna array with multiple rows and columns of antenna ports that may be used by base station 105 to support beamforming for communications with UE 115. Similarly, UE 115 may have one or more antenna arrays that may support various MIMO or beamforming operations. Additionally or alternatively, the antenna panel may support radio frequency beamforming for signals sent via the antenna ports.

[0086] The base station 105 or UE 115 can use MIMO communication to adopt multipath signal propagation to increase spectral efficiency by sending or receiving multiple signals via different spatial layers. These technologies can be referred to as spatial multiplexing. For example, the transmitting device can send the multiple signals via different antennas or different combinations of antennas. Similarly, the receiving device can receive the multiple signals via different antennas or different combinations of antennas. Each of the multiple signals can be referred to as a separate spatial stream, which can carry bits associated with the same data stream (e.g., the same codeword) or different data streams (e.g., different codewords). Different spatial layers can be associated with different antenna ports for channel measurement and reporting. MIMO technology includes single-user MIMO (SU-MIMO) and multi-user MIMO (MU-MIMO), where under SU-MIMO, multiple spatial layers are sent to the same receiving device, and under MU-MIMO, multiple spatial layers are sent to multiple devices.

[0087] Beamforming (which may also be referred to as spatial filtering, directional transmission, or directional reception) is a signal processing technique that may be used at a transmitting device or receiving device (e.g., base station 105, UE 115) to shape or control an antenna beam (e.g., a transmit beam, a receive beam) along a spatial path between the transmitting device and the receiving device. Beamforming may be achieved by combining signals transmitted via antenna elements of an antenna array so that certain signals propagating at a particular orientation with respect to the antenna array experience constructive interference, while other signals experience destructive interference. Adjustments to signals transmitted via antenna elements may include the transmitting device or receiving device applying an amplitude offset, a phase offset, or both to signals carried by antenna elements associated with the device. Adjustments associated with each antenna element may be specified by a set of beamforming weights associated with a particular orientation (e.g., with respect to an antenna array of a transmitting device or receiving device, or with respect to some other orientation).

[0088] The base station 105 or the UE 115 may use beam scanning techniques as part of a beamforming operation. For example, the base station 105 may use multiple antennas or antenna arrays (e.g., antenna panels) to perform beamforming operations for directional communications with the UE 115. The base station 105 may transmit some signals (e.g., synchronization signals, reference signals, beam selection signals, or other control signals) multiple times in different directions. For example, the base station 105 may transmit signals according to different sets of beamforming weights associated with different transmission directions. Transmissions in different beam directions may be used to identify (e.g., by a transmitting device such as the base station 105 or a receiving device such as the UE 115) a beam direction in which the base station 105 will later transmit or receive.

[0089] Base station 105 may transmit some signals (e.g., data signals associated with a particular receiving device) in a single beam direction (e.g., a direction associated with a receiving device such as UE 115). In some examples, the beam direction associated with transmission along the single beam direction may be determined based on signals transmitted in one or more beam directions. For example, UE 115 may receive one or more of the signals transmitted by base station 105 in different directions and may report to base station 105 an indication of the signals received by UE 115 with the highest signal quality or other acceptable signal quality.

[0090] In some examples, transmissions by a device (e.g., a base station 105 or a UE 115) may be performed using multiple beam directions, and the device may use a combination of digital precoding or radio frequency beamforming to generate a combined beam for transmission (e.g., from the base station 105 to the UE 115). The UE 115 may report feedback indicating precoding weights for one or more beam directions, and the feedback may correspond to a configured number of beams across the system bandwidth or one or more subbands. The base station 105 may send a reference signal (e.g., a cell-specific reference signal (CRS), a channel state information reference signal (CSI-RS)), which may be precoded or unprecoded. The UE 115 may provide feedback for beam selection, which may be a precoding matrix indicator (PMI) or codebook-based feedback (e.g., a multi-panel type codebook, a linear combination type codebook, a port selection type codebook). Although these techniques are described with reference to signals sent by base station 105 in one or more directions, UE 115 may employ similar techniques to send signals multiple times in different directions (e.g., to identify a beam direction for subsequent transmission or reception by UE 115) or to send signals in a single direction (e.g., to send data to a receiving device).

[0091] When receiving various signals from the base station 105 (e.g., synchronization signals, reference signals, beam selection signals, or other control signals), the receiving device (e.g., UE 115) can try multiple reception configurations (e.g., directional listening). For example, the receiving device can try multiple reception directions by receiving via different antenna subarrays, by processing the received signal according to different antenna subarrays, by receiving according to different reception beamforming weight sets (e.g., different directional listening weight sets) (where these weight sets are applied to signals received at multiple antenna elements of the antenna array), or by processing the received signal according to different reception beamforming weight sets (where these weight sets are applied to signals received at multiple antenna elements of the antenna array), any of which can be referred to as "listening" according to different reception configurations or reception directions. In some examples, the receiving device can use a single reception configuration to receive along a single beam direction (e.g., when receiving a data signal). A single receive configuration may be aligned on a beam direction determined based on listening according to different receive configuration directions (e.g., a beam direction determined to have the highest signal strength, highest signal-to-noise ratio (SNR), or otherwise acceptable signal quality based on listening according to multiple beam directions).

[0092] The wireless communication system 100 can be a packet-based network that operates according to a layered protocol stack. In the user plane, the communication of the bearer or packet data convergence protocol (PDCP) layer can be based on IP. The radio link control (RLC) layer can perform packet segmentation and reorganization to communicate through logical channels. The medium access control (MAC) layer can perform priority processing, as well as multiplexing of logical channels to transport channels. The MAC layer can also use error detection technology, error correction technology, or both to support retransmission of the MAC layer to improve link efficiency. In the control plane, the radio resource control (RRC) protocol layer can provide the establishment, configuration and maintenance of the RRC connection between the UE 115 and the base station 105 or the core network 130 that supports the radio bearer for user plane data. At the physical layer, the transport channel can be mapped to the physical channel.

[0093] UE 115 and base station 105 can support retransmission of data to increase the possibility of successfully receiving the data. Hybrid automatic repeat request (HARQ) feedback is a technique for increasing the possibility of correctly receiving data through communication link 125. HARQ can include a combination of error correction (e.g., using cyclic redundancy check (CRC)), forward error correction (FEC) and retransmission (e.g., automatic repeat request (ARQ)). HARQ can improve the throughput of the MAC layer under poor radio conditions (e.g., low signal-to-noise ratio conditions). In some examples, the device can support same-slot HARQ feedback, in which case the device can provide HARQ feedback in the slot for data received in the previous symbol of a particular slot. In other cases, the device can provide HARQ feedback in a subsequent slot or according to some other time interval.

[0094] The wireless communication system 100 may be a distributed system in which a UE 115 monitors and receives packets from one or more other UEs 115. For example, when two UEs 115 are communicating with each other, a third UE 115 may be able to monitor transmissions between the two UEs 115. In addition, such a system may support the use of an intermediate layer (e.g., VAE and SEAL) to coordinate service and application specific functions between the network and the UEs 115 and between the UEs 115. The VAE and SEAL framework may include congestion control services for communications on the sidelinks between the UEs 115. The congestion control services may include VAE and SEAL functionality to handle distributed communications of sidelink communications where not all UEs 115 are within coverage by providing relay and aggregation services at the SEAL and VAE nodes.

[0095] Based on the limited spectrum allocated for V2X and the large number of UEs 115 that may be concentrated in an area, the resources reserved for sidelink communications may be in high demand, which is most likely when V2X communications are most needed. For example, V2X communications are useful during rush hour traffic in crowded locations, in the event of an accident, at busy intersections, and so on. New services enabled by advanced New Radio (NR) V2X over the PC5 link can transmit a large amount of traffic (e.g., sensor data or video data) between UEs 115, which allows more complex controls to be used when congestion occurs based on the characteristics and requirements of the applications rather than simple rules that apply to all applications. Therefore, it is expected to further assist the VAE and SEAL in determining whether congestion is occurring and mitigation options.

[0096] According to the techniques described herein, the VAE and SEAL enhancement framework may include support for detection of sidelink congestion and congestion relief between UEs 115. The described techniques may include: the VAE layer collects information about one or more applications running by UEs 115 at a specific location, in a specific group of UEs 115, for a specific service (e.g., queues, sensor sharing, or intersection assistance, etc.), and also collects information about UE 115 maneuvers (e.g., left turn, right turn, straight, lane change, merge, etc.). In addition, the SEAL layer may manage and monitor resources based on PC5 communication status, PC5 communication statistics, the number of unicast links, PC5 QoS information, and the like. Based on the collected information, the VAE layer may determine whether the service type can be congested controlled according to the determined algorithm, which may include: adjusting the message generation rate at the UE 115. In addition, based on the collected information, the SEAL layer may also perform analysis to determine whether a certain type of communication is facing problems, or may predict whether a certain type of communication may face problems in the future, and provide such information to the VAE layer.

[0097] In some cases, status monitoring and congestion detection can support scenarios when some UEs 115 are out of coverage but communicate with other UEs 115 via PC5. In the case where UE 115 is out of coverage, the VAE can indicate the relay or aggregation of service level status reports to the UE 115 in coverage, so that the UE 115 out of coverage can report congestion information to the UE 115 in coverage. The VAE can also configure how congestion control instructions should be distributed through the V2X system. Other considerations for congestion services at the VAE and SEAL include: different UEs 115 use different PLMNs. In this case, the VAE or SEAL server can be universal or placed on the user plane and accessible from different PLMNs. Alternatively, a SEAL server-to-server interface can be created so that the UE 115 out of coverage can communicate with its HPLMN VAE or SEAL server via the UE 115 in coverage and its SEAL server. Therefore, side link congestion can be efficiently detected and managed.

[0098] Figure 2 An example of a distributed wireless communication system 200 according to aspects of the present disclosure is shown. In some examples, the distributed wireless communication system 200 can implement aspects of the wireless communication system 100. The distributed wireless communication system 200 can be an NR V2X system and can include UE 115-a, UE 115-b, UE 115-c, and UE 115-d, which can be as described in reference Figure 1 The example of UE 115 described above. UE 115-a, UE 115-b, UE 115-c, and UE 115-d can support congestion control services at VAE server 220 and SEAL server 225 based on the enhanced VAE and SEAL middle layer framework. Figure 2 The described techniques may also be applied to communications in systems other than V2X systems.

[0099] UE 115 in wireless communication system 200 can be distributed throughout the system and communicate via side link 205. In some examples, UE 115-a can be within the coverage area 110-a of base station 105-a. Therefore, UE 115-a and base station 105-a can communicate via link 210. However, UE 115-b, UE 115-c, and UE 115-d may be outside the coverage area 110-a of base station 105-a and may not be able to communicate directly with base station 105-a. In contrast, UE 115-b, UE 115-c, and UE 115-d can communicate indirectly with base station 105-a through UE 115-a via side link 205. For example, UE 115-d can send congestion information intended for VAE 220 to UE 115-b via side link 205. UE 115-b may then forward the transmission to UE 115-a via side link 205, and UE 115-a may forward the transmission to base station 105-a via link 210, wherein base station 105-a may communicate with VAE 220 and SEAL 225 via link 215. Additionally, VAE server 220 and SEAL server 225 may communicate with each other via link 217 and may be configured to support congestion control services for communications of one or more UEs 115 communicating on side link 205. In some examples, a UE 115-a located within coverage area 110-a may be a roadside unit (RSU) strategically located at a particular location to provide assistance to other UEs 115.

[0100] Sidelink 205 communications such as V2X communications may become congested, for example, due to limited spectrum (e.g., 30 MHz), limited radio resources, and a large number of UEs 115 that may be concentrated in a certain area. In some cases, sidelink 205 congestion may occur when V2X communications are critical to UE 115 behavior (e.g., for safety, such as avoiding situations that may be potentially dangerous or may otherwise affect the user). For example, communication congestion may occur when the UE 115 is in traffic, near an intersection, near an accident site, or another UE 115 dense area. In addition, sidelink 205 congestion may be the result of an increase in data transfer rates between UEs 115. For example, some V2X services enabled by advanced NR V2X through the sidelink 205 (e.g., PC5) may send a large amount of traffic for safety service determination to enable sensor sharing or raw video data sharing. When congestion occurs, these advanced services may require complex control, such as service priority based on UE 115 location.

[0101] As described herein, the VAE 220 and SEAL 225 frameworks may be enhanced to support congestion detection and congestion management on the sidelink 205. In some cases, all V2X applications may use congestion control, and it is desirable to implement congestion control at the VAE 220 layer for V2X so that all applications may be processed in a consistent manner at each UE 115. Thus, congestion control and coordination of sidelink communications may be implemented by functions performed by a server associated with the VAE layer (e.g., by the VAE server 220). Similarly, congestion control and management may be implemented additionally or alternatively by functions performed by a server associated with the SEAL (e.g., by the SEAL server 225). The techniques described herein address various aspects of V2X sidelink congestion control at the VAE and SEAL layers, including communication status monitoring for congestion detection and congestion management. Due to the nature of sidelink 205 communications, state monitoring and congestion detection may support PC5 situations when not all UEs 115 are within coverage (e.g., UE 115-a is within coverage while UE 115-b, UE 115-c, and UE 115-d may be out of coverage). VAE 220 and SEAL 225 may work together to control congestion at sidelink 205. In some cases, each layer may be responsible for overlapping and / or unique congestion control functions.

[0102] The VAE 220 may implement intelligent congestion control by understanding for each UE 115 which applications are running at a particular location, a particular UE 115 group or area, a particular service (e.g., a queue, sensor sharing, or intersection assistance), and the maneuvers and / or movements of different UEs 115 (e.g., left turn, right turn, straight ahead, lane change, merge, or other similar maneuvers). The VAE 220 may also collect operational information for each of these categories. Based on the collected information, the VAE 220 may determine whether a service type (e.g., a provider service identifier (PSID) or an intelligent transportation system (ITS) application identifier (AID) (ITS-AID)) is subject to congestion control, such as an adjusted message generation rate. This determination may be made based on a determined algorithm. Some exemplary control mechanisms may be based on V2X specific logic, such as service priority logic based on the contextual awareness or motion state of the UE 115.

[0103] SEAL 225 can implement intelligent congestion control by monitoring and managing the sidelink 205 (e.g., PC5) communication status (e.g., channel busy rate (CBR) or reference signal received power (RSRP)). Additionally or alternatively, SEAL 225 can monitor and manage sidelink 205 (e.g., PC5) communication statistics, such as the number of UE 115 groups (e.g., second layer (L2) IDs) or the number of unicast links. Additionally or alternatively, SEAL 225 can monitor and manage sidelink 205 (e.g., PC5) QoS information, which includes, for example, packet error rate, observed packet delay, HARQ feedback error count, multicast range, unicast bit rate, and prevention quality indicator (PQI). Based on the monitored information, SEAL 225 can perform analysis to determine whether a certain type of communication is facing problems and provide such information to VAE 220. In some cases, the determination can be based on data statistics and / or analysis, or some prediction based on machine learning or artificial intelligence (AI). SEAL 225 shares this determination with VAE 220, allowing VAE 220 to perform congestion control to adjust application communication patterns based on the underlying communication type.

[0104] VAE 220 and SEAL 225 can collect information from UE 115. In some cases, the information may have to be relayed to a server. As shown, UE 115-d may not be able to communicate directly with UE 115-a within coverage, so UE 115-a cannot directly monitor information from UE 115-d and report it to VAE 220 and SEAL 225 (which may be referred to as SEAL network resource management (NRM) server). In order to support this common situation of UE 115 out of coverage for V2X, UE 115-b or UE 115-c can help provide information from UE 115-d to the network side (e.g., VAE 220 or SEAL 225) via UE 115-a.

[0105] In some examples, UE 115-a may act as a UE-to-network relay for out-of-coverage UEs 115 (e.g., UE 115-b, UE 115-c, and UE 115-d), and each UE 115-a, UE 115-b, UE 115-c, and UE 115-d may report to the server separately. Thus, duplicate information may be sent to VAE 220 and SEAL 225. UE 115-a may provide relay or proxy operations to VAE 220 and SEAL 225, and VAE 220 and SEAL 225 may organize and aggregate the information.

[0106] In other examples, each of the UEs 115 may forward the report information with associated location information. For example, UE 115-d may forward the report information to another UE 115 (e.g., UE 115-b or UE 115-c), and the receiving UE 115 may aggregate and prune the overlapping information between the received information and its own information before multicasting the report information to another UE 115 (e.g., UE 115-a). UE 115-a may be in coverage area 110-a and may not further multicast the information. Instead, UE 115-a may prune the overlapping information and report the aggregated information directly to VAE 220 and SEAL 225 (e.g., via base station 105-a).

[0107] To limit unnecessary information dissemination, UE 115-b or 115-c can limit the re-groupcast information to information within a limited UE 115 area (e.g., geographic area, location, etc.) that can be pre-configured, signaled to UE 115-b or UE 115-c within network coverage, or relayed to UE 115-b or UE 115-c by UE 115-a within coverage. If VAE 220 or SEAL 225 determines that there are one or more holes in the collected information, VAE 220 and SEAL225 can configure UE 115 in a specific area to increase the area. For example. VAE 220 can request more information from UE 115-b via UE 115-a based on the lack of complete congestion information.

[0108] Similar to information collection, VAE 220 and SEAL 225 can distribute congestion control to UE 115. In some examples, these layers can work together for cross-layer congestion management. As described above, VAE 220 and SEAL 225 can perform congestion control management at different layers. For example, VAE 220 can determine that a certain service (e.g., a security service) should be prioritized and therefore request SEAL 225. The NRM server can generate corresponding policies to be transmitted to all UEs 115 in a specific area. For example, this can be achieved in the following way: the NRM server makes a request via a 5G system public function (e.g., a network public function (NEF) and a unified data repository (UDR) and a policy control function (UDR-PCF)) to transmit these configurations directly to UE 115 via a UE115 policy configuration mechanism, or to NG-RAN to be broadcast via SIB or dedicated RRC signaling, etc.

[0109] In some cases, the VAE 220 may have direct control at the V2X layer, such as setting the message generation rate for some services. This configuration may be provided to the UE 115 via the NEF-UDR-PCF-AMF route described above (as part of the application server configuration via the control plane), or may be provided directly to the UE 115 via the user plane. Because not all UEs 115 are within coverage (e.g., UE 115-b, UE 115-c, and UE 115-d are out of coverage), some UEs 115 should forward the received configuration to other UEs 115 in the target area via the side link 205 (e.g., PC5), as indicated by the server. For example, UE 115-a may forward the configuration to UE 115-b and UE 115-c, and UE 115-b or UE 115-c may forward the configuration to UE 115-d. In some cases, the VAE 220 and SEAL 225 may identify a UE 115 (e.g., UE 115-a) in a target area and transmit updated congestion control management instructions to the UE 115-a. The UE 115-a may use the target area of ​​an explicit indication or information element (IE) from the VAE 220 or SEAL 225 to determine whether and how to forward the configuration (e.g., multicast with range control).

[0110] In some cases, not all UEs 115 subscribe to the same PLMN. For example, UE 115-a and UE 115-b may subscribe to a first PLMN, while UE 115-c and 115-d may subscribe to a second, different PLMN. For the V2X case, different UEs 115 may have different HPLMNs. To support such operations, the VAE 220 or SEAL 225 may be generic so as to be shared by multiple PLMNs (e.g., placed in a V2X slice). In another example, the VAE 220 or SEAL 225 may be placed on the user plane and may be accessed from different PLMNs. Alternatively, a SEAL server-to-server interface may be created so that UE 115-c may send to its HPLMN VAE 220 or SEAL 225 server via UE 115-a and its SEAL 225 by indicating its HPLMN ID in a report message. This inter-SEAL interface may then be handled as roaming of SEALs only, and a general national roaming agreement may not be required.

[0111] Figure 3An example of an intermediate layer framework 300 according to aspects of the present disclosure is shown. In some examples, the intermediate layer framework 300 can implement aspects of the wireless communication systems 100 and 200. The intermediate layer framework 300 may include a V2X application server 305, which may include a VAE server 320 and a SEAL server 325, and V2X UE1 and V2X UE2 (which may be Figure 2 Example of UE 115 in ).

[0112] The VAE and SEAL frameworks can be defined on the user plane. For example, the VAE layer can provide corresponding user plane data and / or control to the 3GPP network system and provide service requirements to the SEAL layer. In some examples, the SEAL layer can interact with the 3GPP network system to meet the V2X service requirements. With these, some V2X application-specific functions can be offloaded to the VAE and SEAL layers.

[0113] According to the techniques described herein, the VAE framework may include a congestion control service at the VAE server 320 for detecting and managing congestion between the V2X UE1 and the V2X UE2, wherein the V2X UE1 and the V2X UE2 may be Figure 2 Additionally or alternatively, the VAE framework may include potential relaying or aggregation of service level status reports at V2X UE1 and V2X UE2 (wherein V2X UE1 and V2X UE2 may be such as Figure 2 UE 115 described in ), and including congestion control instruction distribution in the VAE server 320 and relay services in V2X UE1 and V2X UE2.

[0114] According to the techniques described herein, the SEAL framework may include congestion control monitoring and management services at the SEAL server 325 and V2X UE1 and V2X UE2. The SEAL framework may also include a relay for reporting and instruction distribution services at the VAE layer. In some examples, the SEAL framework may include additional cross-layer interactions with the VAE for congestion control management at the SEAL server 325. Additionally or alternatively, the SEAL framework may include analysis and prediction capabilities for PC5 operations of the SEAL server 325.

[0115] Figure 4 An example of a process flow 400 according to aspects of the present disclosure is shown. In some examples, the process flow 400 can implement aspects of the wireless communication systems 100 and 200. The process flow 400 is shown as being implemented by a UE 115-e within coverage, which can be part of a V2X system and can be as described with reference to FIG. Figure 1 and Figure 2 Examples of UEs described herein. For example, UE 115-e may be Figure 2 The process flow 400 is also shown as being implemented by a VAE server 320-a and a SEAL server 325-a, which may be part of a V2X system and may be as described with reference to FIG. Figure 2 and Figure 3 An example of a VAE and SEAL server as described.

[0116] In the following description of process flow 400, the operations of UE 115-e, VAE server 320-a, and SEAL server 325-a may occur in a different order than the exemplary order shown. Some of the operations shown may also be excluded from process flow 400, or other operations may be added to process flow 400. It should be understood that although UE 115-e, VAE server 320-a, and SEAL server 325-a are shown as performing many of the operations of process flow 400, any wireless device may perform the operations shown.

[0117] At 405, the UE 115-e, the VAE server 320-a, and the SEAL server 325-a may identify a congestion control configuration. In some cases, the congestion control configuration may include a capability to collect operational information at the VAE server 320-a and the SEAL server 325-a.

[0118] At 410, the VAE server 320-a may send an operational information request, and the UE 115-e may receive it. In some examples, the request may be based on a hole identified in the information by the VAE server 320-a or the SEAL server 325-a.

[0119] At 415, UE 115-e may send operational information based on the capabilities and optionally the request at 410, and VAE server 320-a may receive the operational information. In some examples, the operational information includes location-specific application information, sidelink group-specific information, connected vehicle service-specific information, UE mobility information, or a combination thereof.

[0120] At 420, the SEAL server 325-a can monitor the sidelink performance of the UE 115-e based on the capabilities. In some examples, the sidelink performance includes sidelink communication status, sidelink communication statistics, sidelink quality of service information, or a combination thereof.

[0121] At 425, SEAL server 325-a may identify a congestion state for the communication type based on monitoring the sidelink performance at 420. In some cases, identifying a congestion state for the communication type may include identifying potential congestion for the communication type based on a prediction based on monitoring the sidelink performance.

[0122] At 430, based on identifying the congestion state at 425, the SEAL server 325-a may send, and the VAE server 320-a may receive, congestion control information for one or more UEs 115. In some examples, the congestion control information includes an underlying communication type.

[0123] At 435 , the VAE server 320 - a may generate congestion control instructions for one or more UEs 115 based on the received operational information and, optionally, the congestion control information received at 430 .

[0124] At 440, the VAE server 320-a may send congestion control instructions based on the instruction generation at 435, and the UE 115-e may receive and then forward to other UEs 115. In some examples, the instructions may include a distribution configuration. In some cases, sending the congestion control instructions may include sending the instruction distribution configuration via a user plane, a control plane, a system information, a radio resource control signaling, or a combination thereof. In some cases, the congestion control instructions include a priority of the underlying communication type. In some examples, the congestion control instructions include a message generation rate adjustment, an application communication mode adjustment, a priority of the underlying communication type, or a combination thereof.

[0125] Figure 5 A block diagram 500 of a device 505 according to aspects of the present disclosure is shown. The device 505 can be an example of aspects of an application server as described herein. For example, the application server can be an example of a VAE server, a SEAL server, an NRM server, etc. The device 505 may include an input module 510, a communication manager 515, and an output module 520. The device 505 may also include a processor. Each of these components can communicate with each other (e.g., via one or more buses).

[0126] Input module 510 can manage input signals for device 505. For example, input module 510 can recognize input signals based on interaction with a modem, keyboard, mouse, touch screen, or similar device. These input signals can be associated with user input or processing at other components or devices. In some cases, input module 510 can utilize a computer such as a computer program product. 505 to process the input signals. The input module 510 may send aspects of these input signals to other components of the device 505 for processing. For example, the input module 510 may send input signals to the communication manager 515 to support congestion control of the sidelink intermediate layer framework. In some cases, the input module 510 may be as described in reference to Figure 8 Components of the input / output (I / O) controller 815 are described.

[0127] The communication manager 515 can identify a congestion control configuration at the application enabler layer, which includes the ability to collect operational information, receive operational information from a group of UEs based on these capabilities, and generate congestion control instructions for one or more UEs in the group of UEs based on the received operational information. In some examples, the operations performed at the application enabler layer are performed by executing instructions associated with the layer (e.g., executed at an application server). The communication manager 515 can also identify a congestion control configuration at the application enabler architecture layer, which includes the ability to collect operational information, monitor the side link performance of a group of UEs based on these capabilities, and identify the congestion state of the communication type based on monitoring the side link performance. In some examples, the operations performed at the application enabler architecture layer are performed by executing instructions associated with the layer (e.g., executed at an application server). The communication manager 515 can be an example of various aspects of the communication manager 810 described herein.

[0128] The communication manager 515 or its subcomponents may be implemented in hardware, in code (e.g., software or firmware) executed by a processor, or in any combination thereof. When implemented in code executed by a processor, a general purpose processor, a DSP, an application specific integrated circuit (ASIC), an FPGA or other programmable logic device, a discrete gate or transistor logic device, discrete hardware components, or any combination thereof for performing the functions described in the present disclosure may perform the functions of the communication manager 515 or its subcomponents.

[0129] The communication manager 515 or its subcomponents may be physically distributed in multiple locations, including being distributed as part of implementing functionality at different physical locations through one or more physical components. In some examples, according to various aspects of the present disclosure, the communication manager 515 or its subcomponents may be separate and distinct components. In some examples, according to various aspects of the present disclosure, the communication manager 515 or its subcomponents may be combined with one or more other hardware components, including but not limited to input / output (I / O) components, transceivers, network servers, another computing device, one or more other components described in the present disclosure, or combinations thereof.

[0130] Output module 520 can manage output signals of device 505. For example, output module 520 can receive signals from other components of device 505 (e.g., communication manager 515) and can send these signals to other components or devices. In some specific examples, output module 520 can send output signals for display in a user interface, for storage in a database or data store, for further processing at a server or server cluster, or for any other processing at any number of devices or systems. In some cases, output module 520 can be as described in reference to Figure 8 Components of I / O controller 815 are described.

[0131] Figure 6 A block diagram 600 of an apparatus 605 according to aspects of the present disclosure is shown. The apparatus 605 may be a device 505 or an application server as described herein (e.g., an application server 305, or a VAE server 320, or a SEAL server 325, or a combination thereof, as described in reference to FIG. Figure 3 605 may include an example of various aspects of a VAE server, a SEAL server, an NRM server, etc., or various aspects of their functions. The device 605 may include an input module 610, a communication manager 615, and an output module 645. The device 605 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses). In some cases, the device 605 may be an example of a user terminal, a database server, or a system comprising multiple computing devices.

[0132] Input module 610 can manage input signals for device 605. For example, input module 610 can identify input signals based on interaction with a modem, keyboard, mouse, touch screen, or similar device. These input signals can be associated with user input or processing at other components or devices. In some cases, input module 610 can utilize a computer such as a computer program product. 610 may send aspects of these input signals to other components of the device 605 for processing. For example, the input module 610 may send input signals to the communication manager 615 to support congestion control of the sidelink intermediate layer framework. In some cases, the input module 610 may be as described in reference to Figure 8 Components of the input / output (I / O) controller 815 are described.

[0133] The communication manager 615 may be an example of aspects of the communication manager 515 as described herein. The communication manager 615 may include a VAE service manager 620, a congestion information collector 625, a congestion controller 630, a SEAL service manager 635, and a sidelink performance component 640. The communication manager 615 may be a reference Figure 7 and Figure 8 Examples of aspects of the communications manager 705 or 810 are described.

[0134] At least some of the communication manager 615 and / or its various subcomponents may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, a general purpose processor, DSP, application specific integrated circuit (ASIC), FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or any combination thereof for performing the functions described in the present disclosure may perform the functions of at least some of the communication manager 615 and / or its various subcomponents.

[0135] At least some of the communication manager 615 and / or its various subcomponents may be physically distributed in multiple locations, including being distributed as part of implementing functionality at different physical locations through one or more physical devices. In some examples, according to various aspects of the present disclosure, at least some of the communication manager 615 and / or its various subcomponents may be separate and distinct components. In other examples, according to various aspects of the present disclosure, at least some of the communication manager 615 and / or its various subcomponents may be combined with one or more other hardware components, including, but not limited to, I / O components, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof.

[0136] The VAE service manager 620 can identify a congestion control configuration at the application enabler layer, which includes the ability to collect operational information. In some examples, the operations performed at the application enabler layer are performed by executing instructions associated with the layer (e.g., executed at an application server). The congestion information collector 625 can receive operational information from a group of UEs based on these capabilities. The congestion controller 630 can generate congestion control instructions for one or more UEs in the group of UEs based on the received operational information. The congestion controller 630 can identify the congestion state of the communication type based on monitoring the side link performance.

[0137] The SEAL service manager 635 can identify a congestion control configuration at the application enabler architecture layer that includes capabilities for collecting operational information. In some examples, operations performed at the application enabler architecture layer are performed by executing instructions associated with the layer (e.g., executed at an application server). The sidelink performance component 640 can monitor the sidelink performance of a group of UEs based on these capabilities.

[0138] Output module 645 can manage output signals of device 605. For example, output module 645 can receive signals from other components of device 605 (e.g., communication manager 615) and can send these signals to other components or devices. In some specific examples, output module 645 can send output signals for display in a user interface, for storage in a database or data store, for further processing at a server or server cluster, or for any other processing at any number of devices or systems. In some cases, output module 645 can be as described in reference to Figure 8 Components of I / O controller 815 are described.

[0139] Figure 7 A block diagram 700 of a communication manager 705 is shown according to aspects of the present disclosure. The communication manager 705 may be an example of aspects of the communication manager 515, the communication manager 615, or the communication manager 810 described herein. The communication manager 705 may include a VAE service manager 710, a congestion information collector 715, a congestion controller 720, an information requester 725, a report configuration manager 730, a control instruction component 735, a distribution configuration manager 740, a SEAL interface 745, an information mapping identifier 750, a PLMN communication component 755, a SEAL service manager 760, a sidelink performance component 765, a sidelink manager 770, a VAE interface 775, and a potential congestion predictor 780. Each of these modules may communicate directly or indirectly with each other (e.g., via one or more buses).

[0140] The VAE service manager 710 can identify a congestion control configuration at the application enabler layer, which includes the ability to collect operational information. In some examples, the operations performed at the application enabler layer are performed by executing instructions associated with the layer (e.g., executed at an application server). In some cases, the operational information includes location-specific application information, sidelink group-specific information, vehicle networking service-specific information, UE mobility information, or a combination thereof. In some cases, the application enabler layer includes a vehicle networking application enabler layer.

[0141] The congestion information collector 715 may receive operational information from a group of UEs based on these capabilities. In some examples, the congestion information collector 715 may receive operational information from a group of UEs based on an operational information request. In some examples, the congestion information collector 715 may receive one or more side link status reports from a UE in a group of UEs, wherein the UE relays one or more side link status reports from one or more out-of-coverage UEs of the group of UEs. In some cases, the one or more side link status reports include an aggregated status report from each UE in the group of UEs.

[0142] The congestion controller 720 may generate congestion control instructions for one or more UEs in the group of UEs based on the received operational information. In some examples, the congestion controller 720 may identify a congestion state of a communication type based on monitoring sidelink performance. In some examples, the congestion controller 720 may detect congestion of a service type based on the received operational information, wherein the congestion control instructions for one or more UEs in the group of UEs are associated with the service type and are based on the detected congestion.

[0143] The information requester 725 may send an operation information request to a subset of the set of UEs within the network coverage. In some examples, the information requester 725 may send an operation information trigger with a relay instruction to the subset of the set of UEs within the network coverage based on the operation information mapping. In some examples, the information requester 725 may send a performance information request with a relay instruction to the subset of the set of UEs within the network coverage based on the state information mapping.

[0144] The reporting configuration manager 730 may send a reporting configuration for reporting operational information to the subset of the set of UEs, wherein the reporting configuration includes relay instructions based on the coverage level of each UE in the set of UEs. In some cases, the reporting configuration includes an aggregation instruction associated with the relay instruction.

[0145] The control instruction component 735 may send a congestion control instruction to a UE in the group of UEs, wherein the UE is within the network coverage. In some examples, the control instruction component 735 may receive congestion control instructions for one or more UEs in the group of UEs from the application enabler layer based on sending congestion control information. In some cases, these congestion control instructions include message generation rate adjustment, application communication mode adjustment, priority of the underlying communication type, or a combination thereof. In some cases, these congestion control instructions include priority of the underlying communication type. In some cases, these congestion control information include the underlying communication type.

[0146] The distribution configuration manager 740 may send an instruction distribution configuration for relaying congestion control instructions to the UE. In some examples, the distribution configuration manager 740 may send the instruction distribution configuration to the UE via a user plane, a control plane, system information, radio resource control signaling, or a combination thereof.

[0147] The SEAL interface 745 can receive congestion control information for one or more UEs in a group of UEs from the application enabler architecture layer, wherein congestion control instructions are generated for one or more UEs in the group of UEs based on the received congestion control information. In some examples, operations performed at the application enabler architecture layer are performed by executing instructions associated with the layer (e.g., executed at an application server). For example, identifying a congestion control configuration that includes the ability to collect operational information in the application enabler architecture layer can include: executing instructions associated with the application enabler architecture layer at the application server to identify the congestion control configuration. Similarly, various aspects of the application enabler architecture layer and the functions performed by the application enabler layer can be performed by executing corresponding instructions by the server. In some cases, the application enabler architecture layer includes a vertical service enabler architecture layer having an inter-server interface.

[0148] The information map identifier 750 may identify the operational information map based on the received congestion control information. In some examples, the information map identifier 750 may identify the state information map based on monitoring of the sidelink performance.

[0149] The PLMN communication component 755 can manage an application enabler layer, which includes a vehicle networking application enabler layer that communicates with a public vehicle networking server shared by a group of public land mobile networks or a vehicle networking server accessible from each of the group of public land mobile networks on a user plane. In some cases, the application enabler layer includes a vehicle networking application enabler layer that communicates with a public vehicle networking server shared by a group of public land mobile networks or a vehicle networking server accessible from each of the group of public land mobile networks on a user plane.

[0150] The SEAL service manager 760 may identify congestion control configurations at the application enabler architecture layer that include capabilities for collecting operational information.

[0151] The sidelink performance component 765 can monitor the sidelink performance of a group of UEs based on the capabilities. In some cases, the sidelink performance includes sidelink communication status, sidelink communication statistics, sidelink service quality information, or a combination thereof.

[0152] The lateral link manager 770 may manage lateral link operations for the communication type based on identifying the congestion condition.

[0153] The VAE interface 775 may send congestion control information for one or more UEs in a group of UEs to the application enabler layer based on identifying a congestion state. In some examples, the VAE interface 775 may send congestion control information for one or more UEs in a group of UEs to the application enabler layer based on identifying a potential congestion state.

[0154] The potential congestion predictor 780 may identify potential congestion for the type of communication based on a prediction made from monitoring the sidelink performance.

[0155] Figure 8 According to aspects of the present disclosure, a diagram of a system 800 including a device 805 is shown. The device 805 can be an example of an application server or device 505, device 605, or application server (e.g., VAE or SEAL) as described herein, or include components thereof. The device 805 may include components for two-way data communication, including components for sending communications and components for receiving communications, including a communication manager 810, an I / O controller 815, a transceiver 820, an antenna 825, a memory 830, a processor 840, an input 845, and an output 850. These components can be in electrical communication via one or more buses (e.g., bus 845).

[0156] The communication manager 810 may be an example of the communication manager 615 or 705 as described herein. For example, the communication manager 810 may perform the above reference Figure 6 and Figure 7 Any of the methods or processes described. In some cases, the communications manager 810 may be implemented in hardware, software executed by a processor, firmware, or any combination thereof.

[0157] I / O controller 815 can manage input and output signals for device 805. I / O controller 815 can also manage peripheral devices that are not integrated into device 805. In some cases, I / O controller 815 can represent a physical connection or port for external peripheral devices. In some cases, I / O controller 815 can utilize a computer such as a 805. In some cases, the I / O controller 815 may be implemented as part of a processor. In some cases, a user may interact with the device 805 via the I / O controller 815 or via hardware components controlled by the I / O controller 815.

[0158] The transceiver 820 can communicate bidirectionally via one or more antennas, wired links, or wireless links, as described above. For example, the transceiver 820 can represent a wireless transceiver that can communicate bidirectionally with another wireless transceiver. The transceiver 820 can also include a modem to modulate packets, provide the modulated packets to an antenna for transmission, and demodulate packets received from the antenna. In some cases, the wireless device can include a single antenna 825. However, in some cases, the device can have more than one antenna 825 that can simultaneously send or receive multiple wireless transmissions.

[0159] The memory 830 may include RAM and ROM. The memory 830 may store computer-readable, computer-executable code 835 including instructions that, when executed, cause the processor to perform the various functions described herein. In some cases, specifically, the memory 830 may include a basic input / output system (BIOS), which may control basic hardware or software operations (e.g., interaction with peripheral components or devices).

[0160] Processor 840 may include an intelligent hardware device (e.g., a general purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a separate gate or transistor logic component, a separate hardware component, or any combination thereof). In some examples, processor 840 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into processor 840. Processor 840 may be configured to execute computer-readable instructions stored in a memory (e.g., memory 830) to cause device 805 to perform various functions (e.g., supporting functions or tasks for reclaiming resources based on sidelink feedback).

[0161] The code 835 may include instructions for implementing various aspects of the present disclosure, including instructions for supporting wireless communications. The code 835 may be stored in a non-transitory computer-readable medium such as a system memory or other type of memory. In some cases, the code 835 may not be executed directly by the processor 840, but causes the computer (e.g., when compiled and executed) to perform the functions described herein.

[0162] Fig. 9 1 shows a flow chart of a method 900 according to various aspects of the present disclosure. The operations of the method 900 may be implemented by an application server or a component thereof as described herein. For example, the operations of the method 900 may be implemented by an application server or a component thereof as described herein. Figures 5 to 8 In some examples, the application server may execute an instruction set to control the functional units of the application server to perform the functions described below. Additionally or alternatively, the application server may use special-purpose hardware to perform various aspects of the functions described below.

[0163] At 905, the application server may identify a congestion control configuration at the application enabler layer (e.g., by executing instructions associated with the application enabler layer), the congestion control configuration including a capability for collecting operational information. The operations of 905 may be performed according to the methods described herein. In some examples, aspects of the operations of 905 may be described by referring to Figures 5 to 8 The described VAE service manager is used to execute.

[0164] At 910, the application server may receive operational information from a set of UEs based on the capabilities. The operations of 910 may be performed according to the methods described herein. In some examples, aspects of the operations of 910 may be as described with reference to Figures 5 to 8 The described congestion information collector is performed.

[0165] At 915, the application server may generate congestion control instructions for one or more UEs in the group of UEs based on the received operation information. The operations of 915 may be performed according to the methods described herein. In some examples, aspects of the operations of 915 may be as described with reference to Figures 5 to 8 The congestion controller described is implemented.

[0166] Fig.10 1000 according to various aspects of the present disclosure. The operations of the method 1000 may be implemented by an application server or a component thereof as described herein. For example, the operations of the method 1000 may be implemented by an application server or a component thereof as described herein. Figures 5 to 8 In some examples, the application server may execute an instruction set to control the functional units of the application server to perform the functions described below. Additionally or alternatively, the application server may use special-purpose hardware to perform various aspects of the functions described below.

[0167] At 1005, the application server may identify a congestion control configuration at the application enabler layer that includes a capability for collecting operational information. The operations of 1005 may be performed according to the methods described herein. In some examples, aspects of the operations of 1005 may be described with reference to Figures 5 to 8 The described VAE service manager is used to execute.

[0168] At 1010, the application server may send an operation information request to a subset of a group of UEs within network coverage. The operations of 1010 may be performed according to the methods described herein. In some examples, aspects of the operations of 1010 may be as described with reference to Figures 5 to 8 The described information requester is executed.

[0169] At 1015, the application server may receive operation information from a group of UEs according to the capability, wherein the operation information may be received based on the operation information request. The operation of 1015 may be performed according to the methods described herein. In some examples, aspects of the operation of 1015 may be as described with reference to Figures 5 to 8 The described congestion information collector is performed.

[0170] At 1020, the application server may generate congestion control instructions for one or more UEs in the group of UEs based on the received operation information. The operations of 1020 may be performed according to the methods described herein. In some examples, aspects of the operations of 1020 may be as described with reference to Figures 5 to 8 The congestion controller described is implemented.

[0171] Fig.11 100 according to various aspects of the present disclosure. The operations of the method 1100 may be implemented by an application server or a component thereof as described herein. For example, the operations of the method 1100 may be implemented by an application server or a component thereof as described herein. Figures 5 to 8 In some examples, the application server may execute an instruction set to control the functional units of the application server to perform the functions described below. Additionally or alternatively, the application server may use special-purpose hardware to perform various aspects of the functions described below.

[0172] At 1105, the application server may identify a congestion control configuration at an application enabler layer (e.g., a VAE layer) that includes a capability for collecting operational information. The operations of 1105 may be performed according to the methods described herein. In some examples, aspects of the operations of 1105 may be described with reference to Figures 5 to 8 The described VAE service manager is used to execute.

[0173] At 1110, the application server may receive operational information from a set of UEs based on the capabilities. The operations of 1110 may be performed according to the methods described herein. In some examples, aspects of the operations of 1110 may be as described with reference to Figures 5 to 8 The described congestion information collector is performed.

[0174] At 1115, the application server may generate congestion control instructions for one or more UEs in the group of UEs based on the received operation information. The operations of 1115 may be performed according to the methods described herein. In some examples, aspects of the operations of 1115 may be as described with reference to Figures 5 to 8 The congestion controller described is implemented.

[0175] At 1120, the application server may send a congestion control instruction to a UE in the group of UEs that is within network coverage. The operations of 1120 may be performed according to the methods described herein. In some examples, aspects of the operations of 1120 may be as described with reference to Figures 5 to 8 The control instruction components described are executed.

[0176] Fig.12 1200 according to various aspects of the present disclosure. The operations of the method 1200 may be implemented by an application server or a component thereof as described herein. For example, the operations of the method 1200 may be implemented by an application server or a component thereof as described herein. Figures 5 to 8 In some examples, the application server may execute an instruction set to control the functional units of the application server to perform the functions described below. Additionally or alternatively, the application server may use special-purpose hardware to perform various aspects of the functions described below.

[0177] At 1205, the application server may identify a congestion control configuration at the application enabler layer that includes a capability for collecting operational information. The operations of 1205 may be performed according to the methods described herein. In some examples, aspects of the operations of 1205 may be described with reference to Figures 5 to 8 The described VAE service manager is used to execute.

[0178] At 1210, the application server may receive operational information from a set of UEs based on the capabilities. The operations of 1210 may be performed according to the methods described herein. In some examples, aspects of the operations of 1210 may be as described with reference to Figures 5 to 8 The described congestion information collector is performed.

[0179] At 1215, the application server may receive congestion control information for one or more UEs in the group of UEs from an application enabler architecture layer (e.g., a SEAL layer). The operations of 1215 may be performed according to the methods described herein. In some examples, aspects of the operations of 1215 may be performed as described with reference to Figures 5 to 8 The SEAL interface described is implemented.

[0180] At 1220, the application server may generate a congestion control instruction for one or more UEs in the group of UEs based on the received operation information, wherein generating the congestion control instruction for one or more UEs in the group of UEs is based on the received congestion control information. The operations of 1220 may be performed according to the methods described herein. In some examples, aspects of the operations of 1220 may be performed as described with reference to Figures 5 to 8 The congestion controller described is implemented.

[0181] Fig.13 1300 according to various aspects of the present disclosure. The operations of the method 1300 may be implemented by an application server or a component thereof as described herein. For example, the operations of the method 1300 may be implemented by an application server or a component thereof as described herein. Figures 5 to 8 In some examples, the application server may execute an instruction set to control the functional units of the application server to perform the functions described below. Additionally or alternatively, the application server may use special-purpose hardware to perform various aspects of the functions described below.

[0182] At 1305, the application server may identify a congestion control configuration at the application enabler architecture layer (e.g., by executing instructions associated with the application enabler architecture layer), the congestion control configuration including a capability for collecting operational information. The operations of 1305 may be performed according to the methods described herein. In some examples, aspects of the operations of 1305 may be performed as described with reference to Figures 5 to 8 The SEAL service manager described here is used to perform the above operations.

[0183] At 1310, the application server may monitor the sidelink performance of a group of UEs based on the capabilities. The operations of 1310 may be performed according to the methods described herein. In some examples, aspects of the operations of 1310 may be as described with reference to Figures 5 to 8 The described side link performance components are performed.

[0184] At 1315, the application server may identify a congestion state of the communication type based on monitoring the side link performance. The operations of 1315 may be performed according to the methods described herein. In some examples, aspects of the operations of 1315 may be described as described with reference to Figures 5 to 8The congestion controller described is implemented.

[0185] Fig.14 1400 according to various aspects of the present disclosure. The operations of the method 1400 may be implemented by an application server or a component thereof as described herein. For example, the operations of the method 1400 may be implemented by an application server or a component thereof as described herein. Figures 5 to 8 In some examples, the application server may execute an instruction set to control the functional units of the application server to perform the functions described below. Additionally or alternatively, the application server may use special-purpose hardware to perform various aspects of the functions described below.

[0186] At 1405, the application server may identify a congestion control configuration at the application enabler architecture layer, the congestion control configuration including a capability for collecting operational information. The operations of 1405 may be performed according to the methods described herein. In some examples, aspects of the operations of 1405 may be described with reference to Figures 5 to 8 The SEAL service manager described here is used to perform the above operations.

[0187] At 1410, the application server may monitor the sidelink performance of a group of UEs based on the capabilities. The operations of 1410 may be performed according to the methods described herein. In some examples, aspects of the operations of 1410 may be as described with reference to Figures 5 to 8 The described side link performance components are performed.

[0188] At 1415, the application server may identify a congestion state of the communication type based on monitoring the side link performance. The operations of 1415 may be performed according to the methods described herein. In some examples, aspects of the operations of 1415 may be performed as described with reference to Figures 5 to 8 The congestion controller described is implemented.

[0189] At 1420, the application server may manage sidelink operations of the communication type based on identifying the congestion state. The operations of 1420 may be performed according to the methods described herein. In some examples, aspects of the operations of 1420 may be described as described with reference to Figures 5 to 8 The described sidelink manager is executed.

[0190] It should be noted that the methods described herein describe possible implementations, and these operations and steps may be rearranged or modified, and other implementations are also possible. In addition, two or more aspects from these methods may be combined.

[0191] Although aspects of LTE, LTE-A, LTE-A Pro, or NR systems are described for example purposes, and LTE, LTE-A, LTE-A Pro, or NR terminology is used in most of the description, the techniques described herein may also be applicable beyond LTE, LTE-A, LTE-A Pro, or NR networks. For example, the described techniques may be applicable to various other wireless communication systems, such as Ultra Mobile Broadband (UMB), Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, and other systems and radio technologies not explicitly mentioned herein.

[0192] The information and signals described herein may be represented using any of a variety of different techniques and methods. For example, data, instructions, commands, information, signals, bits, symbols, and chips mentioned throughout the description herein may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0193] A general purpose processor, DSP, ASIC, CPU, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware components or any combination thereof for performing the functions described herein may be used to implement or perform the various exemplary blocks and components described in conjunction with the contents disclosed herein. A general purpose processor may be a microprocessor, or the processor may be any processor, controller, microcontroller or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of a microprocessor and a DSP core, or any other such structure).

[0194] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions may be stored on a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Other examples and implementations also fall within the scope of protection of the present disclosure and the claims thereto. For example, due to the nature of software, the functions described herein may be implemented using software executed by a processor, hardware, firmware, hardware wiring, or any combination thereof. The features used to implement the functions may be physically distributed in multiple locations, including being distributed in different physical locations to implement a portion of the functions.

[0195] Computer-readable media include non-temporary computer storage media and communication media, wherein the communication media include any media that facilitates the transmission of computer programs from one place to another.Non-temporary storage media can be any available media that a general or special-purpose computer can access.For example, but not limited to, non-temporary computer-readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory, compact disc (CD) ROM or other optical disc storage, disk storage or other magnetic storage device, or can be used to carry or store the desired program code unit with instruction or data structure form and can be accessed by a general or special-purpose computer, or a general or special-purpose processor Any other non-temporary medium.In addition, any connection can be appropriately referred to as a computer-readable medium.For example, if the software is transmitted from a website, a server or other remote source using a coaxial cable, an optical fiber cable, a twisted pair, a digital subscriber line (DSL) or wireless technologies such as infrared, wireless and microwaves, then the coaxial cable, optical fiber cable, twisted pair, DSL or wireless technologies such as infrared, wireless and microwaves are included in the definition of the computer-readable medium. As used herein, disks and optical disks include CDs, laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, where disks typically reproduce data magnetically, while optical disks reproduce data optically with lasers. Combinations of the above should also be included within the scope of protection of computer-readable media.

[0196] As used herein (including in the claims), "or" as used in a list item (e.g., a list item ending with a phrase such as "at least one of" or "one or more of") indicates an inclusive list, so that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). In addition, as used herein, the phrase "based on" should not be interpreted as referring to a closed set of conditions. For example, an exemplary step described as "based on condition A" can be based on condition A and condition B without departing from the scope of protection of the present disclosure. In other words, as used herein, the phrase "based on" should be interpreted in the same manner as the phrase "based at least in part on."

[0197] In the drawings, similar components or features have the same reference numerals. In addition, components of the same type may be distinguished by following the reference numeral with a dashed line and a second reference numeral to distinguish the similar components. If only the first reference numeral is used in the specification, the description is applicable to any similar component having the same first reference numeral, regardless of other subsequent reference numerals.

[0198] The specific embodiments described herein in conjunction with the accompanying drawings describe exemplary configurations, but they do not represent all examples that can be implemented, nor do they represent all examples that fall within the scope of protection of the claims. As used herein, the word "exemplary" means "used as an example, instance, or illustration", but does not mean "preferable" or "more advantageous" than other examples. Specific embodiments include specific details that are used to provide a thorough understanding of the described techniques. However, these techniques can be implemented without using these specific details. In some examples, in order to avoid obscuring the concepts of the described examples, well-known structures and devices are shown in block diagram form.

[0199] The above description is centered around the present disclosure in order to enable any person of ordinary skill in the art to implement or use the present disclosure. Various modifications to the present disclosure will be apparent to those of ordinary skill in the art, and the general principles defined herein may also be applied to other variations without departing from the scope of protection of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but is consistent with the broadest scope of the principles and novel features disclosed herein.

Claims

1. A method for wireless communication at a vehicle-to-everything (V2X) application enabler (VAE) server, comprising: identifying, at a VAE layer, a congestion control configuration, the congestion control configuration comprising a capability for collecting operational information related to a plurality of user equipments (UEs), wherein one or more of the plurality of UEs are outside of a network coverage of a network device; Sending an operation information request to a subset of the plurality of UEs within network coverage, wherein sending the operation information request further comprises: sending, to the subset of the plurality of UEs, a reporting configuration for reporting the operational information, wherein the reporting configuration comprises relay instructions based at least in part on a coverage level of each of the plurality of UEs; receiving the operational information from the plurality of UEs based at least in part on the operational information request; and Congestion control instructions are generated for one or more UEs of the plurality of UEs based at least in part on the received operational information.

2. The method according to claim 1, wherein: The reporting configuration includes aggregation instructions associated with the relay instructions.

3. The method according to claim 1, further comprising: Congestion for a service type is detected based at least in part on the received operational information, wherein the congestion control instructions for the one or more UEs of the plurality of UEs are associated with the service type and are based at least in part on the detected congestion.

4. The method according to claim 1, further comprising: The congestion control instruction is sent to a UE among the multiple UEs, where the UE is within network coverage.

5. The method according to claim 4, wherein: Sending the congestion control instruction further includes: Sending an instruction distribution configuration for relaying the congestion control instruction to the UE.

6. The method according to claim 4, wherein: Sending the congestion control instruction further includes: The command distribution configuration is sent to the UE via a user plane, a control plane, system information, a radio resource control signaling, or a combination thereof.

7. The method according to claim 1, further comprising: Congestion control information for the one or more UEs of the plurality of UEs is received from an application enabler architecture layer, wherein the congestion control instructions are generated for the one or more UEs of the plurality of UEs based at least in part on the received congestion control information.

8. The method according to claim 1, further comprising: identifying an operational information map based at least in part on the received congestion control information; as well as An operational information trigger with relay instructions is sent to a subset of the plurality of UEs within network coverage based at least in part on the operational information map.

9. The method according to claim 1, wherein: The operation information includes location-specific application information, side link group-specific information, Internet of Vehicles service-specific information, UE mobility information, or a combination thereof.

10. The method according to claim 1, wherein: The congestion control instructions include message generation rate adjustment, application communication mode adjustment, priority of underlying communication type, or a combination thereof.

11. The method according to claim 1, wherein: The VAE layer communicates with a public vehicle networking server shared by a plurality of public land mobile networks or a vehicle networking server accessible from each of the plurality of public land mobile networks on a user plane.

12. The method according to claim 1, wherein: Identifying, at the VAE layer, the congestion control configuration including the capability for collecting, in the VAE layer, operational information related to the plurality of UEs comprises: Instructions associated with the VAE layer are executed at an application server to identify the congestion control configuration.

13. A method for wireless communication at a vertical service enabler architecture layer (SEAL) server, comprising: identifying a congestion control configuration at the SEAL layer, the congestion control configuration including a capability for collecting operational information; Monitoring sidelink performance of multiple user equipments (UEs) according to the capability, wherein monitoring the sidelink performance of the multiple UEs further comprises: receiving one or more sidelink status reports from a UE of the plurality of UEs, wherein the UE relays the one or more sidelink status reports from one or more out-of-coverage UEs of the plurality of UEs; identifying a congestion condition for a communication type based at least in part on monitoring the sidelink performance; and Congestion control information for one or more of the plurality of UEs is sent to an application enabler layer based at least in part on identifying the congestion state.

14. The method according to claim 13, further comprising: Sidelink operation of the communication type is managed based at least in part on identifying the congestion condition.

15. The method according to claim 13, further comprising: Congestion control instructions are received from an application enabler layer for the one or more UEs of the plurality of UEs based at least in part on sending the congestion control information.

16. The method according to claim 15, wherein: The congestion control instructions include a priority level for the underlying communication type.

17. The method according to claim 13, wherein: The congestion control information includes the underlying communication type.

18. The method according to claim 13, wherein: Identifying the congestion state of the communication type further includes: identifying potential congestion for the type of communication based at least in part on a prediction based on monitoring performance of the sidelink; and Congestion control information for one or more of the plurality of UEs is sent to an application enabler layer based at least in part on identifying the potential congestion state.

19. The method according to claim 13, wherein: The one or more sidelink status reports include an aggregated status report from each of the plurality of UEs.

20. The method of claim 13, further comprising: identifying a state information map based at least in part on monitoring the sidelink performance; as well as Based at least in part on the state information map, a performance information request with relay instructions is sent to a subset of the plurality of UEs within network coverage.

21. The method according to claim 13, wherein: The sidelink performance includes sidelink communication status, sidelink communication statistics, sidelink quality of service information, or a combination thereof.

22. The method according to claim 13, wherein: The application enabler layer includes a vehicle networking application enabler layer that communicates with a public vehicle networking server shared by a plurality of public land mobile networks or a vehicle networking server accessible from each of the plurality of public land mobile networks on a user plane.

23. The method according to claim 13, wherein: Identifying, at the SEAL layer, the congestion control configuration including a capability for collecting operational information in the SEAL layer, including: Instructions associated with the SEAL layer are executed at an application server to identify the congestion control configuration, wherein the SEAL layer includes an inter-server interface.

24. An apparatus for wireless communication, comprising: processor, a memory coupled to the processor; as well as Instructions stored in the memory and executable by the processor to cause the device to: identifying, at a vehicle-to-everything (V2X) application enabler (VAE) layer, a congestion control configuration, the congestion control configuration comprising a capability for collecting operational information associated with a plurality of user equipments (UEs), wherein one or more of the plurality of UEs are outside of a network coverage of a network device; Sending an operation information request to a subset of the plurality of UEs within network coverage, wherein sending the operation information request further comprises: sending, to the subset of the plurality of UEs, a reporting configuration for reporting the operational information, wherein the reporting configuration comprises relay instructions based at least in part on a coverage level of each of the plurality of UEs; receiving the operational information from the plurality of UEs based at least in part on the operational information request; and Congestion control instructions are generated for one or more UEs of the plurality of UEs based at least in part on the received operational information.

25. The device according to claim 24, wherein: The reporting configuration includes aggregation instructions associated with the relay instructions.

26. The device according to claim 24, wherein: The instructions may also be executed by the processor to cause the device to perform the following operations: Congestion for a service type is detected based at least in part on the received operational information, wherein the congestion control instructions for the one or more UEs of the plurality of UEs are associated with the service type and are based at least in part on the detected congestion.

27. The device according to claim 24, wherein: The instructions may also be executed by the processor to cause the device to perform the following operations: The congestion control instruction is sent to a UE among the multiple UEs, where the UE is within network coverage.

28. The device according to claim 27, wherein Sending the congestion control instruction further includes: Sending an instruction distribution configuration for relaying the congestion control instruction to the UE.

29. The device according to claim 27, wherein: Sending the congestion control instruction further includes: The command distribution configuration is sent to the UE via a user plane, a control plane, system information, a radio resource control signaling, or a combination thereof.

30. The device according to claim 24, wherein: The instructions may also be executed by the processor to cause the device to perform the following operations: Congestion control information for the one or more UEs of the plurality of UEs is received from an application enabler architecture layer, wherein the congestion control instructions are generated for the one or more UEs of the plurality of UEs based at least in part on the received congestion control information.

31. The device according to claim 24, wherein: The instructions may also be executed by the processor to cause the device to perform the following operations: identifying an operational information map based at least in part on the received congestion control information; and An operational information trigger with relay instructions is sent to a subset of the plurality of UEs within network coverage based at least in part on the operational information map.

32. The apparatus of claim 24, wherein: The operation information includes location-specific application information, side link group-specific information, Internet of Vehicles service-specific information, UE mobility information, or a combination thereof.

33. The device according to claim 24, wherein: The congestion control instructions include message generation rate adjustment, application communication mode adjustment, priority of underlying communication type, or a combination thereof.

34. The device according to claim 24, wherein: The VAE layer communicates with a public vehicle networking server shared by a plurality of public land mobile networks or a vehicle networking server accessible from each of the plurality of public land mobile networks on a user plane.

35. The apparatus of claim 24, wherein: Identifying, at the VAE layer, the congestion control configuration including the capability for collecting, at the VAE layer, operational information related to the plurality of UEs includes: Instructions associated with the VAE layer are executed at an application server to identify the congestion control configuration.

36. An apparatus for wireless communication, comprising: processor, a memory coupled to the processor; as well as Instructions stored in the memory and executable by the processor to cause the device to: identifying a congestion control configuration at a vertical service enabler architecture layer (SEAL) layer, the congestion control configuration including a capability for collecting operational information; Monitoring sidelink performance of multiple user equipments (UEs) according to the capability, wherein monitoring the sidelink performance of the multiple UEs further comprises: receiving one or more sidelink status reports from a UE of the plurality of UEs, wherein the UE relays the one or more sidelink status reports from one or more out-of-coverage UEs of the plurality of UEs; identifying a congestion condition for a communication type based at least in part on monitoring the sidelink performance; and Congestion control information for one or more of the plurality of UEs is sent to an application enabler layer based at least in part on identifying the congestion state.

37. The device according to claim 36, wherein The instructions may also be executed by the processor to cause the device to perform the following operations: Sidelink operation of the communication type is managed based at least in part on identifying the congestion condition.

38. The device according to claim 36, wherein The instructions may also be executed by the processor to cause the device to perform the following operations: Congestion control instructions are received from an application enabler layer for the one or more UEs of the plurality of UEs based at least in part on sending the congestion control information.

39. The device according to claim 38, wherein The congestion control instructions include a priority level for the underlying communication type.

40. The apparatus of claim 36, wherein: The congestion control information includes the underlying communication type.

41. The apparatus of claim 36, wherein: Identifying the congestion state of the communication type further includes: identifying potential congestion for the type of communication based at least in part on a prediction based on monitoring performance of the sidelink; and Congestion control information for one or more of the plurality of UEs is sent to an application enabler layer based at least in part on identifying the potential congestion state.

42. The apparatus of claim 36, wherein: The one or more sidelink status reports include an aggregated status report from each of the plurality of UEs.

43. The apparatus of claim 36, wherein: The instructions may also be executed by the processor to cause the device to perform the following operations: identifying a state information map based at least in part on monitoring the sidelink performance; and Based at least in part on the state information map, a performance information request with relay instructions is sent to a subset of the plurality of UEs within network coverage.

44. The apparatus of claim 36, wherein: The sidelink performance includes sidelink communication status, sidelink communication statistics, sidelink quality of service information, or a combination thereof.

45. The apparatus of claim 36, wherein: The application enabler layer includes a vehicle networking application enabler layer that communicates with a public vehicle networking server shared by a plurality of public land mobile networks or a vehicle networking server accessible from each of the plurality of public land mobile networks on a user plane.

46. ​​The apparatus of claim 36, wherein: Identifying, at the SEAL layer, the congestion control configuration including a capability for collecting operational information in the SEAL layer, including: Instructions associated with the application enabler architecture layer are executed at an application server to identify the congestion control configuration, wherein the application enabler architecture layer includes a vertical service enabler architecture layer having an inter-server interface.

47. An apparatus for wireless communication, comprising: means for identifying, at a vehicle-to-everything (V2X) application enabler (VAE) layer, a congestion control configuration, the congestion control configuration comprising a capability for collecting operational information associated with a plurality of user equipments (UEs), wherein one or more of the plurality of UEs are outside of a network coverage of a network device; A unit configured to send an operation information request to a subset of the plurality of UEs within network coverage, wherein sending the operation information request further comprises: sending a reporting configuration for reporting the operational information to the subset of the plurality of UEs, wherein the reporting configuration comprises relay instructions based at least in part on a coverage level of each of the plurality of UEs; means for receiving the operating information from the plurality of UEs based at least in part on the operating information request; and Means for generating congestion control instructions for one or more UEs of the plurality of UEs based at least in part on the received operational information.

48. The apparatus of claim 47, wherein: The reporting configuration includes aggregation instructions associated with the relay instructions.

49. The apparatus of claim 47, further comprising: Means for detecting congestion for a service type based at least in part on the received operational information, wherein the congestion control instructions for the one or more UEs of the plurality of UEs are associated with the service type and are based at least in part on the detected congestion.

50. The apparatus of claim 47, further comprising: A unit for sending the congestion control instruction to a UE among the multiple UEs, wherein the UE is within network coverage.

51. The apparatus of claim 50, wherein: Sending the congestion control instruction further includes: Sending an instruction distribution configuration for relaying the congestion control instruction to the UE.

52. The apparatus of claim 50, wherein: Sending the congestion control instruction further includes: The command distribution configuration is sent to the UE via a user plane, a control plane, system information, a radio resource control signaling, or a combination thereof.

53. The apparatus of claim 47, further comprising: Means for receiving congestion control information for the one or more UEs of the plurality of UEs from an application enabler architecture layer, wherein the congestion control instructions are generated for the one or more UEs of the plurality of UEs based at least in part on the received congestion control information.

54. The apparatus of claim 47, further comprising: means for identifying an operational information map based at least in part on the received congestion control information; as well as Means for sending an operational information trigger with relay instructions to a subset of the plurality of UEs within network coverage based at least in part on the operational information map.

55. The apparatus of claim 47, wherein: The operation information includes location-specific application information, side link group-specific information, Internet of Vehicles service-specific information, UE mobility information, or a combination thereof.

56. The apparatus of claim 47, wherein: The congestion control instructions include message generation rate adjustment, application communication mode adjustment, priority of underlying communication type, or a combination thereof.

57. The apparatus of claim 47, wherein: The VAE layer communicates with a public vehicle networking server shared by a plurality of public land mobile networks or a vehicle networking server accessible from each of the plurality of public land mobile networks on a user plane.

58. The apparatus of claim 47, wherein: Identifying, at the VAE layer, the congestion control configuration including the capability for collecting, in the VAE layer, operational information related to the plurality of UEs comprises: Instructions associated with the VAE layer are executed at an application server to identify the congestion control configuration.

59. An apparatus for wireless communication, comprising: means for identifying, at a vertical service enabler architecture layer (SEAL) layer, a congestion control configuration, the congestion control configuration including a capability for collecting operational information; A unit for monitoring sidelink performance of a plurality of user equipments (UEs) based on the capability, wherein monitoring the sidelink performance of the plurality of UEs further comprises: receiving one or more sidelink status reports from a UE of the plurality of UEs, wherein the UE relays the one or more sidelink status reports from one or more out-of-coverage UEs of the plurality of UEs; means for identifying a congestion condition for a communication type based at least in part on monitoring the sidelink performance; and Means for sending congestion control information for one or more of the plurality of UEs to an application enabler layer based at least in part on identifying the congestion state.

60. The apparatus of claim 59, further comprising: Means for managing sidelink operation of the communication type based at least in part on identifying the congestion condition.

61. The apparatus of claim 59, further comprising: Means for receiving, from the application enabler layer, congestion control instructions for the one or more UEs of the plurality of UEs based at least in part on sending the congestion control information.

62. The device according to claim 61, wherein The congestion control instructions include a priority level for the underlying communication type.

63. The apparatus of claim 59, wherein: The congestion control information includes the underlying communication type.

64. The apparatus of claim 59, wherein: Identifying the congestion state of the communication type further includes: identifying potential congestion for the type of communication based at least in part on a prediction based on monitoring performance of the sidelink; and Congestion control information for one or more of the plurality of UEs is sent to an application enabler layer based at least in part on identifying the potential congestion state.

65. The apparatus of claim 59, wherein: The one or more sidelink status reports include an aggregated status report from each of the plurality of UEs.

66. The apparatus of claim 59, further comprising: means for identifying a state information map based at least in part on monitoring said sidelink performance; as well as Means for sending a performance information request with relay instructions to a subset of the plurality of UEs within network coverage based at least in part on the state information map.

67. The apparatus of claim 59, wherein: The sidelink performance includes sidelink communication status, sidelink communication statistics, sidelink quality of service information, or a combination thereof.

68. The apparatus of claim 59, wherein: The application enabler layer includes a vehicle networking application enabler layer that communicates with a public vehicle networking server shared by a plurality of public land mobile networks or a vehicle networking server accessible from each of the plurality of public land mobile networks on a user plane.

69. The apparatus of claim 59, wherein: Identifying, at the SEAL layer, the congestion control configuration including a capability for collecting operational information in the SEAL layer, including: Instructions associated with the SEAL layer are executed at an application server to identify the congestion control configuration, wherein the SEAL layer includes an inter-server interface.

70. A non-transitory computer-readable medium storing code for wireless communication, the code comprising instructions executable by a processor to: A congestion control configuration is identified at a vehicle-to-everything (V2X) application enabler (VAE) layer, the congestion control configuration including a capability for collecting operational information associated with a plurality of user equipments (UEs), wherein: One or more UEs among the plurality of UEs are outside the network coverage of the network device; Sending an operation information request to a subset of the plurality of UEs within network coverage, wherein sending the operation information request further comprises: sending, to the subset of the plurality of UEs, a reporting configuration for reporting the operational information, wherein the reporting configuration comprises relay instructions based at least in part on a coverage level of each of the plurality of UEs; receiving the operational information from the plurality of UEs based at least in part on the operational information request; and Congestion control instructions are generated for one or more UEs of the plurality of UEs based at least in part on the received operational information.

71. A non-transitory computer readable medium storing code for wireless communication, the code comprising instructions executable by a processor to: identifying a congestion control configuration at a vertical service enabler architecture layer (SEAL) layer, the congestion control configuration including a capability for collecting operational information; monitoring sidelink performance of a plurality of user equipments (UEs) based on the capability, wherein: Monitoring the sidelink performance of the multiple UEs further includes: receiving one or more sidelink status reports from a UE of the plurality of UEs, wherein the UE relays the one or more sidelink status reports from one or more out-of-coverage UEs of the plurality of UEs; identifying a congestion condition for a communication type based at least in part on monitoring the sidelink performance; and Congestion control information for one or more of the plurality of UEs is sent to an application enabler layer based at least in part on identifying the congestion state.

Images