(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)

Transcription

1 (12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) (19) World Intellectual Property Organization International Bureau (10) International Publication Number (43) International Publication Date WO 2017/ Al 02 November 2017 ( ) W!P O PCT (51) International Patent Classification: land, Oregon (US). CAVALCANTI, Dave; POB H04W4/04 ( ) H04W 88/06 ( ) 6525, Beaverton, Oregon (US). ALNASHI, Saif; Scheelevagen 19, Lund (SE). VENKATACHA- (21) International Application Number: LAM, Muthaiah; NW Paddington Dr., Beaverton, PCT/US20 16/ Oregon (US). (22) International Filing Date: (74) Agent: ESCHWEILER, Thomas G.; Eschweiler & A s 29 September 2016 ( ) sociates, LLC, 629 Euclid Avenue, Suite 1000, Cleveland, (25) Filing Language: English Ohio (US). (26) Publication Language: English (81) Designated States (unless otherwise indicated, for every kind of national protection available): AE, AG, AL, AM, (30) Priority Data: AO, AT, AU, AZ, BA, BB, BG, BH, BN, BR, BW, BY, BZ, 62/329, April 2016 ( ) CA, CH, CL, CN, CO, CR, CU, CZ, DE, DJ, DK, DM, DO, 62/334, May 2016 ( ) DZ, EC, EE, EG, ES, FI, GB, GD, GE, GH, GM, GT, HN, (71) Applicant: INTEL IP CORPORATION [US/US]; 2200 HR, HU, ID, IL, IN, IR, IS, JP, KE, KG, KN, KP, KR, KW, Mission College Boulevard, Santa Clara, California KZ, LA, LC, LK, LR, LS, LU, LY, MA, MD, ME, MG, MK, (US). MN, MW, MX, MY, MZ, NA, NG, NI, NO, NZ, OM, PA, PE, PG, PH, PL, PT, QA, RO, RS, RU, RW, SA, SC, SD, (72) Inventors: PINHEIRO, Ana Lucia; NE 25th SE, SG, SK, SL, SM, ST, SV, SY, TH, TJ, TM, TN, TR, TT, Ave., Hillsboro, Oregon (US). KEDALAGUDDE, TZ, UA, UG, US, UZ, VC, VN, ZA, ZM, ZW. Meghashree Dattatri; NW Heathman Ln., Port (54) Title: INTEROPERABILITY BETWEEN V2X (V2V (VEHICLE TO VEHICLE), V2I (VEHICLE TO INFRASTRUCTURE), AND/OR V2P (VEHICLE TO PEDESTRIAN)) RADIO ACCESS TECHNOLOGIES (RATS) o (57) Abstract: Techniques for facilitating V2X (V2V (vehicle to vehicle), V2I (vehicle to infrastructure), and/or V2P (vehicle to pedestrian)) communication between UEs (User Equipments) are discussed. A first set of techniques relate to facilitate selection of a V2X RAT (radio access technology) for a UE in a cell. A second set of techniques relate to facilitating V2X communication between UEs that do not employ a common V2X RAT for direct communication of safety messages. [Continued on nextpage]

2 WO 2017/ Al Illlll II i ll lllll i ll llll II III ill lllll lllll Hill lllll llll llll llll llll (84) Designated States (unless otherwise indicated, for every kind of regional protection available): ARIPO (BW, GH, GM, KE, LR, LS, MW, MZ, NA, RW, SD, SL, ST, SZ, TZ, UG, ZM, ZW), Eurasian (AM, AZ, BY, KG, KZ, RU, TJ, TM), European (AL, AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HR, HU, IE, IS, IT, LT, LU, LV, MC, MK, MT, NL, NO, PL, PT, RO, RS, SE, SI, SK, SM, TR), OAPI (BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, KM, ML, MR, NE, SN, TD, TG). Declarations under Rule 4.17: of inventorship (Rule 4.17(iv)) Published:

3 INTEROPERABILITY BETWEEN V2X (V2V (VEHICLE TO VEHICLE), V2I (VEHICLE TO INFRASTRUCTURE), AND/OR V2P (VEHICLE TO PEDESTRIAN)) RADIO ACCESS TECHNOLOGIES (RATS) REFERENCE TO RELATED APPLICATIONS [0001] This application claims the benefit of U.S. Provisional Applications No. 62/334,31 0 filed May 10, 201 6, entitled "INTEROPERABILITY BETWEEN DSRC AND 3GPP V2X TECHNOLOGIES" and No. 62/329,416 filed April 29, 201 6, entitled "INTEROPERABILITY BETWEEN DSRC AND 3GPP V2X TECHNOLOGIES", the contents of which are herein incorporated by reference in their entirety. FIELD [0002] The present disclosure relates to wireless technology, and more specifically to facilitating interoperability between distinct V2X (V2V (vehicle to vehicle), V2I (vehicle to infrastructure), and/or V2P (vehicle to pedestrian)) radio access technologies (RATs). BACKGROUND [0003] Intelligent Transportation Systems (ITS) enabled by connected vehicles can improve safety and efficiency in roadways. The DSRC (Dedicated Short Range Communication) suite of protocols has been developed based on standards, adding modifications to the exchange of safety messages between vehicles and vehicles and road side units (RSU). Most ITS applications rely on the concept of situation or co-operative awareness, which is based on periodic and event-driven broadcast of basic safety messages (BSM) between vehicles (V2V), vehicles and infrastructure (V2I), vehicles and pedestrians (V2P). These short messages are mostly useful locally to identify situations that require action (e.g. collision warning, emergency stop, pre-crash warning, etc.) within very short intervals (e.g. 20 to 100 msec). As such, minimizing the overhead involved in enabling scalable transmission and reception of BSMs is one of the challenges to support V2X (V2V, V2I and V2P) over cellular systems. [0004] Lately the cellular protocols defined in 3GPP (Third Generation Partnership Project) are being enhanced to support V2X communications and their KPIs (key performance indicators). V2X communications are part of work items in 3GPP SA (Service and Systems Aspects) and RAN (Radio Access Network), and an initial release in June is currently planned, proposing enhancements for D2D (Device-to-Device)

4 communication interface in order to support the service requirements associated with V2V. As part of 5G (Fifth Generation), V2X is also considered a major important use case, and it is currently being studied in NGMN (Next Generation Mobile Networks) and 3GPP. BRIEF DESCRIPTION OF THE DRAWINGS [0005] FIG. 1 is a block diagram illustrating an example user equipment (UE) useable in connection with various aspects described herein. [0006] FIG. 2 is an example diagram of a protocol stack of a device assuming a device (UE in vehicle) supporting V2X in DSRC (dedicated short range communication) and 3GPP (Third Generation Partnership Project) 5G (Fifth Generation) RAT (radio access technology) according to various aspects described herein. [0007] FIG. 3 is an example diagram of a network architecture showing V2X configuration of a UE via messaging from a core network according to various aspects described herein. [0008] FIG. 4 is example diagram of a network architecture showing V2X configuration of a UE via messaging from a core network according to various aspects described herein. [0009] FIG. 5 is a flow diagram of an example method that facilitates selection by a UE of a RAT for V2X communication, according to various aspects described herein. [0010] FIG. 6 is a diagram showing channels and frequencies for the DSRC RAT that can be employed in connection with various aspects described herein. [001 1] FIG. 7 is a diagram showing an example scenario involving multiple UEs employing different RATs or combinations of RATs in multiple coverage areas, according to various aspects described herein. [0012] FIG. 8 is a diagram of an example of a gateway protocol deployed above the WSMP (wave short message protocol) and 5G V2X layer for protocol conversion according to various aspects described herein. [0013] FIG. 9 is a diagram showing an example of a UE registering with an enb (Evolved Node B) as a multi-protocol stack device and converting safety messages between V2X RATs, according to various aspects described herein. [0014] FIG. 10 is a diagram of an example situation involving a gateway protocol converter that converts between two or more RATs for V2X communication according to various aspects described herein.

5 [0015] FIG. 1 1 is a diagram showing a message flow of a DSRC V2X message through a DSRC RSU (road side unit) to a LTE RSU and a 5G RSU according to various aspects described herein. [0016] FIG. 12 is a diagram of an example of a gateway protocol converter facilitating protocol conversion between DSRC and 5G RATs according to various aspects described herein. [0017] FIG. 13 is a diagram of a first example situation in which a UE is configured to act as a relay to facilitate interoperability of V2X RATs according to various aspects described herein. [0018] FIG. 14 is a diagram of a second example situation in which a UE is configured to act as a protocol converter to facilitate interoperability of V2X RATs according to various aspects described herein. [0019] FIG. 15 is a diagram of a third example situation in which a UE is configured to act as a relay to facilitate interoperability of V2X RATs according to various aspects described herein. [0020] FIG. 16 is a diagram of a fourth example situation in which a UE is configured to act as a relay to facilitate interoperability of V2X RATs according to various aspects described herein. [0021] FIG. 17 is a block diagram of a system that facilitates V2X communication at a UE, according to various aspects described herein. [0022] FIG. 18 is a block diagram of a system that facilitates V2X communication between UEs by a base station according to various aspects described herein. [0023] FIG. 19 is a flow diagram of a method that facilitates V2X communication and/or protocol conversion by a UE, according to various aspects described herein. [0024] FIG. 20 is a flow diagram of a method that facilitates V2X communication between UEs by a base station, according to various aspects described herein. DETAILED DESCRIPTION [0025] The present disclosure will now be described with reference to the attached drawing figures, wherein like reference numerals are used to refer to like elements throughout, and wherein the illustrated structures and devices are not necessarily drawn to scale. As utilized herein, terms "component," "system," "interface," and the like are intended to refer to a computer-related entity, hardware, software (e.g., in execution), and/or firmware. For example, a component can be a processor (e.g., a microprocessor, a controller, or other processing device), a process running on a processor, a controller,

6 an object, an executable, a program, a storage device, a computer, a tablet PC and/or a user equipment (e.g., mobile phone, etc.) with a processing device. By way of illustration, an application running on a server and the server can also be a component. One or more components can reside within a process, and a component can be localized on one computer and/or distributed between two or more computers. A set of elements or a set of other components can be described herein, in which the term "set" can be interpreted as "one or more." [0026] Further, these components can execute from various computer readable storage media having various data structures stored thereon such as with a module, for example. The components can communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network, such as, the Internet, a local area network, a wide area network, or similar network with other systems via the signal). [0027] As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, in which the electric or electronic circuitry can be operated by a software application or a firmware application executed by one or more processors. The one or more processors can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts; the electronic components can include one or more processors therein to execute software and/or firmware that confer(s), at least in part, the functionality of the electronic components. [0028] Use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X employs A ; X employs B ; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing instances. In addition, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms "including", "includes", "having", "has", "with", or variants thereof are used in either the detailed description and the

7 claims, such terms are intended to be inclusive in a manner similar to the term "comprising." [0029] As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware. [0030] Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. FIG. 1 illustrates, for one embodiment, example components of a User Equipment (UE) device 100. In some embodiments, the UE device 100 may include application circuitry 102, baseband circuitry 104, Radio Frequency (RF) circuitry 106, front-end module (FEM) circuitry 108 and one or more antennas 110, coupled together at least as shown. [0031] The application circuitry 102 may include one or more application processors. For example, the application circuitry 102 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the system. [0032] The baseband circuitry 104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 104 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 106 and to generate baseband signals for a transmit signal path of the RF circuitry 106. Baseband processing circuity 104 may interface with the application circuitry 102 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 106. For example, in some embodiments, the baseband circuitry 104 may include a second generation (2G) baseband processor 104a, third generation (3G) baseband processor 104b, fourth generation (4G) baseband processor 104c, and/or other baseband processor(s) 104d for other existing generations, generations in development

8 or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 104 (e.g., one or more of baseband processors 104a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 106. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 104 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 104 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. [0033] In some embodiments, the baseband circuitry 104 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or radio resource control (RRC) elements. A central processing unit (CPU) 104e of the baseband circuitry 104 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 104f. The audio DSP(s) 104f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 104 and the application circuitry 102 may be implemented together such as, for example, on a system on a chip (SOC). [0034] In some embodiments, the baseband circuitry 104 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 104 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 104 is configured

9 to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry. [0035] RF circuitry 106 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 106 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 106 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 108 and provide baseband signals to the baseband circuitry 104. RF circuitry 106 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 104 and provide RF output signals to the FEM circuitry 108 for transmission. [0036] In some embodiments, the RF circuitry 106 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 106 may include mixer circuitry 106a, amplifier circuitry 106b and filter circuitry 106c. The transmit signal path of the RF circuitry 106 may include filter circuitry 106c and mixer circuitry 106a. RF circuitry 106 may also include synthesizer circuitry 106d for synthesizing a frequency for use by the mixer circuitry 106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 106a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 108 based on the synthesized frequency provided by synthesizer circuitry 106d. The amplifier circuitry 106b may be configured to amplify the down-converted signals and the filter circuitry 106c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 104 for further processing. In some embodiments, the output baseband signals may be zerofrequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 106a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect. [0037] In some embodiments, the mixer circuitry 106a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 106d to generate RF output signals for the FEM circuitry 108. The baseband signals may be provided by the baseband circuitry 104 and may be filtered by filter circuitry 106c. The filter circuitry 106c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

10 [0038] In some embodiments, the mixer circuitry 106a of the receive signal path and the mixer circuitry 106a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively. In some embodiments, the mixer circuitry 106a of the receive signal path and the mixer circuitry 106a 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 circuitry 106a of the receive signal path and the mixer circuitry 106a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 106a of the receive signal path and the mixer circuitry 106a of the transmit signal path may be configured for super-heterodyne operation. [0039] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 104 may include a digital baseband interface to communicate with the RF circuitry 106. [0040] In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect. [0041] In some embodiments, the synthesizer circuitry 106d 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 be suitable. For example, synthesizer circuitry 106d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider. [0042] The synthesizer circuitry 106d may be configured to synthesize an output frequency for use by the mixer circuitry 106a of the RF circuitry 106 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 106d may be a fractional N/N+1 synthesizer. [0043] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 104 or the applications processor 102 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 102.

11 [0044] Synthesizer circuitry 106d of the RF circuitry 106 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus 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 either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flipflop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, 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. [0045] In some embodiments, synthesizer circuitry 106d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (flo). In some embodiments, the RF circuitry 106 may include an IQ/polar converter. [0046] FEM circuitry 108 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 110, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 106 for further processing. FEM circuitry 108 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 106 for transmission by one or more of the one or more antennas 110. [0047] In some embodiments, the FEM circuitry 108 may include a TX/RX switch to switch between transmit mode and receive mode 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 a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 106). The transmit signal path of the FEM circuitry 108 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 106), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the o ne or more antennas 110.

12 [0048] In some embodiments, the UE device 100 may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or input/output (I/O) interface. [0049] Additionally, although the above example discussion of device 100 is in the context of a UE device (e.g., a UE in a vehicle), in various aspects, a similar device can be employed in connection with a base station (BS) such as an Evolved NodeB (enb), road side unit (RSU), etc. In various aspects discussed herein, an RSU can be an enb RSU (an RSU implemented in an enb), a UE RSU (a RSU implemented in a UE), or a non-enb and non-ue RSU (e.g., a dedicated RSU, etc.). [0050] As discussed above, multiple potential technologies can be employed for V2X communication. In the future, V2X communications may be supported by a combination of DSRC and cellular (e.g., LTE (Long Term Evolution) or 5G) systems. V2X devices can be equipped with multiple radios operating in different spectrum bands. Referring to FIG. 2, illustrated is an example diagram of a protocol stack of a device assuming a device (UE in vehicle) supporting V2X in DSRC and 3GPP 5G according to various aspects described herein. [0051] In various embodiments, techniques disclosed herein can be employed to facilitate V2X communications in a variety of scenarios involving multiple potential V2X RATs (e.g., 5G, LTE, DSRC). These scenarios can include V2X RAT selection by a UE in a vehicle, and/or switching between V2X RATs, which can be based on one or more of preferences configured by the network, operator's policies, or coverage. [0052] In various aspects, techniques are discussed herein that can support V2X communication for scenarios where there are multiple technologies available for communication of safety messages in a given area. In various embodiments, one or more of UE configuration, UE provided information, network provided information, and coverage for the UE can be used to choose a V2X RAT for transmission (e.g., DSRC versus LTE versus 5G). [0053] As there are multiple technologies available for V2X communications, some vehicles (via the UE of that vehicle) can be equipped with multiple access technologies for V2X communication, such as DSRC, LTE and 5G. It is widely accepted that 5G will provide much lower latency and support for more use cases and scenarios than DSRC and/or LTE. Thus, in aspects, with 5G availability, the preference can be to use 5G communications for V2X, as opposed to DSRC or LTE. However, as the coverage area for 5G is likely to be limited in early deployments (and may be limited in some areas or otherwise unavailable for other reasons), UEs can be equipped with the capability of

13 switching between technologies (V2X RATs) in a fast manner, with a minimum impact in message transmission and reception reliability. Moreover, the UE can also be prepared to handle the different latencies of the different technologies, because some use cases may not be supported in certain technologies due to the larger latency and/or lower reliability of those technologies. [0054] Referring to FIG. 3, illustrated is an example diagram of a protocol stack for a UE supporting the three air interface technologies discussed herein (DSRC, LTE, and 5G). FIG. 3 omits the IP-related communication and only shows the layers responsible for the transmission of safety messages. [0055] Moreover, if there is no coordination, different vehicles in the same area can be transmitting in different technologies. [0056] In various aspects discussed herein, two distinct scenarios are addressed herein. In a first scenario, for a multi-technology UE (e.g., a UE configured to employ two or more of LTE, 5G, or DSRC for V2X communication, etc.), techniques are discussed herein for how the UE selects which technology to employ at a given time. In a second scenario, where two or more UEs support different technologies (e.g., a first set of UEs only supports technologies not employed by a second set of UEs), techniques are discussed herein for how those two or more UEs can communicate safety messages with each other. SELECTION OF RAT [0057] In the first scenario, related to choice of RAT for V2X communication, the choice of which air interface technology to use can be based on one or more of the following: ( 1) UE configuration by the network; (2) broadcast information; (3) dedicated message(s) from the NW (network) to the UE; (4) NW coverage and/or availability; (5) message(s) from NW server(s) and/or application server(s); or (6) channel quality (e.g., as determined by RSRP (reference signal received power), etc.). [0058] UE configuration : The UE can be configured, via OMA-DM (Open Mobile Alliance - Device Management), with one or more preferred air interface technologies for V2X (e.g., prioritized when there are more than one). This can be done by configuring the information in a Management Object (MO), which can then be used by the UE to choose the radio access technology. [0059] Broadcast information : The network can send V2X configuration in the Broadcast channel telling all UEs within an area to utilize a specific technology for V2X communication. This can be done if the network knows the capabilities of all UEs in the

14 area, thus the UE can notify the network which RAT(s) is/are supported when the UE first enters the cell. [0060] Dedicated message : The network can send a dedicated message to the UE configuring the UE with a specific technology to be used for V2X communication. [0061] Network coverage and RAT (radio access technology) availability : In an example, the UE can, for example, be configured to send all V2X messages using 5G. In addition, the UE can be configured to use LTE if 5G is not available, and can be further to configured to use DSRC if both 5G and LTE are not available. Other radio access technologies (and/or other orderings of priorities for RATs) can be added, without loss of generality. [0062] If the UE is currently in a 5G coverage area, the UE can use 5G technology to send V2X messages. If the UE leaves the 5G coverage area, the UE can check if LTE is available, and if LTE is available and if the UE supports V2X over LTE, the UE can use LTE. If LTE is not available, or if the UE does not support V2X over LTE, then the UE can fall back to DSRC. [0063] Message from network server or application server : In another option, the UE can receive V2X configuration information when the UE is authorized to use V2X services over the 3GPP network. This authorization is done by a V2X function in the core network, and part of the authorization procedure the V2X function can send a list of preferred air interface technologies. Alternatively, V2X configuration can be performed by an application server that is not part of the core network. Referring to FIG. 4, illustrated is an example diagram of a network architecture showing V2X configuration of a UE via messaging from a core network according to various aspects described herein. [0064] Channel gualitv : In aspects, the UE can employ one or more channel quality measurements (e.g., RSRP, etc.) in connection with associated threshold(s) to determine if a preferred RAT should be employed for V2X communication, or if a lower priority RAT should be employed. [0065] In one set of examples illustrating aspects associated with the first scenario, several UEs can be in a given coverage area inside a cell covered by an enb that supports 5G, LTE and DSRC RSU (road side unit) functionality. [0066] The UEs can notify the enb/rsu which V2X communication RAT(s) is/are supported. Based on that information, the network can choose an access technology for the UEs to use.

15 [0067] As a specific example, there can be 20 vehicle UEs in a given area covered by an enb, and a new UE can enters the cell area. The new UE can report its capabilities to the enb. If the existing 20 cars in the area are communicating using a given access technology, for instance, LTE, the network/enb can configure the UE to communicate the currently used communication technology, in this example LTE. [0068] If the UE that just joined (the new UE) does not support the same access technology, the network can send a multicast message to all existing UEs in the area to switch to an access technology supported by the new UE entering the cell, to make sure they can communicate with each other. [0069] Optionally, the network can broadcast in the cell the preferred access technology. When the new UE enters the cell, the new UE can employ the preferred access technology indicated in the broadcast channel if possible. If the new UE does not support that preferred access technology, the new UE can send a message indicating its capabilities to the network. The network can then switch to the supported access technology. [0070] The first scenario applies when there is at least one common access technology supported by all UEs. If that is not the case, communication can be facilitated as described in connection with the second scenario, discussing interoperability of RATs. [0071] As an option, instead of the network/enb indicating the access technology to be used, the new UE can listen to the medium and decide which access technology is currently being used. If the new UE does not find any, then it can send a request to the network for more information. Then network can then provide more information to help, or it can also decide to change the access technology based on the new UE capability (in case the new UE does not support the existing access technology). [0072] Referring to FIG. 5, illustrated is a flow diagram of an example method 500 that facilitates selection by a UE of a RAT for V2X communication, according to various aspects described herein. In some aspects, method 500 can be performed at a UE. In other aspects, a machine readable medium can store instructions associated with method 500 that, when executed, can cause a UE to perform the acts of method 500. [0073] Example method 500 can apply to a new UE entering a cell currently employing a preferred access technology X (e.g., 5G, LTE, DSRC, etc.). [0074] At 5 10, the new UE can send its access technology capabilities to the enb

16 [0075] At 520, the new UE can scan the medium for a maximum period of time (e.g., P ms, where P can be predefined, configured, etc.) to discover the access technology being used (e.g., X). In aspects, P can be set to 0, causing this action to be skipped). [0076] At 530, if the new UE finds the preferred access technology X within P ms, the new UE can employ the preferred RAT. [0077] At 540, if the new UE does not find the preferred access technology within P ms, the new UE can receive configuration from the enb indicating a RAT to employ for V2X communication. Based on the received capabilities, combined with information regarding which access technology is currently being used in the cell, the enb can choose the access technology. For example, if the new UE supports the existing access technology, the enb can configure the new UE to use that technology. As another example, if the new UE does not support the existing access technology but there is a common access technology that all UEs in the cell support, the enb can notify all UEs in the cell to use that common access technology. [0078] However, at 550, if there is no common access technology in the cell, communication can still be facilitated as discussed below in connection with the second scenario. [0079] Triggering a change of RAT after initial selection : Change of RAT can happen in situations in which the network indicates a change (e.g., as discussed in connection with FIG. 5) or when the UE moves out of the coverage area of a given RAT (e.g., UE is using LTE and as the UE moves, LTE coverage is not available. The UE can then either use the LTE solution out of coverage, or choose to change to another RAT, depending on its configuration. [0080] UE moving out of coverage: As an example, a UE vehicle can support a m ulti protocol stack (e.g., 5G, LTE, DSRC). The UE can be currently using a preferred technology for safety message communication, which can be selected as explained above in connection with FIG. 5 or via some other method. [0081] When changing cells, in some aspects the UE can employ method 500 as a new UE in a new cell. In other aspects, the UE can employ the following method. [0082] The enb RSU can send a measurement configuration to the UE including threshold limits associated with one or more RATs (e.g., 5G, LTE, and DSRC). As an example, threshold limits can be configured for the 5G ThresholdiRAT (T RAT), ThresholdSwitch (T Sw itch) and ThresholdLTE (T L TE) - These thresholds can be employed as described below.

17 [0083] Assuming the 5G radio is given a higher priority, the safety messages can be transmitted over the 5G broadcast channel when the UE vehicle is in enb RSU coverage. If the reference signal received power (RSRP) of the enb RSU, measured by the UE, is below T IRAT, the UE vehicle can start to make inter-rat measurements, looking for other technologies for V2X. The IRAT measurements can be configured by the network, along with the threshold values. Thus, in an example, the UE can be in 5G coverage and can start measuring LTE and DSRC, while it continues measuring the 5G cell also. [0084] When the RSRP received from the enb RSU is below T itc Sw (where T itc Sw < T RAT ) and the RSRP measurements from LTE enb (received through inter-rat measurements) is higher than T LTE, then the UE vehicle can switch to LTE and can start safety message communication on the LTE network. [0085] If there is no LTE coverage, for example, the RSRP received from the enb RSU is below Ts W itc h but there is no RSRP measurements in LTE enb (UE is not in LTE coverage area), then the UE vehicle can switch to the DSRC network and continue the safety message communication on the DSRC CCH. DSRC in this example would be the fallback, in case both 5G and LTE are not available. [0086] By changing the values of the threshold and associating different access technologies with different thresholds, the UE can be triggered to check for different access technologies in an event basis manner. [0087] Optionally, the UE can check for different access technologies periodically. When the UE vehicle is broadcasting safety messages on the DSRC channels, it can also periodically scan for 5G RAN or LTE RAN. If the UE vehicle detects 5G or LTE RAN, it can switch to the respective radio channels to continue communicating the safety messages. Referring to FIG. 6, illustrated is a diagram showing channels and frequencies for the DSRC RAT that can be employed in connection with various aspects described herein. As shown in FIG. 6, the DSRC network has one control channel (CCH) and 4 service channels (SCH). The CCH is used only for management messages and safety messages, while the SCH is used for both safety messages and non-safety messages. When a UE vehicle is on a DSRC network, it can periodically scan for 5G or LTE RAN when there is no data to transmit on SCH. [0088] Although specific examples of priorities for RATs and thresholds are discussed above to illustrate aspects disclosed herein, different combination of priorities and/or thresholds can also be used in various embodiments. The priorities assigned to

18 the radio technology for communication on a multi-protocol stack can be configured as explained above. INTEROPERABILITY OF RATS [0089] As discussed above, in various situations, there may be multiple UEs inside a cell using different radio access technologies. Also, based on the fact that DSRC solutions are available today, LTE V2X is starting to be implemented, and 5G is to be available in 2020, in the future there may be vehicles supporting different technologies in a given region. Moreover, some radio access technologies may not be support in certain regions. Referring to FIG. 7, illustrated is a diagram showing an example scenario involving multiple UEs employing different RATs or combinations of RATs in multiple coverage areas, according to various aspects described herein. [0090] In various embodiments of the second scenario, When a UE vehicle supporting 3GPP technology initially connects to the network, that UE can register itself as multi-protocol stack capable UE with the network. Option 1: Transmission over multiple technologies [0091] In a first option, transmission can be performed over multiple technologies. For example, a UE vehicle that supports a multi-protocol stack (5G,LTE, DSRC) can broadcast safety messages on its 5G broadcast channel for V2V, on its LTE sidelink broadcast channel, and on its DSRC control channel (CCH). The UE can also actively listen to messages from other UE vehicles/enb RSU/RSU/OBUs (on board units). This option addresses the case where UE vehicles supporting only 5G or only LTE or only DSRC can exist on the road and still needs to be aware of each other's presence, however it can involve more overhead than other options, as messages are repeated in different technologies. Option 2 : RSU operating as a protocol converter [0092] For example, in some aspects of the second option, a 3GPP RSU (e.g., enb implementing instructions to act as a RSU) can support a DSRC protocol stack in addition to one or more 3GPP technologies. In such aspects, the 3GPP RSU can be capable of assuming the role of a relay/protocol converter. When a UE vehicle supporting 5G technology broadcasts safety messages on the interface towards the RSU, the RSU can listen to the messages and re-broadcast them on other technologies supported on the RSU.

19 [0093] In the same or other aspects of the second option, when a UE vehicle supporting only 5G technology broadcasts safety messages on the 5G D2D channels, the RSU can overhear the messages and re-broadcast them on other technologies supported on the RSU. In connection with these aspects, the UE vehicle signal transmit power should be high enough for the RSU to be able to over-hear the message that needs to be re-broadcast. [0094] Referring to FIG. 8, illustrated is a diagram of an example of a gateway protocol deployed above the WSMP (wave short message protocol) and 5G V2X layer (which could simply be RLC/PDCP or a simplified RLC/PDCP) for protocol conversion according to various aspects described herein. In various aspects, the interface between the RSUs can be standardized or can be proprietary. Additionally, because this communication is time sensitive, selection and/or design of the link can prioritize reliability. [0095] In the same or other aspects of the second option, a single RSU supporting more than one V2X RAT can perform internal protocol conversion, similarly to the flow shown in FIG. 8, but with the DSRC RSU functionality and 5G RSU functionality within a single node. [0096] In some embodiments, this option can be implemented via an enb. Option 3 : UE(s) operating as protocol converter(s) [0097] In a third option, one or more UEs can operate as protocol converters. In this option, a UE vehicle that supports multi-protocol stacks can assume the role of a relay/protocol converter to re-broadcast messages for vehicles that support only a single stack. The UE vehicle can register itself with the enb RSU as a multi-protocol stack capable device with the relay/protocol converter feature supported during the initial registration process. Referring to FIG. 9, illustrated is a diagram showing an example of a UE registering with an enb as a multi-protocol stack device and converting safety messages between V2X RATs, according to various aspects described herein. [0098] For example, in connection with this third option, act 550 of method 500 (implementing RAT interoperability techniques when no common RAT exists in the cell) can include the enb determining which UE(s) in the cell support(s) multiple access technologies to behave as protocol converter(s) and configuring that UE(s) to behave as protocol converter(s).

20 Option 4 : Gateway operating as a protocol converter [0099] In this fourth option, each RSU, for example DSRC RSU or 3GPP RSU (LTE or 5G) is connected to a "gateway protocol converter". The gateway protocol converter can be responsible for receiving the message from any given RSU, deciding whether to convert the message to another technology, and resending converted messages to the respective RSU for processing and retransmission. Referring to FIG. 10, illustrated is a diagram of an example situation involving a gateway protocol converter that converts between two or more RATs for V2X communication according to various aspects described herein. [00100] In an example situation in connection with the fourth option, a DSRC UE vehicle can be broadcasting safety messages to its vicinity where there are other UE vehicles that might only support LTE and/or 5G. To ensure the safety message gets delivered for a given area, the UE can broadcast the message to the DSRC RSU, and the DSRC RSU can receive the vehicle's DSRC message and send the message to the gateway converter. The gateway converter can send it to the 3GPP RSU, which can relay the message to the area of interest. Referring to FIG. 1 1, illustrated is an example diagram showing a message flow of a DSRC V2X message through a DSRC RSU to a LTE RSU and a 5G RSU according to various aspects described herein. Referring to FIG. 12, illustrated is a diagram of an example of a gateway protocol converter facilitating protocol conversion between DSRC and 5G RATs according to various aspects described herein. [00101] One difference between the fourth option and the second option is that there can be a centralized gateway in the fourth option that receives the messages from all RSUs in a given area and decides to forward the message to the RSUs of interest. The RSUs can simply forward the packet, as they are received, to this gateway. The DSRC and/or 3GPP RSUs need not be modified, as they can simply forward the message(s) to a centralized/localized gateway. [00102] In aspects, the gateway can be inside or outside the 3GPP Core. In various embodiments, one of the above options (first through fourth) can be employed in situations where UE vehicles supporting only 5G or only LTE or only DSRC are in a common geographic region with one another, to facilitate awareness of each other's presence and communication of V2X safety messages. [00103] As with option two, discussed above, in some embodiments, this option can be implemented via an enb.

21 [00104] FIGS illustrate diagrams of various example situations that can facilitate interoperability of V2X RATs in connection with the second scenario. [00105] Referring to FIG. 13, illustrated is a diagram of a first example situation in which a UE is configured to act as a relay to facilitate interoperability of V2X RATs according to various aspects described herein. The following actions can be performed in connection with this example situation: ( 1) a multi-mode device can inform the NW (network) of its multi-mode capabilities and current location; (2) the multi-mode device can be elected to be a relay for the RSU/eNB; (3) a V2V message can be sent in a first RAT (e.g., a 3GPP RAT) to all devices; (4) the V2V message can be received in the first RAT by the multi-mode device; (5) the multi-mode device can forward the message to the RSU/eNB and inform the RSU/eNB the message was associated with the first RAT (e.g., the 3GPP RAT); (6) the RSU/eNB (e.g., enb RSU) can find an IP address for a RSU associated with a second RAT (e.g., DSRC) based on a database and can forward the message to the RSU associated with the second RAT; (7) the RSU associated with the second RAT can determine whether to rebroadcast the message; and (8) if the determination is positive, the message can be received by a device capable of communicating via the second RAT but not the first RAT (e.g., a DSRC-only device). [00106] Referring to FIG. 14, illustrated is a diagram of a second example situation in which a UE is configured to act as a protocol converter to facilitate interoperability of V2X RATs according to various aspects described herein. The following actions can be performed in connection with this example situation: ( 1) a multi-mode device can inform the NW (network) of its multi-mode capabilities and current location; (2) the multi-mode device can be elected to be a relay for local vehicles; (3) a V2V message can be sent in a first RAT (e.g., a 3GPP RAT) to all devices; (4) the V2V message can be received in the first RAT by the multi-mode device; (5) the multi-mode device can convert the message to a second RAT (e.g., DSRC) and resend it; and (6) the message can be received by a device capable of communicating via the second RAT but not the first RAT (e.g., a DSRC-only device). [00107] Referring to FIG. 15, illustrated is a diagram of a third example situation in which a UE is configured to act as a relay to facilitate interoperability of V2X RATs according to various aspects described herein. The following actions can be performed in connection with this example situation: ( 1) a multi-mode device can inform the NW (network) of its multi-mode capabilities and current location; (2) the multi-mode device can be elected to be a relay for the RSU/eNB; (3) a V2V message can be sent in a first RAT (e.g., DSRC) to all devices; (4) the V2V message can be received in the first RAT