Resource allocation and configuration for broadcast and unicast operations on the sidelink for NR V2X
By combining the LTE resource allocation framework and the NR V2X system, adopting network scheduling and autonomous resource selection mode, and dynamically adjusting the resource pool, the resource allocation problem of the NR V2X system within and outside the coverage area is solved, and efficient unicast and broadcast communications are achieved.
Patent Information
- Application Number
- CN201980063993.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2018-09-27
- Filing Date
- 2019-09-27
- Publication Date
- 2025-09-19
- Estimated Expiration
- 2039-09-27
AI Technical Summary
The existing NR V2X system has difficulty in effectively supporting seamless connectivity in unicast and broadcast communication modes in terms of resource allocation and configuration. Especially in scenarios outside the network coverage area, resource allocation is not flexible enough, resulting in resource waste and inefficiency.
It adopts an LTE-based resource allocation framework, combined with network scheduling and autonomous resource selection mode, and dynamically adjusts the use of resource pools through pre-configured authorization and RRC signaling to ensure effective V2X communication in scenarios both within and outside the coverage area.
It achieves seamless connection of NR V2X communications within and outside the coverage area, improves resource utilization efficiency, meets the needs of high-reliability and low-latency unicast transmission, and optimizes the coexistence of broadcast and unicast traffic.
Smart Images

Figure CN113170444B_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 737,731 (AB5660-PCT), filed September 27, 2018. Said application No. 62 / 737,731 is hereby incorporated by reference in its entirety. Background Art
[0003] To effectively address the use case requirements for advanced vehicle-to-everything (V2X) use cases over New Radio (NR), it is necessary to define the overall system design, specifically the resource allocation and configuration of the sidelink for user equipment (UE) devices operating in unicast and broadcast communication modes. To this end, a solution can be provided to define functionality based on Long Term Evolution (LTE) and consider the harmonious coexistence of unicast and broadcast traffic on the enhanced sidelink. BRIEF DESCRIPTION OF THE DRAWINGS
[0004] The claimed subject matter is particularly pointed out and distinctly described in the concluding portion of the specification. However, such subject matter may be understood by reference to the following detailed description when read with the accompanying drawings, wherein:
[0005] Figure 1 is an illustration of an uplink grant process in which uplink transmission is lost according to one or more embodiments.
[0006] Figure 2 The architecture of a system of networks according to some embodiments is shown.
[0007] Figure 3 Example components of an apparatus according to some embodiments are shown.
[0008] Figure 4 Example interfaces of baseband circuitry according to some embodiments are shown.
[0009] It should be understood that for simplicity and / or clarity of illustration, the elements illustrated in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Furthermore, where deemed appropriate, reference numerals have been repeated in the drawings to indicate corresponding and / or similar elements. DETAILED DESCRIPTION
[0010] In the following detailed description, a number of specific details are provided to provide a comprehensive understanding of the claimed subject matter. However, it will be understood by those skilled in the art that the claimed subject matter may be practiced without these specific details. In other cases, well-known methods, processes, components and / or circuits have not been described in detail.
[0011] In the following description and / or claims, the terms "coupled" and "connected" and their derivatives may be used. In a particular embodiment, "connected" may be used to indicate that two or more elements are in direct physical and / or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical and / or electrical contact. However, "coupled" may also mean that two or more elements may not be in direct contact with each other, but may still cooperate and / or interact with each other. For example, "coupled" may mean that two or more elements are not in direct contact with each other, but are indirectly joined together via another element or an intermediate element. Finally, the terms "on," "overlying," and "above" may be used in the following description and claims. "on," "overlying," and "above" may be used to indicate that two or more elements are in direct physical contact with each other. However, it should be noted that "above" may also mean that two or more elements are not in direct contact with each other. For example, "above" may mean that one element is higher than another element but is not in contact with each other, and may have another one or more elements between the two elements. Furthermore, the term "and / or" may mean "and," it may mean "or," it may mean "exclusive or," it may mean "one," it may mean "some but not all," it may mean "neither," and / or it may mean "both," but does not limit the scope of the claimed subject matter in this respect. In the following description and / or claims, the terms "include" and "comprising," along with their derivatives, may be used and are intended as synonyms for each other.
[0012] Now see Figure 1 , an illustration of an uplink grant process in which uplink transmission is lost according to one or more embodiments will be discussed. As vehicle-to-everything (V2X) use cases based on New Radio (NR) are becoming increasingly popular, procedures should be defined to effectively allow different NR V2X User Equipment (UE) devices to perform V2X transmissions regardless of their physical state, mobility, and location within the network coverage area. Generally speaking, V2X UEs may have very different mobility profiles than non-V2X UEs and therefore should have specific configurations and system designs that allow for seamless V2X connectivity. Since a vehicle UE (V-UE) is not guaranteed to be within coverage at any given point in time, resources should also be allocated for out-of-coverage scenarios. This resource allocation in the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) standard can be handled through two operating modes.
[0013] The first mode of operation involves network scheduling, which is applicable only in RRC_CONNECTED mode and within the coverage of an evolved Node B (eNB). The UE requests resources for transmission from the eNB or next-generation Node B (gNB) for the NR network. The eNB or gNB may schedule dedicated resources for the transmission based on relevant information indicated by the UE.
[0014] The second mode of operation involves autonomous resource selection, where the UE selects a set of resources from a specific resource pool used for V2X transmissions. This applies to both in-coverage and out-of-coverage scenarios. The resource pool selection can be based on multiple factors, including the UE's geographic location.
[0015] For the network (NW) scheduled case and the autonomous case, the transmission is broadcast based, where the UE does not employ a dedicated connection when sending packets over the side link. In the case of NR V2X and the possibility of supporting unicast and broadcast based communications, an added dimension of complexity is involved when considering the resource configuration design and procedures for NR V2X. However, it is expected that the overall design can still be centered around the broadcast-based LTE framework, which is based on supporting the two operating modes as described above. In fact, NR V2X is expected to have similar operating modes as LTE, namely network scheduled operation and autonomous resource selection. Taking into account at least the sidelink operation, one way to deal with this is to reuse the LTE resource allocation framework. Specifically, as a starting point, if the UE is within the coverage of a suitable serving cell and is allowed to use the selected frequency for V2X communication, or if the UE is authorized to perform V2X communication outside the coverage area, the UE can perform sidelink V2X communication for NR. The use of pre-configured authorization can be based on standards similar to those involved in LTE. Additionally, Radio Resource Control (RRC) signaling can be used to indicate a UE’s interest in V2X communications, similar to the SidelinkUEInformation information element (IE) in LTE.
[0016] According to one or more embodiments, a resource pool configuration for autonomous resource selection mode may be utilized. As shown in NR network 100, a first operating mode, network-scheduled operation, may be utilized when a first UE (UE 1) 112 is within range of and connected to a next-generation Node B (gNB) 110. In this mode, first UE 112 is within range of a gNB and in RRC_CONNECTED mode. First UE 112 may request resources from gNB 110 for transmissions, and gNB 110 may schedule dedicated resources for transmissions based on some relevant information indicated by first UE 112.
[0017] For the case of autonomous resource selection mode, for example, when first UE 112 is outside the operating range of gNB 110, the overall configuration of sidelink V2X communications in network 100 may be handled similarly to how it is handled in LTE. UE 112 is permitted to use the set of resources or resource pools when in RRC_CONNECTED or RRC_IDLE mode, as appropriate, which may be included in system information broadcast by the cell or provided via dedicated signaling, such as RRC signaling. This may also include the set of exception pools and associated configurations. In LTE, the exception transmit (TX) pool is designed for specific scenarios where UE 112 cannot use the normal TX pool, such as handover, radio link failure, transition from RRC_IDLE to RRC_CONNECTED, and involves resources for emergency transmissions. In such cases, UE 112 may select resources from the exception pool for V2X transmissions. For example, in the event of a handover, the exception pool configuration can be included in the handover command, and UE 112 can use this configuration to perform V2X transmissions therebetween. Similarly, in the event of a radio link failure (RLF), UE 112 can temporarily use an exception pool from the configuration provided in the system information. For the NR network 100, reusing the same functionality may be beneficial depending on the mobility of individual V-UEs. While using an exception TX resource pool can result in resource fragmentation and inefficient operation, the advantages of using this resource pool may outweigh the disadvantages.
[0018] Since LTE operation is broadcast-based, the use of such resource pools may also depend on the congestion status and the priority of the traffic to be sent. In LTE, this is based on the channel busy rate (CBR) and the transmission parameters mapped to the various pools, so that the UE 112 selects resources and TX parameters based on the priority of the traffic. For the NR network 100, it can be assumed that similar metrics can be defined for resource usage to handle broadcast traffic, so the same principles apply. In this case, the system information may include a configuration when the UE 112 can use resource pools based on the current resource utilization measured by the UE 112. Overall sensing-based usage is essential to allow efficient use of shared resources and should be used in NR V2X to at least support broadcast operation.
[0019] In one or more embodiments, resource configuration for unicast operation may be utilized. In one example, a first UE 112 may communicate with a second UE (UE 2) 114 via a unicast link 120. In another example, the first UE 112 may transmit to a second UE 114 and a third UE (UE 3) 116 via a multicast link 122, where UE 2 and UE 3 comprise a defined group of UEs. In another example, the first UE 112 may communicate with all nearby UEs, including UE 2, UE 3, and a fourth UE (UE 4) 118, via a broadcast link 124, as an example. Since the fundamental difference between broadcast and unicast and / or multicast transmissions is based on whether they are addressed to a specific UE or to a group of UEs, which have been previously determined during the connection establishment process, this raises the question of whether the physical resources used for V2X transmissions are dedicated or shared with the physical resources used for broadcast transmissions, particularly for the autonomous resource allocation mode. With advanced use cases and stringent requirements for NR V2X, unicast transmissions can be particularly useful for high-reliability and low-latency scenarios, such as extended sensor sharing or remote driving. In such cases, transmissions from UEs for these use cases and / or V2X services can be provided with an appropriate set of resources and quality of service (QoS) for proper operation. From this perspective, an appropriate set of sidelink resources can be allocated to meet the stringent QoS requirements of advanced V2X use cases.
[0020] In this regard, for NR V2X, resource partitioning and associated configurations based on operating mode, unicast, multicast, and broadcast, can be considered. For operating mode 2, which involves autonomous resource selection, as described above, the expected need for V2X applications to establish unicast links is independent of their operating mode, operating mode 1 or 2. Based on this assumption, separate, non-overlapping resources can be allocated for unicast transmissions. Even though various sidelink enhancements are considered for the unicast case, hybrid automatic repeat request (HARQ) feedback, radio link control (RLC) acknowledgement mode (AM), etc., the underlying physical resource set itself is very helpful in determining whether QoS requirements can be met. Therefore, at least for unicast operation, a dedicated resource pool for V2X communications on the sidelink can be considered. This can ensure reduced contention with broadcast traffic and enhanced resource efficiency from a system perspective. Generally speaking, the same mechanism can also be extended to the multicast case.
[0021] In terms of configuration, these resource pools can be individually included in system information or pre-configured for NR UEs and mapped to specific V2X services or service types. This allows any given UE, after establishing a unicast connection, to use the specific resource pool allocated to the relevant V2X service or service type. While the overall sensing-based transmission process is still required, this is not a truly dedicated set of resources. Instead, resource pooling can provide better performance than sharing transmission with other broadcast traffic. The detailed operation of such resource pooling can be described as follows.
[0022] In one or more embodiments, two options may be provided regarding how to configure resource pools for V2X unicast, groupcast, and broadcast communications, as well as a third combined option.
[0023] A first option includes configuring a resource pool for any multicast and broadcast and a separate resource pool for any unicast, regardless of the unicast pair. For example, a resource pool configured for unicast may be used for unicast pair #1 including source identifier (ID) (A) and destination ID (B) and unicast pair #2 including source ID (A) and destination ID (C). In this case, if any multicast or broadcast communication is triggered and operation mode 2 including UE autonomous resource selection is used, the transmitter UE, such as the first UE 112, may select the resource pool configured for multicast and broadcast. Similarly, if any unicast is triggered and operation mode 2 is used, the transmitter UE will select the resource pool configured for unicast. In other aspects, if a unicast connection is established, the receiver UE, such as the second UE 114, may monitor the resource pool configured for unicast. Note that control messages for unicast establishment may be transmitted and / or received via the resource pool configured for multicast and broadcast.
[0024] To avoid conflicts in resource selection within a resource pool or congestion between resource pools, resource selection within a resource pool, or when multiple resource pools are configured, can also be performed based on a specific function. An example of this is using a hash function using source and / or destination IDs to distribute the selected resource pool or pools to multiple transmitter UEs. Note that as a result of the hash function for an established unicast session, receiver UEs can only monitor the corresponding resources or resource pools.
[0025] The second option includes configuring resource polling for any multicast and broadcast and one or more resource pools for a specific unicast pair. In this case, extending the above example, one or more resource pools for unicast pair #1 including source ID (A) and destination ID (B) and one or more resource pools for unicast pair #2 including source ID (A) and destination ID (C) can be configured separately. If any multicast or broadcast is triggered and mode two including UE autonomous resource selection is used, the transmitter UE, such as the first UE 112, can select the resource pool configured for multicast and broadcast. Similarly, if unicast is triggered and mode two is used, the transmitter UE (UE 1) can select the resource pool configured for the associated unicast link, for example, if unicast pair #1 is triggered, the resource pool configured with the association with unicast pair #1 is used. If the unicast pair has been established, the receiver UE, such as the second UE 114, can monitor the resource pool configured for the associated unicast.
[0026] This type of configuration is more like a dedicated configuration than a configuration via system information. In this case, the network 100 should be aware of the unicast pair information, and the UE can notify the network 100 via an RRC message or as part of a medium access control (MAC) header / control information element. In some embodiments, the network 100 can more dynamically activate and / or deactivate candidate resource pools, depending on the amount of data the UE must transmit and the active unicast pairs, i.e., which unicast pairs need to be transmitted. For this activation / deactivation, the network 100 can send commands via a MAC header, a MAC control information element (CE), or physical control information. To avoid sending multiple commands to both the transmitter UE and the receiver UE for this unicast, the network 100 can assign a pairing ID to both UEs. If the transmitter UE receives an activation command using this pairing ID, the UE considers the resource pool associated with the unicast pair to be activated and uses it for transmissions associated with the unicast pair. If the receiver UE receives an activation command using this pairing ID, the UE will monitor any data reception through this resource pool. Using the same principle, if the transmitter UE receives a deactivation command by using the pairing ID, the UE regards the resource pool as deactivated and it will not be used. If the receiving UE receives a deactivation command by using the pairing ID, the UE will stop monitoring the resource pool.
[0027] In one or more embodiments, a combination of the first option and the second option may be utilized. For example, the first option may be used in configuration via system information, and the second option may be used in configuration via dedicated RRC configuration.
[0028] In one or more embodiments, the congestion control mechanism may be specifically used for unicast transmissions. In LTE, as described above, V2X congestion control for the sidelink resource pool is based on channel busy rate (CBR) and proximity service (ProSe) per-packet priority (PPP) mapping to ensure that high-priority traffic takes precedence when congested resources become an issue. For NR V2X, considering both unicast and broadcast, whether separate non-overlapping resources are allocated for autonomous resource selection operation, it can be considered whether unicast traffic should be subject to the same priority rules as broadcast traffic. One reason why a V2X application at a given UE would establish a unicast connection is to meet specific QoS requirements that are not or cannot be met otherwise using broadcast operations. In this sense, unicast traffic inherently corresponds to a higher overall priority than broadcast traffic. It should be noted that the priority here does not refer to any specific QoS parameters, but rather that the traffic generally needs to be handled with higher urgency than broadcast traffic. The QoS parameters for NR V2X are expected to be different from LTE, but the basic principle can still be that resource usage can be regulated based on these parameters in general. Therefore, a corresponding set of rules such as similar CBR-PPPP mapping for unicast traffic can generally be configured differently than for broadcast traffic. This can be done by adding separate configurations for unicast-based and broadcast-based transmissions in system information or pre-configuration of the NR V-UE.
[0029] Figure 2 The architecture of a system 200 of a network according to some embodiments is shown. System 200 is shown to include user equipment (UE) 201 and UE 202. UE 201 and UE 202 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but these UEs can also include any mobile or non-mobile computing devices, such as personal data assistants (PDAs), pagers, laptop computers, desktop computers, wireless handheld terminals, or any computing device that includes a wireless communication interface.
[0030] In some embodiments, either UE 201 or UE 202 may comprise an Internet of Things (IoT) UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with an MTC server or device via a public land mobile network (PLMN), proximity-based services (ProSe), or device-to-device (D2D) communication, a sensor network, or an IoT network. The M2M or MTC data exchange may be a machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.
[0031] UE 201 and UE 202 may be configured to connect, e.g., be communicatively coupled, to a radio access network (RAN) 210, which may be, for example, an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN), a next generation RAN (NG RAN), or some other type of RAN. UE 201 and UE 202 utilize connection 203 and connection 204, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example, connection 203 and connection 204 are shown as air interfaces to achieve communicatively coupling and may be consistent with cellular communication protocols, such as a global system for mobile communications (GSM) protocol, a code division multiple access (CDMA) network protocol, a push-to-talk (PTT) protocol, a PTT over cellular (POC) protocol, a universal mobile telecommunications system (UMTS) protocol, a 3GPP long term evolution (LTE) protocol, a fifth generation (5G) protocol, a new radio (NR) protocol, or the like.
[0032] In this embodiment, UE 201 and UE 202 may also directly exchange communication data via the ProSe interface 205. The ProSe interface 205 may alternatively be referred to as a sidelink interface including one or more logical channels including, but not limited to, a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).
[0033] UE 202 is shown as being configured to access access point (AP) 206 via connection 207. Connection 207 may comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 206 would include Wi-Fi. In this example, AP 206 is shown connected to the Internet without being connected to the core network of the wireless system (described in further detail below).
[0034] The RAN 210 may include one or more access nodes that enable connections 203 and 204. These access nodes (ANs) may be referred to as base stations (BSs), Node Bs, evolved Node Bs (eNBs), next-generation Node Bs (gNBs), RAN nodes, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). The RAN 210 may include one or more RAN nodes (e.g., macro RAN nodes 211) for providing macro cells, and one or more RAN nodes (e.g., low power (LP) RAN nodes 212) for providing femto cells or pico cells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth than macro cells).
[0035] Either the RAN node 211 or the RAN node 212 may terminate the air interface protocol and may be the first point of contact for the UE 201 or the UE 202. In some embodiments, either the RAN node 211 or the RAN node 212 may fulfill various logical functions of the RAN 210, including but not limited to functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.
[0036] According to some embodiments, UE 201 and UE 202 may be configured to communicate with each other or with either RAN node 211 or RAN node 212 over a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication techniques, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication techniques (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiments is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.
[0037] In some embodiments, a downlink resource grid can be used for downlink transmissions from either RAN node 211 or RAN node 212 to UE 201 or UE 202, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink per time slot. This type of time-frequency plane representation is common in OFDM systems and makes radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes multiple resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a collection of resource elements; in the frequency domain, this can represent the minimum amount of resources that can currently be allocated. Such resource blocks are used to transmit several different physical downlink channels.
[0038] The physical downlink shared channel (PDSCH) can carry user data and higher-layer signaling to UE 201 and UE 202. The physical downlink control channel (PDCCH) can carry information about, among other things, the transport format and resource allocation associated with the PDSCH channel. It can also inform UE 201 and UE 202 of the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information associated with the uplink shared channel. Typically, downlink scheduling (allocation of control and shared channel resource blocks to UE 102 within a cell) can be performed at either RAN node 211 or RAN node 212 based on channel quality information fed back from either UE 201 or UE 202. Downlink resource allocation information can be sent on the PDCCH for (e.g., allocated to) each of UE 201 and UE 202.
[0039] PDCCH can use control channel elements (CCE) to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruples, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to four sets of nine physical resource elements, called resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the downlink control information (DCI) and the channel conditions, one or more CCEs can be used to transmit the PDCCH. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8).
[0040] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. EPDCCH may be transmitted using one or more enhanced control channel elements (ECCEs). Similar to the above, each ECCE may correspond to nine sets of four physical resource elements, referred to as enhanced resource element groups (EREGs). In some cases, ECCEs may have other numbers of EREGs.
[0041] RAN 210 is shown as being communicatively coupled to a core network (CN) 220 via an S1 interface 213. In various embodiments, CN 220 may be an evolved packet core (EPC) network, a next generation packet core (NPC) network, or some other type of CN. In this embodiment, S1 interface 213 is divided into two parts: an S1-U interface 214, which carries traffic data between RAN nodes 211 and 212 and a serving gateway (S-GW) 222; and an S1-Mobility Management Entity (MME) interface 215, which is a signaling interface between RAN nodes 211 and 212 and MME 221.
[0042] In this embodiment, CN 220 includes MME 221, S-GW 222, Packet Data Network (PDN) Gateway (P-GW) 223, and Home Subscriber Server (HSS) 224. MME 221 may be similar in function to the control plane of a conventional Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME 221 may manage mobility aspects of access, such as gateway selection and tracking area list management. HSS 224 may include a database for network users, which includes subscription-related information used to support network entities in handling communication sessions. Depending on the number of mobile subscribers, equipment capacity, network organization, etc., CN 220 may include one or more HSSs 224. For example, HSS 224 may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.
[0043] The S-GW 222 may terminate the S1 interface 213 towards the RAN 210 and route data packets between the RAN 210 and the CN 220. Additionally, the S-GW 222 may be a local mobility anchor for inter-RAN node handovers and may also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and enforcement of certain policies.
[0044] The P-GW 223 may terminate the SGi interface toward the PDN. The P-GW 223 may route data packets between the EPC network 223 and an external network, such as a network including an application server 230 (alternatively referred to as an application function (AF)), via an Internet Protocol (IP) interface 225. Generally, the application server 230 may be an element that provides applications that use IP bearer resources with the core network (e.g., UMTS packet service (PS) domain, LTE PS data service, etc.). In this embodiment, the P-GW 223 is shown as being communicatively coupled to the application server 230 via an IP communication interface 225. The application server 230 may also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UE 201 and the UE 202 via the CN 220.
[0045] The P-GW 223 may also be a node for policy enforcement and charging data collection. The Policy and Charging Enforcement Function (PCRF) 226 is the policy and charging control element of the CN 220. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local traffic breakout, there may be two PCRFs associated with the UE's IP-CAN session: a Home PCRF (H-PCRF) in the HPLMN and a Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). The PCRF 226 may be communicatively coupled to the application server 230 via the P-GW 223. The application server 230 may signal the PCRF 226 to indicate a new service flow and select appropriate quality of service (QoS) and charging parameters. PCRF 226 may configure the rule to a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate Traffic Flow Template (TFT) and QoS Class Identifier (QCI), which initiates the QoS and charging specified by application server 230 .
[0046] Figure 3Example components of a device 300 according to some embodiments are shown. In some embodiments, the device 300 may include application circuitry 302, baseband circuitry 304, radio frequency (RF) circuitry 306, front-end module (FEM) circuitry 308, one or more antennas 310, and power management circuitry (PMC) 312 (coupled together at least as shown). The components of the illustrated device 300 may be included in a UE or a RAN node. In some embodiments, the device 300 may include fewer elements (e.g., a RAN node may not utilize application circuitry 302 but instead include a processor / controller to process IP data received from an EPC). In some embodiments, the device 300 may include additional elements such as, for example, memory / storage, a display, a camera, sensors, or input / output (I / O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., the circuitry may be included separately in more than one device for a cloud-RAN (C-RAN) implementation).
[0047] Application circuitry 302 may include one or more application processors. For example, application circuitry 302 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Processors may include any combination of general-purpose processors and specialized processors (e.g., graphics processors, application processors, etc.). These processors may be coupled to or include memory / storage and may be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on device 300. In some embodiments, the processors of application circuitry 302 may process IP data packets received from the EPC.
[0048] The baseband circuitry 304 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 304 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of the RF circuitry 306 and to generate baseband signals for the transmit signal path of the RF circuitry 306. The baseband processing circuitry 304 may interact with the application circuitry 302 to generate and process baseband signals and control the operation of the RF circuitry 306. For example, in some embodiments, the baseband circuitry 304 may include a third-generation (3G) baseband processor 304A, a fourth-generation (4G) baseband processor 304B, a fifth-generation (5G) baseband processor 304C, or one or more other baseband processors 304D of other existing, developing, or future generations (e.g., second-generation (2G), sixth-generation (6G), etc.). The baseband circuitry 304 (e.g., one or more of the baseband processors 304A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 306. In other embodiments, some or all of the functionality of baseband processors 304A-D may be included in modules stored in memory 304G and executed via central processing unit (CPU) 304E. Radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some embodiments, the modulation / demodulation circuitry of baseband circuitry 304 may include fast Fourier transform (FFT), precoding, or constellation mapping / demapping functionality. In some embodiments, the encoding / decoding circuitry of baseband circuitry 304 may include convolution, tail-biting, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functionality. The implementation of the modulation / demodulation and encoder / decoder functionality is not limited to these examples and may include other suitable functionality in other embodiments.
[0049] In some embodiments, the baseband circuitry 304 may include one or more audio digital signal processors (DSPs) 304F. The audio DSPs 304F may include components for compression / decompression and echo cancellation, and in other embodiments may include other suitable processing elements. In some embodiments, the components of the baseband circuitry may be appropriately combined in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the components of the baseband circuitry 304 and the application circuitry 302 may be implemented together, such as on a system on a chip (SOC).
[0050] In some embodiments, baseband circuitry 304 can provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 304 can support communications with an Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other wireless metropolitan area network (WMAN), wireless local area network (WLAN), or wireless personal area network (WPAN). Embodiments in which baseband circuitry 304 is configured to support radio communications using more than one wireless protocol may be referred to as multi-mode baseband circuitry.
[0051] RF circuitry 306 can communicate with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, RF circuitry 306 can include switches, filters, amplifiers, etc. to facilitate communication with the wireless network. RF circuitry 306 can include a receive signal path that can include circuitry for downconverting RF signals received from FEM circuitry 308 and providing baseband signals to baseband circuitry 304. RF circuitry 306 can also include a transmit signal path that can include circuitry for upconverting baseband signals provided by baseband circuitry 304 and providing an RF output signal to FEM circuitry 308 for transmission.
[0052] In some embodiments, the receive signal path of RF circuitry 306 may include mixer circuitry 306a, amplifier circuitry 306b, and filter circuitry 306c. In some embodiments, the transmit signal path of RF circuitry 306 may include filter circuitry 306c and mixer circuitry 306a. RF circuitry 306 may also include synthesizer circuitry 306d for synthesizing frequencies used by mixer circuitry 306a in the receive and transmit signal paths. In some embodiments, mixer circuitry 306a in the receive signal path may be configured to downconvert the RF signal received from FEM circuitry 308 based on the synthesized frequency provided by synthesizer circuitry 306d. Amplifier circuitry 306b may be configured to amplify the downconverted signal, and filter circuitry 306c may be a low-pass filter (LPF) or a band-pass filter (BPF) configured to remove unwanted signals from the downconverted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 304 for further processing. In some embodiments, the output baseband signal can be a zero-frequency baseband signal, although this is not required.In some embodiments, the mixer circuit 306a of the receive signal path can include a passive mixer, although the scope of the embodiments is not limited in this respect.
[0053] In some embodiments, mixer circuit 306a of the transmit signal path can be configured to upconvert an input baseband signal based on a synthesized frequency provided by synthesizer circuit 306d to generate an RF output signal for FEM circuit 308. The baseband signal can be provided by baseband circuit 304 and can be filtered by filter circuit 306c.
[0054] In some embodiments, the mixer circuit 306a of the receive signal path and the mixer circuit 306a of the transmit signal path may include two or more mixers and may be arranged for quadrature down-conversion and up-conversion, respectively. In some embodiments, the mixer circuit 306a of the receive signal path and the mixer circuit 306a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit 306a of the receive signal path and the mixer circuit 306a may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, the mixer circuit 306a of the receive signal path and the mixer circuit 306a of the transmit signal path may be configured for superheterodyne operation.
[0055] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 306 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 304 may include a digital baseband interface to communicate with RF circuitry 306.
[0056] In some dual-mode embodiments, separate radio IC circuits may be provided to process signals for each frequency spectrum, although the scope of the embodiments is not limited in this respect. In some embodiments, synthesizer circuit 306 d may be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, although the scope of the embodiments is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, synthesizer circuit 306 d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.
[0057] Synthesizer circuit 306d may be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer circuit 306a of RF circuit 306. In some embodiments, synthesizer circuit 306d may be a fractional-N / N+1 synthesizer.
[0058] In some embodiments, the frequency input may be provided by a voltage controlled oscillator (VCO), but this is not required. The divider control input may be provided by baseband circuitry 304 or application processor 302 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by application processor 302.
[0059] The synthesizer circuit 306d of the RF circuit 306 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-modulus frequency divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, the DLL may include a cascaded, tunable delay element, a phase detector, a charge pump, and a set of D-type flip-flops. In these embodiments, the delay element may be configured to divide the VCO cycle into Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.
[0060] In some embodiments, the synthesizer circuit 306d can be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and can be used with a quadrature generator and divider circuit to generate multiple signals at the carrier frequency with multiple different phases relative to each other. In some embodiments, the output frequency can be the LO frequency (fLO). In some embodiments, the RF circuit 306 can include an IQ / polarity converter.
[0061] The FEM circuitry 308 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 310, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry 306 for further processing. The FEM circuitry 308 may also include a transmit signal path that may include circuitry configured to amplify transmit signals provided by the RF circuitry 306 for transmission via one or more of the one or more antennas 310. In various embodiments, amplification by either the transmit or receive signal path may be performed only in the RF circuitry 306, only in the FEM 308, or in both the RF circuitry 306 and the FEM 308.
[0062] In some embodiments, the FEM circuitry 308 may include a TX / RX switch to switch between transmit and receive modes of operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include an LNA to amplify a received RF signal and provide the amplified received RF signal as an output (e.g., to the RF circuitry 306). The transmit signal path of the FEM circuitry 308 may include a power amplifier (PA) to amplify an input RF signal (e.g., provided by the RF circuitry 306) and one or more filters to generate an RF signal for subsequent transmission (e.g., via one or more of the one or more antennas 310).
[0063] In some embodiments, PMC 312 can manage the power provided to baseband circuitry 304. Specifically, PMC 312 can control power source selection, voltage scaling, battery charging, or DC-DC conversion. PMC 312 is typically included when device 300 is capable of being powered by a battery, such as when the device is included in a UE. PMC 312 can improve power conversion efficiency while providing the desired implementation size and heat dissipation characteristics.
[0064] Although Figure 3 PMC 312 is shown coupled only to baseband circuitry 304. However, in other embodiments, PMC 312 may additionally or alternatively be coupled to other components (such as, but not limited to, application circuitry 302, RF circuitry 306, or FEM 308) and perform similar power management operations.
[0065] In some embodiments, the PMC 312 can control or otherwise be part of various power saving mechanisms of the device 300. For example, if the device 300 is in the RRC_Connected state, in which the device is still connected to the RAN node as expected to receive traffic soon, then after a period of inactivity, the device can enter a state known as discontinuous reception mode (DRX). During this state, the device 300 can be powered down for short intervals to save power.
[0066] If there is no data traffic activity for an extended period of time, the device 300 may transition to the RRC_Idle state, in which the device is disconnected from the network and does not perform operations such as channel quality feedback, handovers, etc. The device 300 enters a very low power state and performs paging, in which the device periodically wakes up again to listen to the network and then powers down again. The device 300 cannot receive data in this state and must transition back to the RRC_Connected state in order to receive data.
[0067] An additional power saving mode can disable the device from using the network for periods exceeding the paging interval (ranging from a few seconds to several hours). During this period, the device is completely unable to connect to the network and can be completely powered down. Any data sent during this period will incur significant latency, assuming that latency is acceptable.
[0068] The processor of the application circuitry 302 and the processor of the baseband circuitry 304 can be used to execute elements of one or more instances of the protocol stack. For example, the processor of the baseband circuitry 304 can be used, alone or in combination, to perform layer 3, layer 2, or layer 1 functions, while the processor of the application circuitry 304 can utilize data received from these layers (e.g., packet data) and further perform layer 4 functions (e.g., transport communication protocol (TCP) and user datagram protocol (UDP) layers). As mentioned herein, layer 3 may include a radio resource control (RRC) layer, which is described in further detail below. As mentioned herein, layer 2 may include a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, which are described in further detail below. As mentioned herein, layer 1 may include a physical (PHY) layer of the UE / RAN node, which is described in further detail below.
[0069] Figure 4 1 shows an example interface of a baseband circuit according to some embodiments. As discussed above, Figure 3 The baseband circuit 304 may include processors 304A-304E and a memory 304G utilized by the processors. Each of the processors 304A-304E may include a memory interface 404A-404E, respectively, for sending / receiving data to / from the memory 304G.
[0070] The baseband circuit 304 may also include one or more interfaces for communicatively coupling to other circuits / devices, such as a memory interface 412 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 304); an application circuit interface 414 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 304); Figure 3 RF circuit interface 416 (for example, for sending / receiving data to / from the application circuit 302); Figure 3 an interface for sending / receiving data to / from the RF circuit 306); a wireless hardware connection interface 418 (e.g., for sending / receiving data to / from a near field communication (NFC) component, Components (e.g. Low power consumption), components and other communication components to send / receive data); and a power management interface 420 (eg, an interface for sending / receiving power or control signals to / from PMC312).
[0071] The following are exemplary implementations of the subject matter described herein. In Example 1, an apparatus of a user equipment (UE) includes one or more baseband processors and a memory for storing resource configurations, the one or more baseband processors being used to configure a resource set for New Radio (NR) Vehicle-to-Everything (V2X) transmission on a sidelink for communicating with one or more other UEs and allocating resources for transmitting one or more packets from the NR network to the one or more other UEs via the sidelink. In Example 2, the UE selects resources to be configured from a resource pool for NR V2X transmission. In Example 3, the UE selects resources to be autonomously configured from the NR network. In Example 4, when the resource pool for NR V2X transmission is unavailable, the UE selects resources for an exception resource pool. In Example 5, the exception pool is used for handover. In Example 6, the exception pool is used for radio link failure. In Example 7, a first resource pool is used for unicast communication, and a second resource pool is used for broadcast communication. In Example 8, the first resource pool is shared by two or more unicast links. In Example 9, the first resource pool is unique to a specific unicast link. In Example 10, the first congestion control mechanism is used for unicast communications and the second congestion control mechanism is used for broadcast communications.
[0072] In Example 11, one or more machine-readable media have instructions stored thereon that, when executed by a device of a user equipment (UE), result in configuring a resource set for New Radio (NR) Vehicle-to-Everything (V2X) transmissions on a sidelink for communicating with one or more other UEs, and allocating resources for transmitting one or more packets from the NR network to the one or more other UEs via the sidelink. In Example 12, the UE selects resources to be configured from a resource pool for NR V2X transmissions. In Example 13, the UE selects resources to be autonomously configured from the NR network. In Example 14, when the resource pool for NR V2X transmissions is unavailable, the UE selects resources from an exception resource pool. In Example 15, the exception pool is used for handover. In Example 16, the exception pool is used for radio link failure. In Example 17, a first resource pool is used for unicast communication, and a second resource pool is used for broadcast communication. In Example 18, the first resource pool is shared by two or more unicast links. In Example 19, the first resource pool is unique to a specific unicast link. In Example 20, the first congestion control mechanism is used for unicast communications and the second congestion control mechanism is used for broadcast communications.
[0073] While the claimed subject matter has been described with a certain degree of particularity, it will be appreciated that elements of the claimed subject matter may be varied by those skilled in the art without departing from the spirit and / or scope of the claimed subject matter. It is believed that the subject matter relating to resource allocation and configuration for broadcast and unicast operations on the sidelink for New Radio (NR) V2X, and its many attendant utilities, will be understood from the foregoing description, and it will be apparent that various changes may be made in the form, construction, and / or arrangement of components thereof without departing from the scope and / or spirit of the claimed subject matter, or without sacrificing all of its material advantages, the forms described above being merely illustrative embodiments of the components and / or further providing no substantial changes thereto. It is the intention of the claims to encompass and / or include such variations.
Claims
1. A device for a user equipment (UE), comprising: One or more baseband processors, configured to configure a set of resources for New Radio (NR) Vehicle-to-Everything (V2X) transmission on a sidelink for communicating with one or more other UEs and allocating the resources for transmitting one or more packets from the NR network to the one or more other UEs via the sidelink, wherein when a resource pool for NR V2X transmission is unavailable based on a sensing operation performed on the resource pool for NR V2X transmission, the UE selects the resources from an abnormal resource pool, and when the resource pool for NR V2X transmission is available, the UE selects the resources to be configured from the resource pool for NR V2X transmission, wherein the resource pool for NR V2X transmission includes at least a first resource pool and a second resource pool, the first resource pool being used for unicast communication and the second resource pool being used for broadcast communication, wherein at least a first congestion control mechanism and a second congestion control mechanism are used for NR V2X transmission, the first congestion control mechanism being used for unicast communication and the second congestion control mechanism being used for broadcast communication; and A memory is used to store resource configuration. The apparatus according to claim 1 , wherein the abnormal resource pool is used for switching. The apparatus according to claim 1 , wherein the abnormal resource pool is used for radio link failure.
4. A machine-readable medium having instructions stored thereon, wherein when the instructions are executed by a device of a user equipment (UE), the device: configuring a set of resources for New Radio (NR) Vehicle-to-Everything (V2X) transmissions on a sidelink for communicating with one or more other UEs; and allocating the resources for transmitting one or more packets from the NR network to the one or more other UEs via the sidelink, determining whether a resource pool for NR V2X transmission is unavailable based on the sensing operation; and When the resource pool for NR V2X transmission is unavailable, the resources are selected from the abnormal resource pool, and when the resource pool for NR V2X transmission is available, the resources to be configured are selected from the resource pool for NR V2X transmission, wherein the resource pool for NR V2X transmission includes at least a first resource pool and a second resource pool, the first resource pool is used for unicast communication, and the second resource pool is used for broadcast communication, wherein at least a first congestion control mechanism and a second congestion control mechanism are used for NR V2X transmission, the first congestion control mechanism is used for unicast communication, and the second congestion control mechanism is used for broadcast communication. The machine-readable medium of claim 4 , wherein the abnormal resource pool is used for switching.
6. The machine-readable medium of claim 4, wherein the abnormal resource pool is used for radio link failure.