Patent Application
20160295624
This disclosure relates generally to wireless communication systems. More specifically, this disclosure relates to method and apparatus for resource pool designs to support vehicle communications and a discovery protocol.
Traditionally, cellular communication networks have been designed to establish wireless communication links between mobile devices and fixed communication infrastructure components (such as base stations or access points) that serve users in a wide or local geographic range. However, a wireless network can also be implemented to utilize only device-to-device (D2D) communication links without a need for fixed infrastructure components. This type of network is typically referred to as an “ad-hoc” network. A hybrid communication network can support devices that connect both to fixed infrastructure components and to other D2D-enabled devices. While end user devices such as smartphones may be envisioned for D2D communication networks, a vehicular communication network (such as V2X) may be supported by a communication protocol where vehicles exchange control and data information between other vehicles or other infrastructure and end-user devices. Multiple types of communication links may be supported by nodes providing V2X communication in a network, and utilizing the same or different protocols and systems.
This disclosure provides a method and apparatus for resource pool design to support vehicle communications and a discovery protocol.
In one embodiment, a first user equipment (UE) in a wireless vehicular communication network is provided. The first UE comprises a transceiver configured to receive a plurality of messages including control and data messages from at least one second UE using at least one of multiple resource pools. The plurality of messages comprises event-triggered or periodic traffic, and the multiple resource pools comprise at least one of dedicated or shared resource pools. The first UE further comprises at least one processor configured to determine at least one of the multiple resource pools to transmit the plurality of messages to the at least one second UE. Multiple traffic types or priorities are multiplexed in the at least one of the multiple dedicated or shared resource pools. The at least one processor is configured to dynamically adjust resource selection within the multiple resource pools based on a resource selection criteria. The transceiver is configured to directly communicate the plurality of messages to the at least one second UE using the at least one of the multiple resource pools.
In another embodiment, a method of a first user equipment (UE) in a wireless vehicular communication network is provided. The method includes receiving a plurality of messages including control and data messages from at least one second UE using at least one of multiple resource pools. The plurality of messages comprises event-triggered or periodic traffic and the multiple resource pools comprise at least one of dedicated or shared resource pools. The method includes determining at least one of the multiple resource pools to transmit the plurality of messages to the at least one second UE. Multiple traffic types or priorities are multiplexed in the at least one of the multiple resource pools. The method further includes dynamically adjusting resource selection within the multiple resource pools based on a resource selection criteria and directly communicating the plurality of messages to the at least one second UE using the at least one of the multiple resource pools.
Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
Before undertaking the DETAILED DESCRIPTION below, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The term “couple” and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The terms “transmit,” “receive,” and “communicate,” as well as derivatives thereof, encompass both direct and indirect communication. The terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation. The term “or” is inclusive, meaning and/or. The phrase “associated with,” as well as derivatives thereof, means to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term “controller” means any device, system or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and/or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase “at least one of,” when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, “at least one of: A, B, and C” includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.
Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms “application” and “program” refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A “non-transitory” computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.
Definitions for other certain words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many if not most instances, such definitions apply to prior as well as future uses of such defined words and phrases.
For a more complete understanding of this disclosure and its advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
The following documents and standards descriptions are hereby incorporated by reference into the present disclosure as if fully set forth herein: 3GPP TS 36.211 v13.0, “E-UTRA, Physical channels and modulation” (REF 1); 3GPP TS 36.212 v13.0, “E-UTRA, Multiplexing and Channel coding” (REF 2); 3GPP TS 36.213 v13.0, “E-UTRA, Physical Layer Procedures” (REF 3); 3GPP TS 36.872 v12.0.0, “Small cell enhancements for E-UTRA and E-UTRAN—Physical layer aspects” (REF 4); and 3GPP TS 36.133 v11.7.0, “E-UTRA, Requirements for support of radio resource management” (REF 5); 3GPP TS 36.321 v12.4.0, “E-UTRA, Medium Access Control (MAC) protocol specification (REF 6); 3GPP TS36.331 v12.4.0, “E-UTRA, Radio Resource Control (RRC) protocol specification (REF 7); 3GPP TS 23.303, “v13.2.0, “Proximity-based services (ProSe); stage 2 (REF 8); 3GPP TR 22.885 v14.0.0, “Study on LTE support for V2X services (REF 9)”
The descriptions of
As shown in
The BS 102 provides wireless broadband access to the network 130 for a first plurality of UEs within a coverage area 120 of the BS 102. The first plurality of UEs includes a UE 111, which may be located in a small business (SB); a UE 112, which may be located in an enterprise (E); a UE 113, which may be located in a WiFi hotspot (HS); a UE 114, which may be located in a first residence (R); a UE 115, which may be located in a second residence (R); and a UE 116, which may be a mobile device (M), such as a cell phone, a wireless laptop, a wireless PDA, or the like. The BS 103 provides wireless broadband access to the network 130 for a second plurality of UEs within a coverage area 125 of the BS 103. The second plurality of UEs includes the UE 115 and the UE 116. In some embodiments, one or more of the BSs 101-103 may communicate with each other and with the UEs 111-116 using 5G, LTE, LTE-A, WiMAX, WiFi, LTE-U (LAA), device-to device (D2D), vehicle communication (V2X) such as vehicle-to-device (V2D), vehicle-to-infrastructure (V2I), vehicle-to-vehicle (V2V), or other wireless communication techniques. In one embodiment, the BSs 101-103 may be implemented as managing entities that control the UEs 111-116 (such as vehicle terminals).
Depending on the network type, other well-known terms may be used instead of “eNodeB” or “eNB,” such as “base station”, “managing entity”, “managing network entity”, or “access point.” For the sake of convenience, the terms “eNodeB” and “eNB” are used in this patent document to refer to network infrastructure components that provide wireless access to remote terminals. Also, depending on the network type, other well-known terms may be used instead of “user equipment” or “UE,” such as “mobile station,” “subscriber station,” “remote terminal,” “wireless terminal,” “vehicle” or “user device.” For the sake of convenience, the terms “user equipment” and “UE” are used in this patent document to refer to remote wireless equipment that wirelessly accesses an eNB (such as base station), whether the UE is a mobile device (such as a vehicle terminal, a mobile telephone, or smartphone) or is normally considered a stationary device (such as a desktop computer, or vending machine).
Dotted lines show the approximate extents of the coverage areas 120 and 125, which are shown as approximately circular for the purposes of illustration and explanation only. It should be clearly understood that the coverage areas associated with BSs, such as the coverage areas 120 and 125, may have other shapes, including irregular shapes, depending upon the configuration of the BSs and variations in the radio environment associated with natural and man-made obstructions.
As described in more detail below, one or more of the UEs 111-116 (such as vehicle with communication interface) include circuitry, programming, or a combination thereof, for processing of discovery and resource selection scheme for V2X communication network. In certain embodiments, and one or more of the BSs 101-103 (such as managing entity) includes circuitry, programming, or a combination thereof, for receiving an authorization request message from a first user equipment (UE) including a request for authorization to perform a vehicle-to-everything (V2X) communication and generating an authorization confirmation message corresponding to the authorization request message to the first UE. The authorization confirmation includes an authorization for the first UE to perform the V2X communication and at least one of security keys, device identifiers (IDs), or group IDs for the first UE to perform the V2X communication.
As used herein, resource selection is a selection of available resources or resource pool(s) comprising time and frequency resources by a node in a wireless communication system. A resource allocation is a type of resource selection that may be performed by a BS (e.g., one of the BSs 101-103) to a first UE (one of the UEs 111-116) that initiates a V2X communication in a wireless communication network with a second UE. For example, UE may perform a resource selection by selecting a portion of the resources that are allocated from the BS to transmit control and data messages including periodic and/or aperiodic traffic to the second UE in a communication range with the first UE. The resource pools may be selected based on one or more resource selection criteria. As used herein, resource selection criteria are any criteria that may be used by a node in a wireless communication system to perform a resource selection. In one example, a UE may select resource pool(s) to use for a V2X communication with another UE using resource selection criteria. For example, without limitation, the resource selection criteria can include geographical location information of the second UE, a size of resource pool, a vehicular (such as the first and/or second UE) speed, a type of traffic (such as control and data message) including periodic and aperiodic traffic, a transmission type or priority, a device or group ID, etc.
Although
As shown in
The RF transceivers 210a-210n receive, from the antennas 205a-205n, incoming RF signals, such as signals transmitted by UEs in the network 100. In one embodiment, the UEs may be implemented as vehicle terminals in a V2X communication network. The RF transceivers 210a-210n down-convert the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to the RX processing circuitry 220, which generates processed baseband signals by filtering, decoding, and/or digitizing the baseband or IF signals. The RX processing circuitry 220 transmits the processed baseband signals to the controller/processor 225 for further processing.
The TX processing circuitry 215 receives analog or digital data (such as voice data, web data, e-mail, or interactive video game data) from the controller/processor 225. The TX processing circuitry 215 encodes, multiplexes, and/or digitizes the outgoing baseband data to generate processed baseband or IF signals. The RF transceivers 210a-210n receive the outgoing processed baseband or IF signals from the TX processing circuitry 215 and up-converts the baseband or IF signals to RF signals that are transmitted via the antennas 205a-205n. In some embodiment, the RF transceivers 210a-210n are configure to receive an authorization request message from a first user equipment (UE) including a request for authorization to perform a vehicle-to-everything (V2X) communication and transmit an authorization confirmation message corresponding to the authorization request message to the first UE. The authorization confirmation includes an authorization for the first UE to perform the V2X communication and at least one of security keys, device identifiers (IDs), or group IDs for the first UE to perform the V2X communication.
The controller/processor 225 can include one or more processors or other processing devices that control the overall operation of the eNB 102. For example, the controller/processor 225 could control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceivers 210a-210n, the RX processing circuitry 220, and the TX processing circuitry 215 in accordance with well-known principles. The controller/processor 225 could support additional functions as well, such as more advanced wireless communication functions. For instance, the controller/processor 225 could support beam forming or directional routing operations in which outgoing signals from multiple antennas 205a-205n are weighted differently to effectively steer the outgoing signals in a desired direction. Any of a wide variety of other functions could be supported in the BS 102 by the controller/processor 225. In some embodiments, the controller/processor 225 includes at least one microprocessor or microcontroller.
As described in more detail below, the BS 102 includes circuitry, programming, or a combination thereof for discovery and resource allocation scheme for V2X communication network. The BS 102 (such as managing entity) is configured to receive an authorization request message from a first user equipment (UE) including a request for authorization to perform a vehicle-to-everything (V2X) communication and transmit an authorization confirmation message corresponding to the authorization request message to the first UE. The authorization confirmation includes an authorization for the first UE to perform the V2X communication and at least one of security keys, device identifiers (IDs), or group IDs for the first UE to perform the V2X communication.
For example, controller/processor 225 can be configured to execute one or more instructions, stored in memory 230, that are configured to cause the controller/processor to generate discovery and resource allocation signals for V2X communication network
The controller/processor 225 is also capable of executing programs and other processes resident in the memory 230, such as an OS. The controller/processor 225 can move data into or out of the memory 230 as required by an executing process.
The controller/processor 225 is also coupled to the backhaul or network interface 235. The backhaul or network interface 235 allows the BS 102 to communicate with other devices or systems over a backhaul connection or over a network. The interface 235 could support communications over any suitable wired or wireless connection(s). For example, when the BS 102 is implemented as part of a cellular communication system (such as one supporting V2D, V2I, V2V, D2D, 5G, LTE, LTE-A, or LTE-U (LAA))), the interface 235 could allow the BS 102 to communicate with other BSs over a wired or wireless backhaul connection. When the BS 102 is implemented as an access point, the interface 235 could allow the BS 102 to communicate over a wired or wireless local area network or over a wired or wireless connection to a larger network (such as the Internet). The interface 235 includes any suitable structure supporting communications over a wired or wireless connection, such as an Ethernet or RF transceiver.
The memory 230 is coupled to the controller/processor 225. Part of the memory 230 could include a RAM, and another part of the memory 230 could include a flash memory or other ROM.
Although
As shown in
The RF transceiver 310 receives, from the set of antennas 305, an incoming RF signal transmitted by an eNB of the network 100. The RF transceiver 310 down-converts the incoming RF signal to generate an intermediate frequency (IF) or baseband signal. In some embodiment, the RF transceiver 310 receives a transceiver configured to transmit an authorization request message to a managing entity and receive an authorization confirmation message corresponding to the authorization request message from the managing entity. In some embodiments, the RF transceiver 310 receives a plurality of messages including control and data messages from the at least one second UE.
The IF or baseband signal is sent to the RX processing circuitry 325, which generates a processed baseband signal by filtering, decoding, and/or digitizing the baseband or IF signal. The RX processing circuitry 325 transmits the processed baseband signal to the speaker 330 (such as for voice data) or to the processor 340 for further processing (such as for web browsing data).
The TX processing circuitry 315 receives analog or digital voice data from the microphone 320 or other outgoing baseband data (such as web data, e-mail, or interactive video game data) from the processor 340. The TX processing circuitry 315 encodes, multiplexes, and/or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver 310 receives the outgoing processed baseband or IF signal from the TX processing circuitry 315 and up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna 305.
The processor 340 can include one or more processors or other processing devices and execute the OS 361 stored in the memory 360 in order to control the overall operation of the UE 116. For example, the processor 340 could control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver 310, the RX processing circuitry 325, and the TX processing circuitry 315 in accordance with well-known principles. In some embodiments, the processor 340 includes at least one microprocessor or microcontroller.
The processor 340 is also capable of executing other processes and programs resident in the memory 360, such as identifies at least one second UE within a communication range of the first UE to transmit a plurality of messages comprising a control and data messages, based on receipt of the authorization confirmation message, determines at least one of multiple resource pools to transmit the plurality of messages to the at least one second UE, wherein the multiple resource pools include event-triggered traffic pools and periodic traffic pools, and directly communicates the plurality of messages to the at least one second UE using at least one of the multiple resource pools.
In some embodiments, the processor 340 is configured to measure power received from the at least one second UE based on at least one of a power threshold, an average power, or a distribution of the measured power to identify a location of the at least one second UE.
In some embodiments, the processor 340 determines a single resource pool to transmit the plurality of messages to the at least one second UE, wherein the single resource pool is dynamically partitioned into first resource pool region for the control messages and second resource pool region for the data messages in a frequency domain over a subframe and communicates the plurality of message to the at least one second UE, wherein the plurality of messages is transmitted in the dynamically partitioned single resource pool over a sidelink, wherein the sidelink is a direct link between the first UE and the at least one second UE.
In some embodiments, the processor 340 determines a single resource pool to transmit the plurality of messages to the at least one second UE, wherein the single resource pool is semi-statically partitioned into first resource pool region for the control messages and second resource pool region for the data messages in a frequency domain over a subframe, and communicates the plurality of message to the at least one second UE in the semi-statically partitioned single resource pool over a sidelink, wherein the sidelink is a direct link between the first UE and the at least one second UE.
The processor 340 can move data into or out of the memory 360 as required by an executing process. In some embodiments, the processor 340 is configured to execute the applications 362 based on the OS 361 or in response to signals received from BSs or an operator. The processor 340 is also coupled to the I/O interface 345, which provides the UE 116 with the ability to connect to other devices, such as laptop computers and handheld computers. The I/O interface 345 is the communication path between these accessories and the processor 340.
The processor 340 is also coupled to the input device 350 and the display 355. The operator of the UE 116 can use the input device 350 to enter data into the UE 116. The display 355 may be a liquid crystal display, light emitting diode display, or other display capable of rendering text and/or at least limited graphics, such as from web sites.
The memory 360 is coupled to the processor 340. Part of the memory 360 could include a random access memory (RAM), and another part of the memory 360 could include a Flash memory or other read-only memory (ROM).
Although
A communication system includes a downlink (DL) that conveys signals from transmission points such as base stations (BSs) or eNodeBs to user equipments (UEs) and an uplink (UL) that conveys signals from UEs to reception points such as eNodeBs. Additionally a sidelink (SL) may convey signals from UEs to other UEs or other non-infrastructure based nodes. A UE, also commonly referred to as a terminal or a mobile station, may be fixed or mobile and may be a cellular phone, a personal computer device, etc. An eNodeB may also be referred to as an access point or other equivalent terminology.
The vehicular communication, referred to as vehicle-to-everything (V2X), contains vehicle-to-vehicle (V2V) communications, vehicle-to-infrastructure (V2I) communications, and vehicle-to-pedestrian (V2P) communications. The V2X communication can use “co-operative awareness” to provide more intelligent services for end-users. This means that transport entities, such as vehicles, roadside infrastructure, and pedestrians, can collect knowledge of their local environments (such as information received from other vehicles or sensor equipment in proximity) to process and share that knowledge in order to provide more intelligent services, such as cooperative collision warning or autonomous driving.
V2X communication can be used to implement several types of services that are complementary to a primary communication network or to provide new services based on a flexibility of a network topology. V2X can support unicasting, broadcasting, or group/multicasting as potential means for V2V communication where vehicles are able to transmit messages to all in-range V2V-enabled devices or to a subset of devices that are members of a particular group. In such instance, a LTE-D2D protocol or on a specialized LTE-V2V protocol.
V2X can support V2I communication between one or more vehicles and an infrastructure node to provide cellular connectivity as well as specialized services related to control and safety of vehicular traffic. V2P communication can also be supported, for example to provide safety services for pedestrians or traffic management services. V2X multicast communication can be used to provide safety and control messages to large numbers of vehicles in a spectrally efficient manner. The two primary standardized messages for V2V/V2I communication are the periodic beacons called cooperative awareness messages (CAM) and the event-triggered warning messages, called decentralized environment notification messages (DENM). The CAMs are periodically broadcasted beacons used to maintain awareness of the surrounding vehicles. These messages are sent with an adaptive frequency of 1-10 Hz. The CAMs include information such as position, type and direction. The DENMs are event-triggered warning messages which are generated to alert neighboring vehicles about potential hazards.
While vehicle devices can be able to support many different communication protocols and include support of mandatory or optional features, since the traffic types, QoS requirements, and deployment topologies are distinct from other types of communications, the hardware/software on a vehicle for supporting V2X can have a reduced or specialized functionality compared to other devices. For example, protocols related to low-complexity, low-data rate, and/or low-latency for machine-type communications can be supported such as, for example, traffic tracking beacons. Satellite-based communication can also be supported for V2X networks for communication or positioning services.
Direct communication between vehicles in V2V is based on a sidelink (SL) interface. The sidelink is the UE to UE interface for SL communication and SL discovery. The SL corresponds to the PC5 interface (such as described in LTE specification). The SL communication is defined as a functionality enabling proximity services (ProSe) direct communication (such as described in LTE specification) between two or more nearby UEs using E-UTRA technology but not traversing any network node.
E-UTRAN allows such UEs that are in proximity of each other to exchange V2V-related information using E-UTRA(N) when permission, authorization and proximity criteria are fulfilled. The proximity criteria can be configured by the MNO. However, UEs supporting V2V service can exchange such information when served by or not served by E-UTRAN which supports V2X Service. The UE supporting V2V applications transmits application layer information (such as location, dynamics, and attributes as part of the V2V Service). The V2V payload may be flexible in order to accommodate different information contents, and the information can be transmitted periodically according to a configuration provided by the MNO. V2V is predominantly broadcast-based; V2V includes the exchange of V2V-related application information between distinct UEs directly and/or, due to the limited direct communication range of V2V, the exchange of V2V-related application information between distinct UEs via infrastructure supporting V2X service (such as RSU, application server, etc.)
As illustrated in
While vehicle devices may be able to support many different communication protocols, and mandatory and optional features, since the traffic types, QoS requirements, and deployment topologies are distinct from other types of communication, the hardware/software on a vehicle for supporting V2X may have a reduced or specialized functionality compared to other devices. For example protocols related to low-complexity, low-data rate, and/or low-latency, machine-type communication protocols 404 may be supported (such as traffic tracking beacons).
Satellite-based communication 405 may also be supported for V2X networks for communication or positioning services. Additionally networks may require devices to operate in near simultaneous fashion when switching between V2X communications modes. Vehicle-to-vehicle communication 412 may also be supported for V2X networks for communication or positioning services.
V2X requires resource allocation mechanisms since multiple V2X UEs may have a need to utilize the same time/frequency resources as other V2X or cellular or D2D UEs. In addition to resource allocation signaling for the transmitting UEs, in the case of V2X, receiving UEs may also require resource allocation signaling in order to determine which time/frequency resources to monitor to receive the transmissions of one of more V2X UEs. Different resource allocation granularity may need to be supported depending on multiple factors including deployment scenarios (such as in/outside network coverage) and traffic types (such as unicast, groupcast, video, etc.).
Traditionally for centralized resource management, a central controller (such as managing entity) like the eNB collects all the channel state information of every UE in the cell and allocates the available resources to maximize a throughput according to fairness and power constraints. For UEs within network coverage, the eNB may be responsible for allocating resources for a group of UEs. Based on the eNB or autonomous resource selection, the transmitting UEs can provide a scheduling assignment signaling indicating the resources the Rx UEs monitor for reception of the data.
On the other hand, especially considering an out-of-network coverage scenario, UEs can determine their resource allocation in a distributed fashion. Simple random resource selection may be considered as a baseline distributed approach with a low overhead and scalability. One drawback of such an approach is that collisions are possible among broadcasting UEs. Thus an implicit coordination (such as carrier sensing) and/or explicit coordination (such as sensing based on scheduling assignment transmission) would be required to prevent collisions and mitigate interference.
As illustrated in
As illustrated in
Several schemes can be considered for providing the control and data links between vehicles in the different deployment scenarios. In such embodiments, different LTE channels (such as DL, UL, SL, or a vehicle link (VL)) and different LTE protocols including broadcast (such as enhanced multimedia broadcast/multicast service (eMBMS) or mode 1 or mode 2 broadcast communication), unicast, or discovery (such as type 1 or type 2 or V2V discovery (type V)) may be configured. Multiple combinations of communication links and protocols can be envisioned to provide a transfer of different types of control and data transmissions.
In some embodiments, a V2V communications protocol may be based upon a LTE-D2D broadcast/groupcast communications protocol. In such embodiments, a group of V2V enable UEs may communicate a series of control and data messages (such as for safety or multimedia services). For example, a V2V communications protocol may include an authorization, a resource allocation, a V2V association, and a V2V communication.
In some embodiments of authorization, a V2V UE sends an authorization message to a managing entity (such as eNB or V2X server) and potentially receives an authorization confirmation message in return in addition to necessary security keys or unique device identifiers and group identifiers. In one example, an authorization may be performed based on a pre-configuration based upon authentication keys or IDs stored in hardware and/or software. In another example, the V2V authorization may utilize a combination of keys, IDs, and messages based on network-specific parameters (such as PLMN ID, V2V server connection, PCID, broadcast area ID), V2V UE-specific (ID, UE type), and location-specific parameters (such as GNSS-based position estimate).
In some embodiments of resource allocation, a V2V UE determines a set of time/frequency resources for transmitting control and data messages. In one example, if V2V transmissions are based upon an LTE-D2D protocol, resource pools can be defined as periodic sets of time/frequency resources that UEs utilize for a given V2V transmission and receiving V2V UEs can search for potential transmissions, including control and data transmissions as shown in
As illustrated in
In one embodiments, V2V and D2D UEs may monitor both the reserved subset and the general subset for SA transmissions while only V2V UEs may transmit SA over the SA cycle 810 in the reserved portion so that D2D UEs avoid the allocation of V2V UEs in the general data subset and V2V UEs may schedule transmissions in both the dedicated and general SA and data pools.
Multiple resource pools may be configured using independent bitmaps with different support lengths and periodicities for different traffic types (such as V2V/D2D or periodic/event-triggered) and the (re)configuration of the parameters may be performed using the same or different higher-layer control message. One benefit of this overlapping pool configuration is to provide priority for one type of traffic (such as different allocations depending on message size, priority, or periodicity, including periodic message and aperiodic or event driven messages). In addition, the overlapping configuration may be applied to other configurations such as V2V or D2D only or mixed traffic from different groups, or with different traffic types or QoS requirements.
In one example of resource allocation in a reserved or shared pool, a V2V UE that is attempting to transmit a SA and/or related data transmission may first monitor an SA pool and may additionally decode transmissions from other V2V UEs in a range. Based on the detection of SA transmissions in a given set of resources (such as based on energy or RS detection) and/or decoding of the SA message containing a resource allocation for transmissions (such as frequency or time pattern), the V2V UE may determine an appropriate SA (and possibly also data) resource allocation by selecting orthogonal resources or resources with below a configured energy threshold. In addition, resources may be based upon other factors, including a transmission type or priority, a device or group ID, or location information (such as global navigation satellite system (GNSS)-based location).
In one example, a multivariate function may be applied when selecting the SA/data allocation with multiple weighted inputs for different metrics including measurement, traffic type/priority, and location. In such examples, resource grouping based on location may first be applied to the set of available SA/data resources and from that set the V2V UE may select the resource(s) with the lowest energy or energy below a configured threshold, and finally a frequency/time domain resource allocation pattern is selected as a function of the device/group/destination ID.
In some embodiments of V2V association, a V2V UE determines a set of V2V UEs from which to send and receive control and data messages. In one example, if only broadcast communication is utilized the V2V UEs may not need to perform group association or group association is directly mapped to a single broadcast group ID that may be provided in the authorization step or preconfigured step. In another example, an association may be performed based upon a received signal strength threshold with one or more communication channels or signals. In such example, one or more communication channels and signals include primary D2D synchronization signal (PD2DSS), a primary D2D shared channel (PD2DSCH), SA, or sidelink data and RS or new V2V control and data channels. In yet another example, the association may be determined based on device discovery using a physical discovery signal message (such as LTE-D2D discovery, direct short range communication (DSRC), or a new device discovery protocol) or based on a broadcast or exchange of absolute or relative location information (such as GNSS, code division GPS (CDGPS), cm-accurate mobile positioning system (CAMPS) etc.).
In such example, the frequency of (re)association may be preconfigured or configured by the network. Additionally, the time period of association may be a function of vehicle type, location, or trajectory information. For example a group of vehicles associated as a ‘platoon’ that are in close proximity and sharing a similar trajectory may perform association more frequently than a group of stationary or slow-moving vehicles. In yet another example, the association may be between UEs traveling in the same lane or with the same trajectory. However vehicles with an opposite or perpendicular trajectory may be excluded from association or associated with a different set.
In some embodiments of V2V communication, a V2V UEs may transmit and receive control and data transmissions after the authorization, resource allocation, and association. In one example, the transmissions may be based on LTE-D2D broadcast communication. In another example, a modified V2V communications protocol may be utilized. In such examples, while for D2D control (such as SA) and data transmissions utilize different messages and resource pools, some control and data information may be combined to reduce latency and improve a reliability of the transmission and reception.
In some embodiments, a V2V communication control message (V2V-CM), sent in physical sidelink control (PSCCH) for example, may utilize one or more formats depending on whether data is additionally multiplexed along with control information providing time/frequency allocation and other parameters for V2V communications data messages (V2V-DM) which can be transmitted in physical sidelink shared channel (PSSCH), for example. In addition, the contents of the V2V-DM may contain control information for scheduling one or more additional V2V-DM. This can be beneficial to support multiplexing of broadcast, groupcast, and unicast messages in V2V resource pools. The control and data information may be carried in physical layer contents of the V2V-CM or V2V-DM, or may be transported in a higher layer message format. In one example, the first control format may be configured with one set of transmission parameters (such as transmission power, modulation coding scheme (MCS), and number of repetitions), while the second control format may be associated with a second set of transmission parameters.
The indication of the control format may be provided in the downlink resource allocation grant in the case of eNB-scheduled V2V transmissions and may additionally be indicated by a format flag in the V2V control message to allow receiving UEs to differentiate between the control and corresponding data transmission formats.
As illustrated in
In some embodiment, a V2V UE may communicate with other V2V UEs by utilizing higher layer (such as L2, L3, or application layer) messages abstracting the physical layer protocol from the lower layers, and making the V2V protocol transparent to the radio access protocol (such as radio link control (RLC) or transmission control protocol (TCP) and below). This may be beneficial to support over-the-top (OTT) applications that are agnostic to a radio access technology (RAT) utilized to transmit the messages (such as DSRC, 802.11p, D2D, cellular, Wi-Fi Direct, or LTE-V2V) and may switch between or simultaneously use different RATs for one or more traffic flows. Additionally this method may be used to support inter-operator or fully ad-hoc V2V communication and discovery. For example two vehicles may be served by different operators utilizing the same RAT for V2V links (such as LTE-V2V) or may utilize different RATs (such as LTE-V2V and DSRC).
In some embodiments, a V2V packet may be passed directly from radio access layers to an application layer where an application layer header may be added to the V2V packets to indicate the source/destination IDs as well as any lower-layer packet indexing parameters for different V2V flows, while the lower layers process all packets from the application in the same manner (such as using the same source/destination IDs).
In some embodiments, an authorization/control message can be exchanged between V2V UE and a managing entity (e.g. eNB, V2X server) to support V2V communication that can be served over different RATs. In one example, upon initiation of the V2X protocol, a V2V UE may provide a network with a message indicating one or more of an operator ID, a device ID, vehicle type information, supported V2X protocols and frequencies, and a unique ID(s). The network may utilize this information to configure broadcast/groupcast parameters and resource configurations for the V2V UE at lower layers and associate support access technologies with different groups of V2V UEs or other V2X nodes to facilitate inter-RAT links.
In some embodiments, periodic beacons may be transmitted by V2X UEs carrying information about the support for a given application layer V2V/V2X communications protocol. These beacons may provide information as described above and the periodicity may be preconfigured with multiple supported periodicities depending on the priority of the control information or dynamics of the vehicle (such as speed, location, type). In addition, the beacons for supporting the application layer V2V may be transmitted using a single radio access technology or may be transmitted across multiple radio access technologies supported by a V2V UE.
In some embodiments, due to the frequent mobility of V2V UEs, a device discovery may need enhancements based upon the LTE-D2D discovery protocol. In one example, a periodicity of D2D discovery transmissions for V2V UEs may be independently configured from the period configured for D2D UEs. In such example, separate system and control information for resource allocation may be provided. In another example, in addition to providing the D2D ID as part of the discovery message, location, trajectory, group or network ID, security parameters, and/or safety assistance information may be provided as part of the discovery message broadcast. This additional information may be provided on a separate channel or using a new discovery message format. In such embodiments, the V2V discovery information may be provided with the same periodicity and/or different periodicity of the V2V discovery information may be utilized based on a (pre)configuration. In such examples, multiple messages sizes may be supported for V2V discovery messages, where a first message size provides the V2V ID only, while a second V2V message provides the ID, as well as additional location and trajectory information. In yet another example, the security parameters may be configured in such a way that successful authentication/decoding of a V2V discovery message requires combination of one or messages from the same V2V UE, utilizing parameters such as the V2V ID and location information.
As illustrated in
In some embodiments, a UE may utilize one or more measurements of the channel(s) utilized for V2V communication to adapt resource allocation and/or other transmission parameters including transmit power, MCS, and number of transmission repetitions. In one example of V2V measurement, Rx range estimation metric can be computed based on the received power of other V2V discovery, control, and/or data transmissions. The V2V UE can compute the received power of the V2V transmissions and can estimate an effective range for V2V transmissions, including a minimum and maximum value, average value, or distribution (such as histogram or cumulative distribute function (CDF)) of the received power of one or more V2V transmissions. In addition, the period over which the measurement is performed or updated can be configured or may be a function of message type or vehicle location/velocity. In addition, the range of the measurement quantity may also be configured. In such examples, maximum and minimum thresholds may be indicated to the V2V UE and/or may be fixed based on a message type or other characteristics such as the velocity/location of the UE.
In some embodiments of Rx range estimation metric, a V2V UE performing measurements may group measurement values based on a group ID or location provided in the V2V discovery or communication messages. For example, a V2V UE may receive messages from multiple groups and can construct Rx range estimate based on the messages received which correspond to the same group ID. A measurement grouping could be performed on a basis of message type, priority, resource pools, higher layer parameters, or other metrics. In one example, the group ID is carried by a broadcast control message or may be carried by a higher layer message. A set of IDs used for constructing range/received power metrics may be configured by higher layers. In another example, Tx range estimation metric can be computed at a given V2V UE based on feedback on the Rx range estimated by other V2V UEs for the given V2V UE. The exchange of the estimated range may be based on an absolute value, or a relative value to an offset, and may be indicated in a V2V discovery, control, or data message in an L1 or L2 payload, or application layer. In yet another example, range/received power metric(s) may be reported to an eNB (such as managing entity) or UE-type road side unit (RSU) for adapting transmission parameters (such as Tx power, MCS, time/frequency allocation and repetition number) in a V2V radio resource management (RRM) message report.
A message may contain one or more IDs and associated absolute or relative range/received power measurements. The periodicity of these reports may be indicated to the UE (such as a configured timer value) or the UE may autonomously report the metrics based on an event-trigger mechanism (such as a value above a threshold).
In some embodiments, event triggered messages, though infrequently, need to be prioritized to communicate safety information. This embodiment considers multiple techniques to prioritize event triggered messages for V2V communication. V2V communication is expected in scenarios with and without network coverage. Both control and data messages will be sent over the V2V communication physical channels. In one example, resource pools can be defined as periodic sets of time/frequency resources that UEs utilize for a given V2V transmission and receiving V2V UEs can search for potential transmissions, including control and data transmissions.
In some embodiments of event-triggered prioritization, different types of V2V messages can be sent over the V2V physical channels. Resource pool partitioning or configuration of multiple pools can be applied to support multiple priorities for event-triggered and periodic traffic.
As illustrated in
In one example, a typical latency requirement for a V2V messages is 100 ms. In another example, sidelink resource pool configurations can be enhanced by introducing shorter periods for control and data pools than supported for other traffic types (such as D2D). In addition, flexible multiplexing of the resources used for control and data channel transmissions in the same pool can also be considered.
Given the importance of event triggered messages, it may be communicated to a large number of devices as quickly as possible and with high reliability. In one embodiment of event-triggered message prioritization, event triggered messages are always configured to be sent with a (pre)configured set of parameters. In one example, the event triggered messages are always sent with a maximum transmission power and at the lowest MCS to maximize the range and reliability of these messages at the lowest latency. In another example, a traffic type flag (such as one or more bits) may be introduced into the uplink request message in order to indicate to the eNB allocating resources for V2V transmission that a given message is of a given traffic type (such as event or periodic). In yet another example, the corresponding downlink grant for V2V resource allocation may also contain a traffic type flag (such as one or more bits) that is used to configure a specific set of transmission parameters (such as power control, MCS, repetition number), where the multiple sets of parameters are configured by higher layer (such as RRC signaling).
The resource pools operation defined for D2D communication can be used as a baseline for defining the resource allocation mechanisms for V2V. However two of the main requirements, reliability and latency for V2V communication, are increased. In addition, some of transmission parameters that may be used for control and data messages may be modified to support better reliability and more scheduling flexibility. In one example, for D2D communication, a time resource pattern for retransmissions of MAC PDUs is derived from a bitmap mapped to available D2D data subframes within a configured data pool. Since a number of MAC PDU retransmissions is fixed to 4, a subset of all possible pattern configurations is specified to reduce signaling overhead. However, for V2V, different numbers of retransmissions can be configured, signaled, or utilized as a tradeoff between latency/reliability and signaling overhead.
In addition, a length of the bitmap can be variable depending on the size of the resource pool which can also be adapted to scale proportionally with the density of traffic in a given geographical area. However, a minimum length may be utilized, corresponding to a default resource pool configuration to provide a minimum guaranteed capacity and latency for the system. The V2V control message payload may dynamically indicate one or more of the transmission and resource allocation parameters, while other parameters may be semi-statically adapted by higher layer signaling or preconfigured. In one example, the V2V control message payload may indicate the transmit power, MCS, and number of repetitions. In addition, event triggered traffic is sent at maximum power and lowest MCS to provide highest reliability in case of collisions while periodic messages are power controlled depending on distance to the UE type or eNB type RSU. The closer the RSU, the lower is the power used for periodic transmission. The receiver may always monitor the event triggered SA pool to see if there is allocation of an event triggered message. It should be noted that the methods above may be utilized for prioritization of other traffic types than event-triggered messages.
In some embodiments, multiple SA and data transmissions are FDMed in the same subframe using separate resource pools for SA and data for V2V communication using PC5 interface. A separate SA pool is reserved for event triggered messages. In one example, a single SA pool may be configured to be semi-statically (such as by higher layer signaling) or dynamically partitioned between SA resources for supporting multiple traffic types (such as event-triggered and periodic traffic), priorities, or groups (such as vehicular platoons). The frequency location of SA pool for event triggered messages may be kept fixed or can be in one of multiple fixed frequency locations, in case it is repeated for increased reliability with frequency diversity. The bandwidth used by the SA for event triggered traffic can be kept fixed. The data transmission can be kept contiguous to the SA transmissions in frequency to minimize in-band emissions. The data pool can be shared between different traffic types (such as event triggered and periodic traffic) or also semi-statically or dynamically partitioned. The partitioning may be performed by higher layer signaling, or a broadcast channel providing system information.
As illustrated in
As illustrated in
In some embodiments, a UE and/or eNB may utilize geographical information in assisting resource selection for V2V or V2I transmissions. In one example the resource pool may be mapped to one or more geographical information values or range of values. In another example the resource pool may be divided into multiple subsets which are mapped to one or more geographical information values or range of values. The geographical information may be associated with resource allocation parameters such as time/frequency resources for control/data messages, transmit power, number of repetitions, MCS, and periodicity of message transmission.
In such embodiments, the geographical information may include one or more of the following: 1) user location coordinates (x/y/z in absolute reference frame from e.g. GNSS post-processing), 2) user pseudo-range coordinates (Δx/Δy/Δz in relative reference frame e.g. from GNSS pre-processing), 3) relative location coordinates (Δx/Δy/Δz in relative reference frame e.g. other vehicle, eNB, positioning reference station, etc.), 4) vehicle orientation or heading, including absolute direction N/W/S/E etc. or relative direction (e.g. map lookup table, relative to other vehicle, eNB, positioning reference station, etc.), 4) vehicle speed/velocity/dynamics (such as absolute value (km/h) or relative to reference value or other vehicles), 5) vehicle type (such as emergency vehicle, platoon, etc.), and 6) landmark or other external reference (such as lane or road ID).
In one embodiment, the geographical information may be conveyed by one or more physical or higher layer channels/messages. The information, including the examples listed previously may be transmitted as a value (with quantization possibly applied) or as an index to one or more lookup tables. The geographical information tables may be configured by higher layer signaling (such as RRC or system information block (SIB)), may be preconfigured, or provided by an application layer. In one example, the time stamp of when the geographical information was determined may be provided along with the geographical information.
In another embodiment, the geographical information may be conveyed by a PC5-V2V physical control, data, or broadcast channel. In one example, the geographical information may be carried in a field of the broadcast channel or control channel message (such as physical sidelink broadcast channel (PSBCH) or SA). In another alternative the geographical information may be carried in the payload of the data message. In yet another alternative the presence of the geographical information may be indicated by a field in the physical control, data, or broadcast message. In such embodiments, the geographical information may be present in every transmission or may be associated with only a subset of transmissions based on a periodic or aperiodic indication. The period of transmission or update of the geographical information may be fixed, or configurable by higher layers (such as RRC or SIB) and may depend on the vehicle location and/or dynamics (such as velocity, emergency priority etc.). For example, as the vehicle speed is increased, the geographical information is updated more frequently. Similarly, if the vehicle speed decreases, the geographical information can be updated less frequently.
In one example, the geographical information may be transmitted or updated every 1 Hz, while the periodic V2V message is transmitted at 10 Hz. Whether or not the geographical information has been updated relative to a previous transmission may be indicated in a field in the physical control, data, or broadcast message. In yet another example the scrambling code or ID used may implicitly indicate the geographical information (such as vehicles traveling in direction y utilize scrambling ID Y, while vehicles traveling in direction x utilize scrambling ID X). In another example the time/frequency resource assignment used to transmit the physical channel/message containing the geographical information may be used to implicitly indicate geographical information (such as vehicles traveling in direction y utilize time/frequency resource pool subset Y, while vehicles traveling in direction x utilize time/frequency resource pool subset X). In yet another example, the geographical information may be conveyed by a PC5-V2V higher layer message. In such examples, the geographical information may be conveyed by one or more fields in a MAC message format. The geographical information may be present in every higher layer transmission or may be associated with only a subset of transmissions based on a periodic or aperiodic indication.
The period of transmission or update of the geographical information may be fixed, or configurable by higher layers (such as RRC or SIB) and may depend on the vehicle location and/or dynamics (such as velocity, emergency priority etc.). For example, the geographical information may be transmitted or updated every 1 Hz, while the periodic V2V message is transmitted at 10 Hz. Whether or not the geographical information has been updated relative to a previous transmission may be indicated in a field in the MAC header or payload.
In yet another example, the geographical information may be conveyed by an application layer message. In yet another example, the geographical information may be conveyed to the network by a UL or PC5 message. This is beneficial in the case of Mode 1 V2X transmissions where the eNB selects one or more resource subsets based on the UE provided vehicle information. In such examples, the geographical information may be contained in a buffer status report (BSR) or V2V scheduling request message in a physical layer payload or MAC message payload. In yet another example, the geographical information may be provided in a dedicated UL or PC5 control message (such as location-request feedback message). In yet another example, the geographical information may be provided in RRM message as part of one or more measurement or dedicated location feedback report configurations.
The geographical information may be present in every transmission or may be associated with only a subset of transmissions based on a periodic or aperiodic indication. For example a DL or PC5 control message may trigger a geographical information update message to be transmitted by the vehicle to the network or one or more vehicles. The geographical information update may be triggered by a field (such as when set to 1) in the DL or PC5 control message. In one example, Mode 2 resource allocation is based on geographical information. In another example, the mapping/association of the geographical information with one or more resource allocation parameters such as time/frequency resources for control/data messages, transmit power, number of repetitions, MCS, and periodicity of message transmission, may be determined by a higher layer signaling (such as RRC or SIB) or may be preconfigured. The UE may autonomously update the resource allocation parameters at the frequency of the geographical information updates based on the mapping provided by the network.
While UL designates a link from a UE 401 (such as 111-116 as illustrated in
To minimize hardware impact on a UE and especially on a power amplifier of the UE, transmission of V2V links occurs in a UL band in case of FDD. Similar, the PC5 interface uses SFs that are reserved for a UL transmission in TDD. A signal transmission is based on single carrier frequency division multiple access (SC-FDMA) that is also used for the UL transmission. New channels can be largely based on a channel structure applicable for a transmission of the physical UL shared channel (PUSCH).
A SL transmission and reception occurs with resources assigned to a group of devices. A resource pool (RP) is a set of resources assigned for SL operation. The SL operation consists of subframes and resource blocks within the subframe. For an SL communication, two additional physical channels are introduced (such as PSCCH carrying the control information and PSSCH carrying the data).
The resource pool 1500 as illustrated in
All the parameters needed to define a resource pool are broadcasted in a system information block (SIB) by a network. Devices which are not within coverage (and hence cannot acquire the SIB) may use some pre-configured values internally stored. The PSCCH is used by a D2D transmission communicating with a UE to make members of the D2D's group aware of a next data transmission that will occur on the PSSCH. The D2D transmission communicating with the UE sends sidelink control information (SCI) on the PSCCH as shown in Table 1.
Devices interested in receiving D2D services can blindly scan the whole PSCCH pool to search if a SCI format matching the devices' group identifier can be detected. On the transmitting device side, resources to transmit the SCI format information may be selected within the PSCCH pool.
Reception resource pools (Rx RPs) and transmission resource pools (Tx RPs) may be defined as resource pool. Rx RPs and Tx RPs may be either signaled by the NodeB for in-coverage case or a pre-configured value is used for the out-of-coverage case. Within a cell, there may be more Rx RPs than Tx RPs to enable reception from adjacent cells or from out-of-coverage UEs.
Two modes of resource allocation are defined for a SL communication (such as mode 1 and mode 2). The mode 1 is referred as scheduled resource allocation and the mode 2 is referred as UE autonomous resource selection. More specifically, in mode 1, access to the SL resources is driven by an eNodeB. In this instance, a UE needs to be connected to transmit data. In one example, the UE wishing to use direct communication feature sends an indication to the network and a temporary identifier is assigned (such as SL radio network temporary identifier (SL-RNTI)). The SL-RNTI may be used by an eNodeB to schedule the future D2D transmission. In another example, when the UE has some data to transmit in a D2D mode, the UE sends a SL-buffer status report (SL-BSR) to the eNodeB which gives an indication on an amount of data to be transmitted in the D2D mode. In such example, the eNodeB sends to the UE the allocation on both PSCCH and PSSCH for the UE's D2D transmission. The allocation information is sent over the PDCCH by sending a DCI format 5, scrambled by the SL-RNTI. The information contained in the DCI format 5 is detailed in Table 2. A large part of the DCI format 5 information is directly reflected in the content of the SCI format 0. Based on the information received in the DCI format 5, the D2D transmitting devices sends the SCI format 0 over the resources within the PSCCH pool allocated by the eNodeB, followed by the data over the resources allocated by the eNodeB for PSSCH transmission.
In mode 1, there is no pre-allocated or reserved resource for PSSCH. For example, “on-demand” by the NodeB is assigned. In addition, since a NodeB is responsible to give access to the resources within the PSCCH pool, collision on the PSCCH transmission can be avoided. In mode 2, the UE transmitting D2D data does not need to be connected to an eNodeB. For example, the UE selects autonomously and randomly the resources within the PSCCH pool to transmit the SCI Format 0.
In addition to the PSCCH pool, there is also a PSSCH pool which defines reserved resources for PSSCH transmission. It is defined in a similar way as the PSCCH pool (such as PRBStart 1510, PRBend 1515, PRBNum 1505 in the frequency domain and a subframe bitmap in the time domain as illustrated in
As illustrated in
The subframe bitmap illustrated in
To be more precise, the set of all subframes which are allocated for the resource pool is restricted by using a periodic pattern with a periodicity of 8 for FDD, and a shorter one for some TDD configurations. Necessary parameters to determine this bitmap in order to receive the data part are signaled via the PSCCH. For mode 2, this structure is quite similar. The main difference is that start of the data part does not depend on the content of the SubframeBitmapSL, but has a fixed offset from the start of the SC Period. In addition, an algorithm to determine the bitmap pattern is somewhat different and may explicitly exclude some configurations.
Semi-persistent scheduling (SPS) is available for DL/UL communication in LTE, primarily to support voice. Since a PDCCH is limited size (generally, 3 OFDM symbols), there is a limit as to how many DCIs can be carried in a subframe. This can in-turn limits the number of UEs which can receive an allocation for that subframe when using dynamic scheduling (such as 1:1 PDCCH-to-PxSCH scheme). With SPS, the UE is pre-configured by an eNB with an SPS-RNTI (allocation ID) and a periodicity. Once pre-configured, if the UE were to receive an allocation (DL/UL) using the SPS-RNTI (instead of the typical C-RNTI), then this one allocation would repeat according to the pre-configured periodicity. During SPS, certain parameters remain fixed for each allocation, for example, RB assignments, modulation and coding scheme (MCS), etc. If radio link conditions change, a new allocation may be sent (PDCCH).
The SPS can be configured/re-configured by RRC at any time using SPS-Config. The SPS-Config includes a configuration for semiPersistSchedC-RNTI (sps-CRNTI), sps-ConfigDL and sps-ConfigUL. In addition, the SPS can be configured only in the uplink (sps-ConfigUL), or in the downlink (sps-ConfigDL) or in both directions. Configuration of the SPS doesn't mean that the UE can start using SPS grants/assignments. The eNB may explicitly activate the SPS, in order for the UE to use the SPS grants/assignments. Also, to avoid wasting resources when a data transfer is completed, there are several mechanisms for deactivating the SPS (explicit, inactivity timer, etc.). When configuring SPS in any direction either UL or DL, SPS C-RNTI is mandatorily provided by the eNB. Soon after the UE is configured with SPS C-RNTI, the UE is configured by higher layers to decode PDCCH with CRC scrambled by the SPS C-RNTI. A UE shall monitor PDCCH with CRC scrambled by the SPS C-RNTI in every subframe as the eNB can activate/re-activate/release SPS at any time using DCI. The SPS is not supported in a SL communication.
In some embodiments, there is a requirement for V2X communication that for particular usage (such as pre-crash sensing) only, the E-UTRA(N) may be capable of transferring V2X messages between two UEs supporting V2V service with a maximum latency of 20 msec. In D2D communication, a scheduling assignment (SA) sent in PSCCH and data sent in PSSCH are time multiplexed in separate pools. The shortest SC period is 40 msec, which does not meet the requirement for V2V. The SA and associated data transmission may be transmitted in the same subframe for the V2V communication so as to satisfy the latency requirement.
In some embodiments, there is a requirement for V2X communication that the E-UTRA(N) may be able to support a high density of UEs supporting V2X service. There is also a requirement that the E-UTRA(N) may be capable of transferring periodic broadcast messages between two UEs supporting V2X services with variable message payloads of 50-300 bytes, not including security-related message component. For many V2V data services, the message sizes are small and the inter-arrival time of transmission is constant (such as the CAM messages are periodic with frequency of 1-10 Hz). The control signaling overhead (PSCCH) can be significant in order to support a large number of vehicles. So, it is important to allocate the resources at once and let the vehicle use these resources instead of re-allocating the resources periodically. To support this efficiently, semi-persistent scheduling support is desirable for the V2V communication using SL.
In some embodiments, a resource pool design in D2D communication assumes a half-duplex constraint so that a device can receive the other UE transmissions while the device is transmitting data. This is not necessary to support for V2X for some pools such as emergency communication since a decentralized environmental notification message (DENM) messages are directed towards the receiving devices to act upon the message rather than any action to be taken from the device transmitting the emergency information.
In some embodiments, there is a requirement for V2X communication that the 3GPP system may be able to vary the transmission rate and coverage area based on service conditions (such as UE speed, UE density). There is also a requirement that the 3GPP network may be able to provide means to prioritize transmission of V2X messages according to their type (such as safety vs. non-safety). Hence, there may be a need to define multiple resource pools for V2V based on message types, traffic density, location, direction of traffic, etc. which affect the communication operation of the vehicle and are requirements unique to V2V communication.
In some embodiments, since low latency is a critical feature for V2V communication, the current D2D structure where the PSCCH and PSSCH are scheduled across multiple subframes in separate resource pools and are time-multiplexed cannot meet the requirements for the V2V communication. Therefore, resource pool designs for fast resource allocation may be necessary to support for semi-persistent scheduling for periodic traffic and support for scheduling emergency DENM event-triggered traffic.
The resource pool 1700 as illustrated in
In one example, low values are supported for voice transmission. SA-PRBnums 1720a, 1720b define the frequency range in PRB bandwidth units that is assigned for SA (PSCCH) transmission and reception. The SA-PRBnums 1720a, 1720b are less than or equal to the PRBnum 1705a, 1705b. The frequency bands are defined starting from the PRBstart 1710 or PRBend 1715, depending on which of the two bands are in use in the current slot. A bitmap in a time domain indicates the 1 msec subframes (such as subframe bitmap 1720) used for PSCCH and PSSCH transmissions. The resources pool 1700 is repeated with a period defined by a parameter SC-Period (expressed in subframe duration, i.e. 1 msec). The range of possible values for SC-Period is from 10 msec to 320 msec. In one example, low values are supported for event-triggered transmission of emergency messages.
As illustrated in
As illustrated in
As illustrated in
The SA and data resources overlap in a frequency domain but the SA only occurs in fixed locations within the allocation. This helps the receiver to look for each of the SA in a particular location without having to search through the entire band. The resource used for each of SA transmissions 1930, 1940a, 1940b is fixed in frequency. The resource location for transmission of each UE within the resource pool 1900 is indicated by an eNodeB in a DCI format. The SA transmissions 1930, 1940a, 1940b may be repeated multiple times within the resource pool to provide improved reliability. The repetition information can be implicitly obtained from the location of the first transmission indicated by the eNodeB. The data transmissions 1935a, 1935b, 1945a, 1945b immediately follow the SA transmissions 1930, 1940a, 1940b in the frequency domain (such as the SA 1920a, 1920b and data 1925a, 1925b are contiguous in frequency). Since the message can be of variable size and may use variable modulation and coding rates, which makes the amount of resources used in frequency variable, rate matching is employed to fill in the entire frequency contents of the Sub-PRBNum 1910. The data 1925a, 1925b can be composed of multiple duplicate transport blocks for increased reliability. Thus, PSSCH and PSCCH are transmitted simultaneously within the same subframe and are contiguous in frequency.
As illustrated in
The SA 2020 and data resources 2025a, 2025b, 2025c are time-multiplexed in certain subframes (such as bitmap 2005) but the SA 2020 only occurs in fixed locations within the allocation. This SA 2020 allocation helps a receiver to look for the SA 2020 in a particular location without having to search through the entire band. The resource used for each SA transmission 2020 is fixed in a frequency domain. The resource location for transmission of each UE within the resource pool 2000 is indicated by an eNodeB in a DCI format. The SA transmission 2020 may be repeated multiple times across the subframes bitmap 2005 within the resource pool 2000 to provide improved reliability.
The repetition information can be implicitly obtained from the location of the first transmission indicated by the eNodeB. The location of the data 2025a, 2025b, 2025c in the time and frequency domain is indicated by the SA transmission 2020. The data 2025a, 2025b, 2025c can be composed of multiple duplicate transport blocks for increased reliability. High priority or emergency traffic can be scheduled in the same subframe while regular traffic can be scheduled in future subframes. The SA 2020 may not be carried in every subframe bitmap 2005.
In one embodiment, the entire slot of periodic traffic 2305a of the subframe bitmap 2005 can be used for the SA transmission 2020. As shown in
As illustrated in
The periodic traffic 2105 and the aperiodic traffic 2110, or the mode 1 allocation 2115 and the mode 2 allocation 2120 first select resources according to an ordered list within regions of the resource pool defined for the traffic (such as periodic traffic or aperiodic traffic) or mode allocation and then select resources based on the ordered list from other regions. For example, the periodic traffic 2105 and the aperiodic traffic 2110, or the mode 1 allocation 2115 and the mode 2 allocation 2120 can occur from opposite sides of the resource pool 2100. The available resources (such as 2105a, 2105b, 2111a, 2111b, 2116a, 2116b, 2121a, 2121b) for UEs are defined as a list of time/frequency locations (such as resource list). The resource list is prioritized, for example, the mode 1 allocation 2115 may use the resource #12116a before using the resource #22116b and so on. Similarly, the mode 1 allocation 2115 and the mode 2 allocation 2120 may use the resource #N 2121b before using the resource #N−1 2121a and so on. Therefore, flexibility may be provided in the pool allocation while minimizing pool fragmentation. The eNodeB can configure the UE, during RRC configuration for example, whether resource pools can be shared or kept exclusive. In one embodiment, the mode 1 allocation 2115 and the mode 2 allocation 2120 share the resource pool 2100, the mode 2 allocation 2120 is no longer random. The UE using the mode 2 2120 firstly senses a channel and investigates the resources pool 2100 available for the UE's SA transmission. The UE selects the first available resource in a priority list for the SA transmission. If all resources are used in the mode 2 allocation 2120, the UE does not transmit but waits for the next available opportunity.
As illustrated in
In one example for penalty, in order to use the resources from resource #P+1 2207b to resource #N 2211b, the UE may reduce the UE's transmission power. In such example, a power reduction may be constant for all the resources 2207b, 2211a, 2211b allocated to the aperiodic traffic 2210 or may increase with increased use of resources (such as increased penalty with increased use of resources allocated to aperiodic traffic 2210). Thus, a probability of the periodic traffic transmission (such as 2205) impacting the aperiodic traffic transmission (such as 2210) is reduced. On the other hand, the aperiodic traffic 2210 may use a fixed power (such as maximum power) even if the aperiodic traffic 2210 uses resources allocated for the periodic traffic 2205, for example, the resources #12206a to the resource #P 2207a due to low latency and critical safety requirements.
As illustrated in
As illustrated in
Due to a need to support periodic messages, it can be more efficient for the eNodeB to assign a periodic schedule for a transmission rather than having to send multiple DCI format for each SC period for a mode 1 operation. Thus, a UE can be configured to support SPS or semi-persistent transmissions for both unicast and sidelink transmissions. The SPS-periodicity and SPS-RNTI for an SL can be configured by the eNodeB using RRC signal using SPS-Config. This SPS-Config is enhanced to additionally include a configuration for semiPersistSched-SL-RNTI (sps-SL-RNTI) and sps-ConfigSL. If SL-SPS is enabled, PSCCH can be scrambled with the SPS-SL-RNTI for the SPS. After the UE is configured with the SPS SL-RNTI, the UE is configured by higher layers to decode the PSCCH with CRC scrambled by the SPS-SL-RNTI. A UE may monitor the PSCCH with the CRC scrambled by the SPS-SL-RNTI in every subframe as the eNB can activate/re-activate/release the SPS at any time using the DCI.
Once the SPS is configured and enabled by the eNodeB, the SPS information is transmitted in an SCI format in the PSCCH and the PSCCH is not transmitted during future repetitions until a periodicity of the SPS expired. The receiving UEs use the same configuration as provided in the initial PSCCH for future data receptions. An MCS, data resource size and other parameters are not modified during the repetitions.
As illustrated in
As illustrated in
As illustrated in
In one embodiment, separate pools can be configured for event triggered traffic to minimize interference. The separate pools are configured with a very small amount of resources for SA and data. The commTxPoolExceptional field in SIB 18 can be re-used for DENM messages for V2V. For the DENM messages, there is no need to support a half-duplex constraint. Every subframe can be used for transmitting an emergency message repeatedly and the separate pools are configured with a very small SA period (10 msec) to meet the 20 msec latency requirement. The DENM messages can be transmitted at maximum transmit power and at the lowest coding rate to improve reliability further. If the UE under an emergency status has other resource pools available for transmission which have reduced interference, the UE can send the event-triggered traffic on those pools as well.
As illustrated in
The authorization confirmation message transmitted from the managing entity 2605, at step 2607, may include the authorization for the vehicle terminal_12610 and at least one of security keys, device identifiers (IDs), or group IDs for the vehicle terminal_12610 to perform the V2X communication. In addition, the authorization confirmation message may further include at least one of network-specific information or location-specific information. More specifically, the network-specific information may include at least one of a public land mobile network identifier (ID), a vehicle-to-vehicle server connection ID, a primary cell ID, or a broadcast ID.
When the vehicle terminal_12610 receives, from the managing entity 2605, the authorization confirmation message at step 2607, the vehicle terminal_12610 may perform measurement procedure to identify a location of the vehicle terminal_22615, at step 2611, based on power received from the vehicle terminal_22615.
At step 2612, the vehicle terminal_12610 may identify the vehicle terminal_22615 to establish a V2X communication link (such as sidelink) to transmit a plurality of message comprising control and data messages. At step 2613, the vehicle terminal_12610 may determine, based on receipt of the authorization confirmation message at step 2607, multiple resource pools to transmit the plurality of messages to the vehicle terminal_22615. The multiple resource pools may include event-triggered traffic pools and periodic traffic pools. In some embodiment, the multiple resource pools may be allocated to the control and data messages in accordance with at least one of a time domain or a frequency domain over a subframe. More specifically, the control message may include scheduling information associated with the data message based on a semi-persistent scheduling technique.
In some embodiments, the vehicle terminal_12610 may determine a single resource pool to transmit the plurality of messages to the vehicle terminal_22615. The single resource pool is dynamically partitioned into first resource pools for the control messages and second resource pools for the data messages in a frequency domain over a subframe.
In some embodiments, the vehicle terminal_12610 may determine a single resource pool to transmit the plurality of messages to the vehicle terminal_22615. The single resource pool is semi-statically partitioned into first resource pools for the control messages and second resource pools for the data messages in a frequency domain over a subframe.
At step 2614, the vehicle terminal_12610 may transmit the control and data message to the vehicle terminal_22615 using the multiple resource pools. In some embodiments, the plurality of messages is transmitted in the dynamically partitioned single resource pool over a sidelink that is a direct link between the vehicle terminal_12610 and the vehicle terminal_22615.
In some embodiments, at step 2614, the vehicle terminal_12610 may transmit the plurality of message to the vehicle terminal_22615 in the semi-statically partitioned single resource pool over the sidelink that is a direct link between the vehicle terminal_12610 and the vehicle terminal_22615.
In some embodiments, at step 2614, the vehicle terminal_12610 may perform resource selection to transmit the plurality of messages to the at least one second UE based on periodic or aperiodic traffic. In one example, for the aperiodic traffic, the vehicle terminal_12610 first selects aperiodic resources according to an order list in the at least one of the multiple dedicated or shared resource pools and then selects periodic resources after selecting the aperiodic traffic in the aperiodic resources. In another example, for the periodic traffic, vehicle terminal_12610 first selects periodic resources according to the order list in the at least one of the multiple dedicated or shared resource pools and then select aperiodic resources after selecting the periodic traffic in the periodic resources.
In some embodiments, at step 2614, the vehicle terminal_12610 performs resource pools selection to transmit the plurality of messages to the at least one second UE. In such embodiments, the selected resource pools are semi-statically partitioned for the at least one of the periodic or aperiodic traffic and the aperiodic traffic uses the selected resource pools that is selected for the periodic traffic without penalty if there is no aperiodic traffic resource pool available while the periodic traffic is penalized to use the aperiodic traffic resources.
In some embodiments, at step 2614, the vehicle terminal_12610 performs resource pools selection to transmit the plurality of messages to the at least one second UE based on at least one of a first mode or a second mode operations. In such embodiments, the resource pools for the first mode and the second mode operations are selected from opposite ends of a shared resource pool.
None of the description in this application should be read as implying that any particular element, step, or function is an essential element that must be included in the claim scope. The scope of patented subject matter is defined only by the claims. Moreover, none of the claims is intended to invoke 35 U.S.C. §112(f) unless the exact words “means for” are followed by a participle.
This application claims priority under 35 U.S.C. §119(e) to: U.S. Provisional Patent Application No. 62/142,151 filed on Apr. 2, 2015; U.S. Provisional Patent Application No. 62/236,473 filed on Oct. 2, 2015; U.S. Provisional Patent Application No. 62/251,256 filed on Nov. 5, 2015; U.S. Provisional Patent Application No. 62/256,993 filed on Nov. 18, 2015; U.S. Provisional Patent Application No. 62/291,323 filed on Feb. 4, 2016; U.S. Provisional Patent Application No. 62/291,253 filed on Feb. 4, 2016; U.S. Provisional Patent Application No. 62/300,425 filed on Feb. 26, 2016; and U.S. Provisional Patent Application No. 62/300,465 filed on Feb. 26, 2016. The above-identified provisional patent applications are hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62142151 | Apr 2015 | US | |
| 62236473 | Oct 2015 | US | |
| 62251256 | Nov 2015 | US | |
| 62256993 | Nov 2015 | US | |
| 62291323 | Feb 2016 | US | |
| 62291253 | Feb 2016 | US | |
| 62300425 | Feb 2016 | US | |
| 62300465 | Feb 2016 | US |
