WO2018031458A1

WO2018031458A1 - Systems, methods, and devices for identifying locations of nearby road side units for vehicle-to-anything communications

Info

Publication number: WO2018031458A1
Application number: PCT/US2017/045713
Authority: WO
Inventors: Ana Lucia A. Pinheiro; Farid Adrangi; Rafael Misoczki; Dave Cavalcanti; Ranganadh Karella; Meghashree Dattatri Kedalagudde
Original assignee: Intel IP Corporation
Priority date: 2016-08-09
Filing date: 2017-08-07
Publication date: 2018-02-15

Abstract

Systems, methods and devices for inter-RAT interoperability of vehicle-to-anything (V2X) messages is described herein. A first radio access technology (RAT) road side unit (RSU) is described. The first RAT RSU includes a memory that stores a database of RSU information for a plurality of RSUs, wherein the plurality of RSUs include a second RAT RSU, the second RAT being different from the first RAT. The first RAT further includes one or more processors to decode a first V2X message from a first RAT device, the first V2X message including a location of the first RAT device, determine an RSU from the plurality of RSUs in the database of RSU information that is close to the location of the first RAT device, where the RSU is the second RAT RSU, and forward the V2X message from the first RAT RSU to the second RAT RSU.

Description

SYSTEMS, METHODS, AND DEVICES FOR IDENTIFYING LOCATIONS OF NEARBY ROAD SIDE UNITS FOR VEHICLE-TO-ANYTHING COMMUNICATIONS

Related Applications

[0001] This application is a non-provisional of U.S. Provisional Patent Application No. 62/372,636, filed August 9, 2016, which is incorporated by reference herein in its entirety.

Technical Field

[0002] The present disclosure relates to supporting vehicle-to-anything (V2X) communications across different radio access technologies (RATs). In particular, the present disclosure relates to identifying locations of nearby road side units (RSUs) for V2X communication.

Background

[0003] Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless mobile device. Wireless communication system standards and protocols can include the 3rd

Generation Partnership Project (3GPP) long term evolution (LTE); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access

(WiMAX); and the IEEE 802.1 1 standard for wireless local area networks (WLAN), which is commonly known to industry groups as Wi-Fi. In 3GPP radio access networks (RANs) in LTE systems, the base station can include a RAN Node such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) and/or Radio Network Controller (RNC) in an E-UTRAN, which communicate with a wireless communication device, known as user equipment (UE). In fifth generation (5G) or new radio (NR) wireless RANs, RAN Nodes can include a 5G Node.

[0004] RANs use a radio access technology (RAT) to communicate between the RAN Node and UE. RANs can include global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and/or E-UTRAN, which provide access to communication services through a core network. Each of the RANs operates according to a specific 3GPP RAT. For example, the GERAN implements GSM and/or EDGE RAT, the UTRAN implements universal mobile telecommunication system (UMTS) RAT or other 3GPP RAT, and the E-UTRAN implements LTE RAT. Examples of RATs include 3GPP LTE RAT, 3GPP 5G NR RAT, dedicated short range communication (DSRC) RAT, and IEEE 802.1 1 RAT, and the like.

[0005] V2X devices may use any of a number of RATs for V2X communication. With this in mind, solutions are needed for enabling V2X communication across different RATs.

Brief Description of the Drawings

[0006] FIG. 1 is a message diagram illustrating an example in which a 3GPP LTE V2X message is forwarded to different technology devices.

[0007] FIG. 2 is a message diagram illustrating an example in which a DSRC V2X message is forwarded to different technology devices.

[0008] FIG. 3 is a message diagram illustrating an example in which a 5G V2X message is forwarded to different technology devices.

[0009] FIG. 4 is a block diagram of an RSU database that an RSU may use to retransmit a V2X message to nearby RSUs for broadcasting the V2X message using other technologies.

[0010] FIG. 5 is an example of a centralized model in which the message is forwarded to the central entity and the central entity forwards the message to the next hop.

[0011] FIG. 6 is an example of a centralized model in which the central entity is queried for the next hop and the RSU forwards the message to the next hop.

[0012] FIG. 7 is a message flow of a security mechanism for protecting communication between RSUs (e.g., the LTE eNB/RSU, the DSRC RSU).

[0013] FIG. 8 is an example of database creation in a de-centralized model. [0014] FIG. 9 is an example of a de-centralized model in which an LTE eNB/RSU receives a V2X message and forwards the message to the DSRC RSU based on the RSU DB.

[0015] FIG. 10 is an example of a de-centralized model in which a multi-mode device acts as a relay for inter-RAT interoperability.

[0016] FIG. 1 1 is a flow diagram of a method for wireless communication.

[0017] FIG. 12 is a flow diagram of a method for wireless communication.

[0018] FIG. 13 is a flow diagram of a method for wireless communication.

[0019] FIG. 14 illustrates an architecture of a system of a network in accordance with some embodiments.

[0020] FIG. 15 illustrates example components of a device in accordance with some embodiments.

[0021] FIG. 16 illustrates example interfaces of baseband circuitry in accordance with some embodiments.

[0022] FIG. 17 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

Detailed Description of Preferred Embodiments

[0023] A detailed description of systems and methods consistent with

embodiments of the present disclosure is provided below. While several

embodiments are described, it should be understood that the disclosure is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed herein, some embodiments can be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the disclosure.

[0024] Techniques, apparatus, and methods for enabling V2X communication across different RATs are disclosed. In particular, techniques, apparatus, and methods for identifying locations of nearby road side units (RSUs) for V2X

communication are disclosed. It is appreciated that the techniques, apparatus, and methods discussed herein can be viewed from both the perspective of the V2X device (e.g., UE, DSRC device, vehicle) and the perspective of the RSU (e.g., eNB RSU, UE RSU, DSRC RSU, 5G RSU, etc.).

[0025] In some embodiments, an apparatus of a multi-mode UE is described. The multi-mode UE includes a memory to store parameters for operating in accordance with a first RAT and stores parameters for operating in accordance with a second RAT that is different from the first RAT and one or more processors. The one or more processors decode a first V2X message, the first V2X message having an internet protocol (IP) address for a first RAT RSU and generate a reporting message for a second RAT RSU, the reporting message including the IP address for the first RAT RSU.

[0026] In some embodiments, an apparatus includes a memory and one or more processors. The memory is to store a database of RSU information for a plurality of RSUs, where the plurality of RSUs include a first technology RSU and a second technology RSU. The one or more processors are to decode a first registration message from the first technology RSU, decode a second registration message from the second technology RSU, the second registration message including a location of the second technology RSU and an IP address of the second technology RSU, generate the database of RSU information based at least in part on the first registration message and the second registration message, and determine a next hop RSU for a V2X message from a first technology device based at least in part on a location of the first technology device and the database of RSU information, where the next hop RSU is the second technology RSU.

[0027] In some embodiments, a first RAT RSU includes a memory and one or more processors. The memory is to store a database of RSU information for a plurality of RSUs, where the plurality of RSUs include a second RAT RSU that is different from the first RAT RSU. The one or more processors are to decode a first V2X message from a first RAT device, the first V2X message including a location of the first RAT device, determine an RSU from the plurality of RSUs in the database of RSU information that is close to the location of the first RAT device, where the RSU is the second RAT RSU, and forward the V2X message from the first RAT RSU to the second RAT RSU.

[0028] As there are multiple technologies available for V2X communications, some vehicles may be equipped with multiple access technologies for V2X

communication, such as DSRC, LTE and 5G, while some vehicles may equipped with only a single access technology. Accordingly, techniques are needed for enabling devices with different access technologies to communicate with each other.

[0029] It is appreciated that different access technologies have different performance characteristics. Therefore different access technologies can enable different use cases. For example, LTE targets the same use cases and key performance indicators (KPIs) as DSRC, while 5G targets even lower latencies and can support even more use cases.

[0030] Also, the deployment of RSUs in DSRC is likely to be restricted to some major intersections only, and many use cases require connectivity with an

application server, which makes 3GPP cellular technologies more suitable overall for V2X. Therefore, some automakers may choose to only support 3GPP technology in the car. That means that not all cars will have DSRC and not all cars will have 3GPP technologies. Moreover, given the relatively long life cycle of vehicles and gradual deployment of new wireless technologies, it is expected that vehicles with

heterogeneous connectivity capabilities will share the same roads. With the absence of a "common denominator" some sort of interoperability will be needed. Therefore, a "middle man" or protocol translator can make these messages available to all cars, regardless of the technology.

[0031] The usage of a protocol converter to convert messages between 3GPP V2X technology and DSRC, and vice versa, is discussed in detail in a separate disclosure. In general, the protocol converter enables an eNB or another entity in the 3GPP network to forward the message to the DSRC RSU, which then resends the message to local devices in its DSRC coverage area.

[0032] FIGs. 1 -3 highlight some exemplary cases of forwarding messages to different technology devices. Each of FIGs. 1 -3 includes a V2X device 102 (e.g., a 3GPP LTE device, a DSRC device, a 5G device, or a multi-mode device), a 3GPP LTE RSU 104, a DSRC RSU 106, and a 5G RSU 108. In FIGs. 1 -3, the

identification and selection of the appropriate RSUs (the RSUs that are located in close proximity to the V2X device, for example) is assumed. The details of these processes are discussed in further detail below.

[0033] FIG. 1 is a message diagram illustrating an example 100 in which a 3GPP LTE V2X message is forwarded to different technology devices. In this example 100, the V2X device 102 sends a V2X message 1 10 (e.g., a 3GPP V2X message) to the 3GPP LTE RSU 104. The V2X message 1 10 includes a location (e.g., coordinates) of the V2X device 102. In response to receiving the V2X message 1 10, the 3GPP LTE RSU 104 processes 1 12 the V2X message 1 10 and determines if the message needs to be transmitted in a different technology. For example, the 3GPP LTE RSU 104 may determine that the V2X message 1 10 is a message that was not communicated in one or more technology domains but should be (needs to be) communicated to other V2X devices in the one or more technology domains (V2X devices using other technologies, for example).

[0034] In some cases, the 3GPP LTE RSU 104 determines which RSUs that the V2X message 1 10 needs to be transmitted to based on the location of the V2X device 102 (using the location information included in the V2X message 1 10, for example), the technology of the V2X message 1 10, a number of RSUs in a certain proximity to the location of the V2X device 102, and the technology of each RSU in the number of RSUs in the proximity to the location of the V2X device 102. Based on this determination the 3GPP LTE RSU 104 may determine that the V2X message 1 10 needs to be transmitted to one or more different technologies (DSRC and 5G, in this case). In some cases, the 3GPP LTE RSU 104 additionally determines if the V2X message 1 10 needs to be broadcast/sent by the 3GPP LTE RSU 104 to nearby V2X devices (e.g., cars) (using the 3GPP LTE technology, for example).

[0035] Upon determining that the V2X message 1 10 needs to be transmitted to a different technology (DSRC and 5G, in this case), the 3GPP LTE RSU 104 forwards a V2X message 1 14/1 16 (e.g., the V2X message 1 10 or some portion of the V2X message 1 10) to the DSRC RSU 106 and to the 5G RSU 108. In response to receiving the forwarded V2X message 1 14, the DSRC RSU 106 sends 1 18 the forwarded V2X message 1 14 (or some portion of the forwarded V2X message 1 14, for example) to nearby V2X devices (e.g., cars) (using the DSRC technology, for example). In response to receiving the forwarded V2X message 1 16, the 5G RSU 108 sends 120 the forwarded V2X message 1 16 (or some portion of the forwarded V2X message 1 16, for example) to nearby V2X devices (e.g., cars) (using the 5G technology, for example).

[0036] FIG. 2 is a message diagram illustrating an example 200 in which a DSRC V2X message is forwarded to different technology devices. In this example 200, the V2X device 102 sends a V2X message 202 (e.g., a DSRC V2X message) to the DSRC RSU 106. The V2X message 202 includes a location (e.g., coordinates) of the V2X device 102. In response to receiving the V2X message 202, the DSRC RSU 106 processes 204 the V2X message 202 and determines if the message needs to be transmitted in a different technology. For example, the DSRC RSU 106 may determine that the V2X message 202 is a message that was not communicated in one or more technology domains but should be (needs to be) communicated to other V2X devices in the one or more technology domains (V2X devices using other technologies, for example).

[0037] In some cases, the DSRC RSU 106 determines which RSUs that the V2X message 202 needs to be transmitted to based on the location of the V2X device 102 (using the location information included in the V2X message 202, for example), the technology of the V2X message 202, a number of RSUs in a certain proximity to the location of the V2X device 102, and the technology of each RSU in the number of RSUs in the proximity to the location of the V2X device 102. Based on this determination the DSRC RSU 106 may determine that the V2X message 202 needs to be transmitted to one or more different technologies (3GPP LTE and 5G, in this case). In some cases, the DSRC RSU 106 additionally determines if the V2X message 202 needs to be broadcast/sent by the DSRC RSU 106 to nearby V2X devices (e.g., cars) (using the DSRC technology, for example).

[0038] Upon determining that the V2X message 202 needs to be transmitted to a different technology (3GPP LTE and 5G, in this case), the DSRC RSU 106 forwards a V2X message 206/208 (e.g., the V2X message 202 or some portion of the V2X message 202) to the 3GPP LTE RSU 104 and to the 5G RSU 108. In response to receiving the forwarded V2X message 206, the 3GPP LTE RSU 104 sends 210 the forwarded V2X message 206 (or some portion of the forwarded V2X message 206, for example) to nearby V2X devices (e.g., cars) (using the 3GPP LTE technology, for example). In response to receiving the forwarded V2X message 208, the 5G RSU 108 sends 120 the forwarded V2X message 208 (or some portion of the forwarded V2X message 208, for example) to nearby V2X devices (e.g., cars) (using the 5G technology, for example).

[0039] FIG. 3 is a message diagram illustrating an example 300 in which a 5G V2X message is forwarded to different technology devices. In this example 300, the V2X device 102 sends a V2X message 302 (e.g., a 5G V2X message) to the 5G RSU 108. The V2X message 302 includes a location (e.g., coordinates) of the V2X device 102. In response to receiving the V2X message 302, the 5G RSU 108 processes 304 the V2X message 302 and determines if the message needs to be transmitted in a different technology. For example, the 5G RSU 108 may determine that the V2X message 302 is a message that was not communicated in one or more technology domains but should be (needs to be) communicated to other V2X devices in the one or more technology domains (V2X devices using other

technologies, for example).

[0040] In some cases, the 5G RSU 108 determines which RSUs that the V2X message 302 needs to be transmitted to based on the location of the V2X device 102 (using the location information included in the V2X message 302, for example), the technology of the V2X message 302, a number of RSUs in a certain proximity to the location of the V2X device 102, and the technology of each RSU in the number of RSUs in the proximity to the location of the V2X device 102. Based on this determination the 5G RSU 108 may determine that the V2X message 302 needs to be transmitted to one or more different technologies (3GPP LTE and DSRC, in this case). In some cases, the 5G RSU 108 additionally determines if the V2X message 302 needs to be broadcast/sent by the 5G RSU 108 to nearby V2X devices (e.g., cars) (using the 5G technology, for example).

[0041] Upon determining that the V2X message 302 needs to be transmitted to a different technology (3GPP LTE and DSRC, in this case), the 5G RSU 108 forwards a V2X message 306/308 (e.g., the V2X message 302 or some portion of the V2X message 302) to the 3GPP LTE RSU 104 and to the DSRC RSU 106. In response to receiving the forwarded V2X message 306, the 3GPP LTE RSU 104 sends 210 the forwarded V2X message 306 (or some portion of the forwarded V2X message 306, for example) to nearby V2X devices (e.g., cars) (using the 3GPP LTE

technology, for example). In response to receiving the forwarded V2X message 308, the DSRC RSU 106 sends 1 18 the forwarded V2X message 308 (or some portion of the forwarded V2X message 308, for example) to nearby V2X devices (e.g., cars) (using the DSRC technology, for example).

[0042] It is appreciated that a protocol converter may be needed to convert messages between 3GPP V2X technology and non-3GPP V2X technologies (e.g. DSRC), and vice versa. Details regarding protocol converters are covered in detail separate disclosures. Although not discussed in detail in this disclosure, it is appreciated that any necessary protocol conversions are carried out between operations so that a message created in a first technology and appropriately be interpreted and understood by devices using a second technology. [0043] In some embodiments, the present description enables a first technology RSU (e.g., eNB RSU or another entity in the 3GPP network) to forward the message to the second technology RSU (e.g., DSRC RSU), which then resends the message to local second technology devices in its second technology coverage area (see FIGs. 1 -3, for example). The question then becomes how the first technology RSU identifies/chooses the second technology RSU for resending the message.

[0044] According to current developments in the RAN study item on V2X, the UE will report its physical location to the eNB when sending a request for resources to transmit a V2X message. This allows the eNB to discover the location of the UE, and when the UE transmits the V2X message the eNB can retransmit the message to nearby DSRC RSU(s) for rebroadcasting in DSRC mode. But the eNB still needs to learn which RSUs are near that sending UE.

[0045] In the present disclosure, a database of nearby RSUs is created and used to identify/choose the RSU(s) that should be resending V2X messages. In some embodiments, a first technology RSU creates a database of nearby RSUs based on location information provided by multi-mode UEs and then use the database information and the location provided by the UE sending the V2X message to discover nearby RSU(s) (e.g., second technology RSU(s)).

[0046] For example, eNB RSUs create a database with local RSUs, their IP address and physical location. A given eNB RSU receives a message from a UE that includes the location of the UE. The eNB RSU looks up the database of local DSRC RSUs and chooses the DSRC RSU that is closest to the UE that sent the message. The eNB RSU sends a message (e.g., a V2X message) to the DSRC RSU (@IP address, for example) based on the database information.

[0047] The present description proposes two models (e.g., centralized model and de-centralized model) for locating nearby RSUs. Both of these models create an RSU database and utilize the RSU database to locate/select/choose nearby RSUs.

[0048] It is noted that while many of the models/approaches/embodiments, etc. are discussed in terms of 3GPP RSUs and UEs and DSRC RSUs and devices, these are exemplary only and the described concepts could equally apply to any first technology (e.g., 3GPP, Wi-Fi, DSRC, etc.) and any second technology (e.g., 3GPP, Wi-Fi, DSRC, etc.). It is appreciated that the described solutions are particularly applicable in the case of an LTE eNB, which typically has a very large coverage area in combination with DSRC RSUs, which typically have a relatively smaller coverage area (in that an LTE coverage area may include multiple DSRC coverage areas within it, for example).

[0049] FIG. 4 is a block diagram of an RSU database 400 that an RSU may use to retransmit a V2X message to nearby RSUs for broadcasting the V2X message using other technologies. For example, each of the above RSUs (e.g., the 3GPP LTE RSU 104, DSRC RSU 106, 5G RSU 108) described above may utilize an RSU database 400 in determining if a V2X message needs to be transmitted in a different technology (e.g., operation 1 12, operation 204, operation 304).

[0050] The RSU database (DB) 400 may include a plurality of fields. In one example, as illustrated, the RSU DB 400 includes a field for an RSU identifier (ID) that identifies an RSU, a field for the technology of the RSU (e.g., RSU technology), and field for the physical location of the RSU. In some embodiments, the ID includes an internet protocol (IP) address, a fully qualified domain name (FQDN), or the like. In some embodiments, the RSU technology includes 3GPP LTE, DSRC, 5G, and/or the like. In some embodiments, the physical location includes geographic

coordinates (e.g., latitude, longitude, and/or elevation), a physical address (e.g., street address), an approximated physical location, a geographical range such as the center of a circle and radius of the circle, a set of location vectors determining the longitude and latitude ranges such as [(lat-x, lat-y), (long-z, long-w)], or the like.

[0051] In one example, the RSU DB 400 includes DB entries for RSUs A-G. For example, RSU A may be identified by IP Address A 402, may be technology limited to DSRC 404, and may have a physical location of physical location A 406.

Similarly, RSU B may be identified by IP Address B 412, may be technology limited to DSRC 414, and may have a physical location of physical location B 416. In one example, RSU C may be identified by FQDN C 422 (instead of an IP address, for example), may be technology limited to DSRC 424, and may have a physical location of physical location C 426.

[0052] RSU D may be identified by IP Address D 432, may be technology limited to LTE 434, and may have a physical location of physical location D 436. RSU E may be identified by IP Address E 442, may be technology limited to 5G 444, and may have a physical location of physical location E 446. Similarly, RSU F may be identified by IP Address F 452, may be technology limited to 5G 454, and may have a physical location of physical location F 456. [0053] In contrast to RSUs A-F which have all been limited to a single technology, RSU G may be identified by IP Address G 462, may not be as technology limited because it supports DSRC, LTE, and 5G 464, and may have a physical location of physical location G 466. Optionally, different IP addresses may be associated with the same RSU based on the technology it is supporting, i.e., RSU G may have 3 separate addresses, one for each technology. Optionally, the technology may be differentiated via a port number. Again, it is appreciated that the RSU DB 400 is exemplary and that in practice an RSU DB would reflect the realities of the RSU present in a particular geographic area. As discussed previously, the physical location field may enable an RSU to select RSUs that are in physical proximity (e.g., within a particular threshold) to the location reported by the V2X device.

[0054] In the centralized model, a centralized entity provides the address and location for each RSU and thus determines where messages should be forwarded to (to which RSUs, for example). In the centralized model, all RSUs (from all technologies, for example) may register with that central entity, with each RSU informing the central entity of its location and its IP address.

[0055] Messages are sent from the UE to the RSU, and the central entity can be responsible for providing information about the next RSU that needs to receive the message, i.e., the "next hop" for the message. The message may be transmitted to the central entity or the central entity may be queried to find out the next hop. In the case the message is transmitted to the central entity, the decision to forward the message is taken at the central entity and it can be based on the type of the message (e.g. PSID that identifies critical message) or destination address

(broadcast vs unicast). In the case the central entity is queried to find out the next hop, the decision to forward the messages is taken at the first RSU and it can be based on the type of the message (e.g. PSID that identifies critical message) or destination address (broadcast vs unicast). Exemplary options are shown in FIGs. 5 and 6 below.

[0056] In some embodiments, the central entity is a server, such as a mobile edge compute server, or a service, such as a service hosted by a mobile edge compute server. In some cases, the central entity may be implemented in a distributed way, where several databases are distributed across the network in order to avoid single location addressing (and related failures) all the queries from the RSUs. [0057] FIG. 5 is an example of a centralized model 500 in which the message is forwarded to a central entity 506 and the central entity 506 forwards the message to the next hop. In this example, the centralized model 500 includes an LTE eNB/RSU 502, a DSRC RSU 504, the central entity 506, a 3GPP-only device 508, and a DSRC-only device 510.

[0058] In the centralized model 500, each of the RSUs (e.g., the LTE eNB/RSU 502, DSRC RSU 504) may register with the central entity 506. At operation 1 a) 512, the LTE eNB/RSU 502 registers its location and IP address with the central entity 506. Similarly, at operation 1 b) 522, the DSRC RSU 504 registers its location and IP address with the central entity 506. Using this information, the central entity 506 may generate/create/update an RSU DB 400. The RSU DB 400 may be an example of the RSU DB discussed in FIG. 4. The central entity 506 may store and may manage the RSU DB 400. With the RSU DB 400 populated, the central entity 506 may use the RSU DB 400 to forward messages to different technology RSUs (the next hop, for example).

[0059] At operation 2) 516, the 3GPP-only device 508 sends a V2X message. It is appreciated that the 3GPP-only device 508 may only send and receive V2X messages using 3GPP technology. So, although the DSRC-only device 510, which may only send and receive V2X messages using DSRC technology, is in close proximity to the 3GPP-only device 508, the DSRC-only device 510 would not receive the V2X message (e.g., operation 2) 516 sent by the 3GPP-only device 510. As discussed above, this lack of communication across technologies is not ideal. But, as described herein, this issue can be ameliorated through the use of the RSU DB 400.

[0060] At operation 3) 518, the LTE eNB/RSU 502 forwards a message (e.g., the V2X message or some portion of the V2X message) to the central entity 506. The central entity 506 may determine that the message is a 3GPP only message and depending on the message type, may need to be communicated to devices using other technologies. The central entity 506 may compare the location of the 3GPP- only device 508 with the location of other technology RSUs in the RSU DB 400 and may determine that the DSRC RSU 504 is in proximity (within a threshold, for example) to the 3GPP-only device 508. The central entity 506 may further determine that since the message was a 3GPP-only message, the message needs to be forwarded to the DSRC RSU 504 for communication to DSRC devices in the area of the 3GPP-only device 508.

[0061] At operation 4) 520, the central entity 506 forwards a message (e.g., the message or some portion of the message) to the "next hop," which in this case is the DSRC RSU 504. At operation 5) 524, the DSRC RSU 504 broadcasts the message using the DSRC technology and the message is received by the DSRC-only device 510. In this way, the DSRC-only device 510 may receive V2X messages that were originally sent by the 3GPP-only device 508.

[0062] FIG. 6 is an example of a centralized model 600 in which a central entity 506 is queried for the next hop and the RSU forwards the message to the next hop. In this example, the centralized model 600 includes the LTE eNB/RSU 502, the DSRC RSU 504, the central entity 506, the 3GPP-only device 508, and the DSRC- only device 510, as discussed with respect to FIG. 5.

[0063] In the centralized model 600, each of the RSUs (e.g., the LTE eNB/RSU 502, DSRC RSU 504) may register with the central entity 506. At operation 1 a) 602, the LTE eNB/RSU 502 registers its location and IP address with the central entity 506. Similarly, at operation 1 b) 604, the DSRC RSU 504 registers its location and IP address with the central entity 506. Using this information, the central entity 506 may generate/create/update an RSU DB 400. The RSU DB 400 may be an example of the RSU DB discussed in FIG. 4. The central entity 506 may store and may manage the RSU DB 400. With the RSU DB 400 populated, the central entity 506 may use the RSU DB 400 to determine "next hops" for forwarding messages to different technology RSUs and may provide any determined "next hops" to the requesting RSU.

[0064] At operation 2) 606, the 3GPP-only device 508 sends a V2X message. It is appreciated that the 3GPP-only device 508 may only send and receive V2X messages using 3GPP technology. So, although the DSRC-only device 510, which may only send and receive V2X messages using DSRC technology, is in close proximity to the 3GPP-only device 508, the DSRC-only device 510 would not receive the V2X message (e.g., operation 2) 606) sent by the 3GPP-only device 508. As discussed above, this lack of communication across technologies is unacceptable. But, as described herein, this issue can be ameliorated through the use of the RSU DB 400. [0065] At operation 3) 608, the LTE eNB/RSU 502 queries the central entity 506 and receives the address (e.g., IP address, FQDN, etc.) of the "next hop." The central entity 506 may determine that the message is a 3GPP-only message and, depending on the message type, may need to be communicated to devices using other technologies. The central entity 506 may compare the location of the 3GPP- only device 508 with the location of other technology RSUs in the RSU DB 400 and may determine that the DSRC RSU 504 is in proximity (within a threshold, for example) to the 3GPP-only device 508. The central entity 506 may further determine that since the message was a 3GPP-only message, the message needs to be forwarded to the DSRC RSU 504 for communication to DSRC devices in the area of the 3GPP-only device 508. Upon determining that the message needs to be forwarded to the DSRC RSU 504, the central entity 506 provides the address of the DSRC RSU 504 (i.e., the "next hop") to the LTE eNB/RSU 502.

[0066] In some embodiments, the LTE eNB/RSU 502 may optionally include the location of the UE when the LTE eNB/RSU 502 sends a query to the central entity 506. In some embodiments, the central entity 506 may provide a geo-casting service, where the next RSU(s) IP address could be mapped to a certain geographic area. For instance, for UEs (3GPP-only devices, for example) located within a certain area, a number of RSUs could be preconfigured to receive the message.

[0067] At operation 4) 610, the LTE eNB/RSU 502 forwards a message (e.g., the V2X message or some portion of the V2X message) to the "next hop," which in this case is the DSRC RSU 504. At operation 5) 612, the DSRC RSU 504 broadcasts the message using the DSRC technology and the message is received by the DSRC-only device 510. In this way, the DSRC-only device 510 may receive V2X messages that were originally sent by the 3GPP-only device 508.

[0068] For the case where the RSU queries the central entity 506 in order to obtain the address of the "next hop" RSU (as in the centralized model 600), a security mechanism may be used to protect the communication between RSUs. This mechanism is based on the security mechanism discussed in the 3GPP TSG SA WG3 Meeting #84 SA3- 160787, which was focused on solving a related problem but for the context of UE instead of RSUs.

[0069] FIG. 7 is a message flow of a security mechanism 700 for protecting communication between RSUs 702, 706 (e.g., the LTE eNB/RSU 502, the DSRC RSU 504). The security mechanism 700 is described as a flow of messages exchanged by the RSUs 702, 706 and the central entity 506. In some embodiments, the central entity 506 can be seen as the composition of two independent entities: a Function Management Entity 720 and a Key Management Entity 724, or in a simplified embodiment both the Function Management Entity 720 and the Key Management Entity 724 roles can be performed by the very same entity.

[0070] It is noted that that the purpose of the security mechanism 700 is to secure the communication between the RSUs 702, 706, while the communication from/to an RSU to/from Function/Key Management Entities 720, 724 is assumed to be secure. In the security mechanism 700, both the RSUs 702, 706 perform authorization and obtain keys from the central entity 506 to use for communication between the RSUs 702, 706. Since the messaging for each of the RSUs 702, 706 is similar, this description begins with the purpose and content of the messages exchanged in the security mechanism 700.

[0071] Configuration (0a 704, 0b 708, 0c 722, and Od 726): encompass any offline initialization process, such as the provisioning of the addresses of

Function/Key Management Entities 720/724 and the provisioning of private keys and certificates that may be required for the secure communication from/to the RSUs 702, 706 to/from the Function/Key Management Entities 720/724.

[0072] Service Authorization (1 a 732 and 1 b 740): the Function Management Entity 720 provides the communication parameters to the RSU 702, 706, which may include a list of services supported by this infrastructure.

[0073] Key Request (2a. i 734 and 2b. i 742): This message includes the Service ID for which the RSU 702, 706 wants to obtain keys and the list of its security capabilities.

[0074] Algorithm Checking (2a. ii 728 and 2b. ii 730): The Key Management Entity 724 checks if at least one of the security methods is supported by the RSU 702, 706.

[0075] Key Response (2a.iii 736 and 2b.iii 744): The Key Management Entity 724 sends to the RSU 702, 706 the Service ID and the supported security method, in case the algorithm checking (2a. ii 728/2b.ii 730) is successful. Otherwise, it sends a message with an indicator about the failure in 2a. ii 728 or 2b. ii 730.

[0076] MIKey Messages (2a.iv 738 and 2b.iv 746): The RSU 702, 706 and the Key Management Entity 724 execute the selected security method to complete security credential/policy provisioning using the Multimedia Internet KEYing (MIKey) key management scheme. [0077] For messages 2a. iv 738 and 2b. iv 746, the MIKey messages can rely on identity-based cryptography or on the usage of certificates. Either one may be used to achieve authentication and encryption features. The main advantage of the identity-based cryptography approach is that the public key of the entities may be obtained from a publicly known string (called its ID). As examples, the ID may be an email address or a domain name.

[0078] As used herein, the ID may be composed by the network address of the UE or the network address of the RSU. In some embodiments, the ID may be the MAC address, the IP address, a combination of both the MAC address and the IP address (such as: MAC address || IP address, where "||" denotes concatenation), and/or the FQDN. The main requirement here is that the ID will be publicly available and static. For example, in one approach, the ID is a MAC address. In another approach, the ID is an IP address. In another approach, the ID is a combination of a MAC address and an IP address (such as: MAC address || IP address). In another approach, the ID is an FQDN.

[0079] Exchange Protected Messages (3a 748 and 3b 750): The RSUs 702, 706 use the provisioned security credential/policy to exchange protected messages with each other.

[0080] In one example, the RSU 1 702 performs the 0a configuration 704, conducts the service authorization 1 a 732 with the Function Management Entity 720, and requests the key 2a. i 734 from the Key Management Entity 724. The Key Management Entity 724 checks the algorithms 2a. ii 728 and provides the key response 2a.iii 736 to the RSU 1 702. The RSU 1 702 and the Key Management Entity 724 exchange the MIKey message 2a. iv 738, in which security credentials are completed to enable protected RSU-to-RSU communications.

[0081] Similarly, the RSU 2 706 performs the 0b configuration 708, conducts the service authorization 1 b 740 with the Function Management Entity 720, and requests the key 2b. i 742 from the Key Management Entity 724. The Key Management Entity 724 checks the algorithms 2b. ii 730 and provides the key response 2b.iii 744 to the RSU 2 706. The RSU 2 706 and the Key Management Entity 724 exchange the MIKey message 2b. iv 746, in which security credentials are completed to enable protected RSU-to-RSU communications.

[0082] Upon completion of the security credentialing process, the RSU 1 702 may send protected messages 3a 748 to the RSU 2 706 and the RSU 2 706 may send protected messages 3b 750 to the RSU 1 702. In response to receiving a protected message (e.g., the 3b 750), the RSU 1 702 may process received data 4a 710.

Similarly, in response to receiving a protected message (e.g., the 3a 748), the RSU 2 706 may process received data 4b 712.

[0083] It is appreciated that the security mechanism 700 may be utilized in the in RSU-to-RSU communications illustrated in FIG. 6. In the case that the security mechanism 700 is utilized in the RSU-to-RSU communications illustrated in FIG. 6, it is noted that the configuration procedure (0a 704, 0b 708, 0c 722, and Od 726) should be performed offline and thus are not related to any operation of FIG. 6. In addition, it is noted that the messages 1 a through 2a. iv (respectively, 1 b through 2b. iv) are exchanged during RSU registration process, which is operation 1 a

(respectively, operation 1 b) of FIG. 6. Furthermore, it is noted that the messages 3a 748 and 3b 750 are exchanged during RSU communication, which is operation 4 of FIG. 6.

[0084] In the de-centralized model, the RSUs create a database of nearby RSUs based on location information provided by multi-mode UEs and then use the database information provided by the UE sending the message to discover the location of the nearby DSRC RSU.

[0085] In the de-centralized model, a first technology RSU creates a database with local RSUs (e.g., second technology RSUs), their IP address and their physical location. A given first technology RSU receives a message from a device that includes the device location. The first technology RSU looks up the database of local RSUs and chooses a second technology RSU that is closest (or within a predefined threshold, for example) to the device that sent the message. The first technology RSU sends the message to the second technology RSU (@IP address) based on the database information.

[0086] For example, eNB RSUs create a database with local RSUs, their IP address and their physical location. A given eNB RSU receives a message from a UE that includes the UE location (i.e., the location of the UE). The eNB RSU looks up the database of local DSRC RSUs and chooses the DSRC RSU that is closest to the UE that sent the message. The eNB RSU sends the message to the DSRC RSU (@IP address) based on the database information.

[0087] For an eNB to learn the location and identity of nearby DSRC RSUs, one of the following processes may be used. If a UE can provide the IP address of DSRC RSUs nearby, then a first set of cases is possible. These case are provided here.

[0088] When multi-mode UEs (e.g., 3GPP devices that also support DSRC) send messages to the eNB, they may report the MAC address and IP address of the nearby DSRC RSUs. The location of the DSRC RSU may then be found by using the MAC address of the DSRC RSU and an existing functionality in DHCP [RFC 4676 (Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information] and [RFC 6225: Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information], designed to provide civic addresses. Using these techniques and/or like location techniques, the eNB maps the DSRC RSU IP address to the location found.

[0089] Additionally or alternatively, when multi-mode UEs (e.g., 3GPP devices that also support DSRC) send messages to the eNB, they may report their location and the IP address of the nearby DSRC RSU. The eNB may use the UE location to approximate a location of the DSRC RSU. Although this is an approximate location, since the coverage area of DSRC RSUs is small, it can be assumed that the location of the DSRC RSU is very close to the location of the reporting UE. Thus, in this case, the eNB relates the IP address of the DSRC RSU to the sending UE location.

[0090] It is noted that for any of the embodiments described herein, in addition to reporting the UE location, a UE may also report its velocity and direction of travel to help the eNB to find the closest DSRC RSU based on the UE location, velocity, and direction of travel. Accordingly, an eNB or other RSU may use this information to find the closest RSU in the RSU DB.

[0091] Additionally or alternatively, when multi-mode UEs (e.g., 3GPP devices that also support DSRC) send messages to the eNB, they may report the MAC address and IP address of the nearby DSRC RSU. The eNB may query the National Emergency Address Database (NEAD) with this reported MAC address. The NEAD is the database that provides the correlation between MAC address and

dispatchable locations (see, for example,

http://apps.fcc.gov/ecfs/document/view?id=60000986637). The eNB may then map the DSRC RSU IP address to the location found (e.g., the dispatchable location).

[0092] In some embodiments, a DSRC RSU may advertise its IP address and location as a part of a DSRC service advertisement. In some embodiments, multi- mode UEs (e.g., 3GPP devices that also support DSRC) may forward these DSRC RSU service advertisements to the eNBs, which enable the eNBs to build an RSU DB (and/or a map of available RSUs, for example) as described herein.

[0093] In some embodiments, this information that is sent from the UE to the eNB RSU may be sent in a V2X message that the eNB RSU can read. Additionally or alternatively, this information may optionally be sent in an RRC message from the UE to the eNB.

[0094] In some cases, the DSRC RSU knows its location via a GNSS discovery, or it is configured with its location, and communication between the DSRC RSU and the eNB is used to share the location information. In some embodiments, this communication may be done via the IKEv2 protocol [RFC 5996: Internet Key Exchange Protocol Version 2 (IKEv2)]. For example, the location information may be communicated using the "vendor ID payload," "Notify payload" or "Configuration payload" defined in RFC 5996.

[0095] In some embodiments, all DSRC RSUs may register with a "V2X function" entity in the 3GPP network. The eNB may then query the "V2X function" entity to find the location of the DSRC RSUs and/or generate the RSU DB.

[0096] In some embodiments, a special FQDN may be created for DSRC RSUs. The UE may use this special, well-known DSRC RSU FQDN as the generic address of the closest DSRC RSU. A domain name server (DNS) may be configured with this special DSRC RSU FQDN so that when the DNS server is queried for this address, it will provide the location of the closest DSRC RSU.

[0097] FIG. 8 is an example of database creation in a de-centralized model 800. In this example, the de-centralized model 800 includes a multi-mode device 802 and the LTE eNB/RSU 502, the DSRC RSU 504, and the DSRC-only device 510, as discussed with respect to FIG. 5. It is noted that the below procedures describe how eNB RSUs can create the database (i.e., RSU DB). However, similar procedures can be used by DSRC RSUs or other technology RSUs.

[0098] In the de-centralized model 800, the multi-mode device 802 receives information from the DSRC RSU 504 including an address (e.g., IP address or FQDN) of the DSRC RSU 504 and provides the multi-mode device's 802 location and the address of the DSRC RSU 504 to the LTE eNB/RSU 502. The procedures below describes how eNB RSUs can create the database. Similar process can be used by DSRC RSUs. [0099] At operation 1 ) 804, the DSRC RSU 504 (or in a different embodiment, another DSRC device) sends a DSRC message. The DSRC message may be sent using DSRC technology and as such may only be received by DSRC-capable devices (e.g., the multi-mode device 802 and the DSRC-only device 510). In this case, the DSRC message is sent 804-a to the multi-mode device 802 and sent 804-b to the DSRC-only device 510. In some embodiments, the DSRC message includes an IP address (or FQDN, for example) associated with the DSRC RSU 504.

[0100] At operation 2) 806, the multi-mode device 802 receives information from the DSRC RSU 504 and learns the RSU IP address. At operation 3) 808, the multi- mode device 802 provides its current location and the DSRC RSU IP address to the LTE eNB/RSU 502. In one example, this information may be provided in a V2X message. In another example, this information may be provided in a 3GPP message, such as an RRC message.

[0101] At operation 4) 810, the LTE eNB/RSU 502 generates and/or updates a DSRC RSU table (e.g., the RSU DB 400) with the IP address and approximate location of the DSRC RSU 504. The approximate location may be determined based on the reported location of the multi-mode device 802 and/or any of the other procedures described herein (e.g., based on IP address and/or MAC address of the DSRC RSU 504).

[0102] Once the location of the DSRC RSU 504 is found (using any combination of the above procedures), the LTE eNB/RSU 502 may store and maintain a database (e.g., the RSU DB 400) of DSRC RSUs, their location, and their IP address. With the RSU DB 400 populated, the LTE eNB/RSU 502 may use the RSU DB 400 to forward messages to different technology RSUs (the next hop, the DSRC RSU 504, for example). The LTE eNB/RSU 502 may use this RSU DB 400 (e.g., database/map) as described below.

[0103] In some embodiments, a UE not supporting DSRC sends a V2X message to an LTE eNB/RSU. Together with the message the sending UE also includes its own physical location. This is already proposed in 3GPP RAN1 (to add the UE location into the Buffer Status Report). Optionally, the sending UE may include other parameters, such as the velocity and direction of travel. The LTE eNB/RSU determines that this message needs to be forwarded to a DSRC RSU. Based on the parameters provided by the sending UE and the database with DSRC RSU information (e.g., the RSU DB 400), the LTE eNB/RSU determines the best DSRC RSU to forward the message. The LTE eNB/RSU forwards the message to the (determined best, for example) DSRC RSU. The DSRC RSU decides if the message should be transmitted to the local devices (local DSRC devices, for example).

[0104] It is noted that a 5G RSU may be known to the eNB RSU and vice versa, since they may all be part of an operator network. For different operators (inter- PLMN procedure, for example), communication with explicitly dedicated messages between the networks may be used to update such information. It is appreciated that similar process can be used for the DSRC RSU to find the location of LTE eNB/RSUs, 5G RSUs, and/or other technology RSUs.

[0105] FIG. 9 is an example of a de-centralized model 900 in which the LTE eNB/RSU 502 receives a V2X message and forwards the message to the DSRC RSU 504 based on the RSU DB 400. In this example, the de-centralized model 900 includes the LTE eNB/RSU 502, the DSRC RSU 504, the 3GPP-only device 508, and the DSRC-only device 510.

[0106] In the de-centralized model 900, each of the RSUs (e.g., the LTE eNB/RSU 502, DSRC RSU 504) may generate and/or maintain an RSU DB 400 using the techniques discussed previously. In this example, the LTE eNB/RSU 502 has a previously generated/maintained the RSU DB 400. The RSU DB 400 may be an example of the RSU DB discussed in FIG. 4. With the RSU DB 400 populated, the LTE eNB/RSU 502 may use the RSU DB 400 to forward messages to different technology RSUs (the next hop, for example).

[0107] At operation 1 ) 902, the 3GPP-only device 508 sends a V2X message. It is appreciated that the 3GPP-only device 508 may only send and receive V2X messages using 3GPP technology. So, although the DSRC-only device 510, which may only send and receive V2X messages using DSRC technology, is in close proximity to the 3GPP-only device 508, the DSRC-only device 510 would not receive the V2X message (e.g., operation 1 ) 902) sent by the 3GPP-only device 508. As discussed above, this lack of communication across technologies is unacceptable. But, as described herein, this issue can be ameliorated through the use of the RSU DB 400.

[0108] The LTE eNB/RSU 502 receives the V2X message (e.g., operation 1 ) 902). In some embodiments, the V2X message may include the location of the 3GPP-only device 508. The LTE eNB/RSU 502 may determine that the message is a 3GPP- only message and, depending on the message type, may need to be communicated to devices using other technologies. The LTE eNB/RSU 502 may compare the location of the 3GPP-only device 508 with the location of other technology RSUs in the RSU DB 400 and may determine that the DSRC RSU 504 is in proximity (within a threshold, for example) to the 3GPP-only device 508. The LTE eNB/RSU 502 may further determine that since the message was a 3GPP-only message, the message needs to be forwarded to the DSRC RSU 504 for

communication to DSRC devices in the area of the 3GPP-only device 508. At operation 2) 904, the LTE eNB/RSU 502 forwards a message (e.g., the V2X message or some portion of the V2X message) to the DSRC RSU 504 (e.g., the "next hop" RSU). Although only one hop is shown, it is appreciated that multiple hop procedures are comprehended in this description.

[0109] At operation 3) 906, the DSRC RSU 504 broadcasts the message using the DSRC technology and the message is received by the DSRC-only device 510. In this way, the DSRC-only device 510 may receive V2X messages that were originally sent by the 3GPP-only device 508.

[0110] FIG. 10 is an example of a de-centralized model 1000 in which the multi- mode device 802 acts as a relay for inter-RAT interoperability. In this example, the de-centralized model 1000 includes the LTE eNB/RSU 502, the DSRC RSU 504, the 3GPP-only device 508, the DSRC-only device 510, and the multi-mode device 802.

[0111] In the de-centralized model 1000, each of the RSUs (e.g., LTE eNB/RSU 502, DSRC RSU 504) may generate and/or maintain an RSU DB 400 using the techniques discussed previously. In this example, the LTE eNB/RSU 502 has a previously generated/maintained the RSU DB 400. The RSU DB 400 may be an example of the RSU DB discussed in FIG. 4. With the RSU DB 400 populated, the LTE eNB/RSU 502 may use the RSU DB 400 to forward messages to different technology RSUs (the next hop, for example).

[0112] At operation 1 ) 1002, the multi-mode device 802 informs the LTE eNB/RSU 502 of its multi-mode capabilities and its current location. At operation 2) 1004, the multi-mode device 802 is elected to be a relay for the LTE eNB/RSU 502.

[0113] At operation 3) 1006, the 3GPP-only device 508 sends a V2V message in 3GPP to all devices. It is appreciated that the 3GPP-only device 508 may only send and receive V2V messages using 3GPP technology. So, although the DSRC-only device 510, which may only send and receive V2X messages using DSRC technology, is in close proximity to the 3GPP-only device 508, the DSRC-only device 510 would not receive the V2V message (e.g., operation 3) 1006) sent by the 3GPP- only device 508. As discussed above, this lack of communication across

technologies is problematic. But, as described herein, this issue can be ameliorated through the use of the RSU DB 400.

[0114] At operation 4) 1008, the V2V message is received in 3GPP by the multi- mode device 802. Since the multi-mode device 802 is configured to be a relay for the LTE eNB/RSU 502 the multi-mode device 802 may be configured to forward messages to the LTE eNB/RSU 502.

[0115] At operation 5) 1010, the multi-mode device 802 forwards the message (e.g., V2X message or some portion of the V2X message) to the LTE eNB/RSU 502 and informs the LTE eNB/RSU 502 that the message was a 3GPP message.

[0116] The LTE eNB/RSU 502 receives the message (e.g., operation 5) 1010). The LTE eNB/RSU 502 may determine that the message is a 3GPP-only message and, depending on the message type, may need to be communicated to devices using other technologies. The LTE eNB/RSU 502 may compare the location of the 3GPP-only device 508 and/or the location of the multi-mode device 802 with the location of other technology RSUs in the RSU DB 400 and may determine that the DSRC RSU 504 is in proximity (within a threshold, for example) to the 3GPP-only device 508 and/or the multi-mode device 802. The LTE eNB/RSU 502 may further determine that since the message was a 3GPP-only message, the message needs to be forwarded to the DSRC RSU 504 for communication to DSRC devices in the area of the 3GPP-only device 508.

[0117] At operation 6) 1012, the LTE eNB/RSU 502 finds the DSRC RSU 504 IP address based on the RSU DB 400 and forwards the message to the DSRC RSU 504. Although only one hop is shown, it is appreciated that multiple hop procedures are comprehended in this description.

[0118] At operation 7) 1014, the DSRC RSU 504 decides if it should rebroadcast the message (e.g., operation 6) 1012). In some cases, this decision may be based on the message type and/or a time threshold.

[0119] At operation 8) 1016, the DSRC RSU 504 broadcasts the message using the DSRC technology and the message is received by the DSRC-only device 510. In this way, the DSRC-only device 510 may receive V2V messages that were originally sent by the 3GPP-only device 508. [0120] Regarding the security of the de-centralized model, there are three communication channels that need to be secured: between V2V (e.g., between UEs), between the UEs and RSUs, and finally between the RSUs. The described models may use the established security mechanisms for V2V (such as the one specified in "Technical Design of the Security Credential Management System" - https://www.regulations.gov/document?D=NHTSA-2015-0060-00046) and use the established security mechanisms for communication between UEs and RSUs depending on the technology (such as DSRC, LTE, 3GPP, 5G). Regarding the security for the communication between the RSUs, the same principle disclosed for the centralized model may be used for the de-centralized model.

[0121] It is noted that V2X messages may also be forwarded between RSUs of the same RAT (e.g., 5G RSU to 5G RSU) and target RSU of same type (e.g., 5G RAT) may further forward V2X message to RSU of different RAT type (e.g., DSRC RSU). This takes care of the case where some of the RSUs may not support the feature of "forwarding V2X messages to another RSU of different RAT" because, e.g., there is no direct interface between those two RSUs. Therefore those RSUs could forward V2X messages to another RSU of same RAT type (using X2 interface) and the target RSU of same RAT type would forward V2X messages. For example, a first LTE eNB RSU forwards to a second LTE eNB RSU; and a second LTE eNB RSU forwards to one or more DSRC RSUs. In some embodiments, this mechanism applies to both centralized and de-centralized approaches.

[0122] FIG. 1 1 is a flow diagram of a method 1 100 for wireless communication. The method 1 100 is performed by a device, such as a user equipment (UE) (e.g., a multi-mode UE) or the like. In particular, the method 1 100 may be performed by a processor (e.g., a baseband processor) within the device. Although the operations of the method 1 100 are illustrated as being performed in a particular order, it is understood that the operations of the method 1 100 may be reordered without departing from the scope of the method 1 100.

[0123] At 1 102, a first V2X message is decoded. The first V2X message includes an IP address for a first RAT RSU. At 1 104, a reporting message for a second RAT RSU is generated. The reporting message includes the IP address for the first RAT RSU. [0124] The operations of the method 1 100 may be performed by an application- specific processor, programmable application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like.

[0125] FIG. 12 is a flow diagram of a method 1200 for wireless communication. The method 1200 is performed by a device, such as server (e.g., a mobile edge compute server) or the like. In particular, the method 1200 may be performed by a processor within the device. Although the operations of the method 1200 are illustrated as being performed in a particular order, it is understood that the operations of the method 1200 may be reordered without departing from the scope of the method 1200.

[0126] At 1202, a first registration message from a first technology RSU is decoded. At 1204, a second registration message from a second technology RSU is decoded. The second registration message includes a location of the second technology RSU and an IP address of the second technology RSU. At 1206, the database of RSU information is generated based at least in part on the first registration message and the second registration message. At 1208, a next hop RSU for V2X message from a first technology device is determined based at least in part on a location of the first technology device and the database of RSU

information, where the next hop RSU is the second technology RSU.

[0127] The operations of the method 1200 may be performed by an application- specific processor, programmable application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like.

[0128] FIG. 13 is a flow diagram of a method 1300 for wireless communication. The method 1300 is performed by a device, such as a RSU or the like. In particular, the method 1300 may be performed by a processor within the device. Although the operations of the method 1300 are illustrated as being performed in a particular order, it is understood that the operations of the method 1300 may be reordered without departing from the scope of the method 1300.

[0129] At 1302, a first V2X message from a first RAT device is decoded. The first V2X message includes an IP address of the first RAT device. At 1304, an RSU from the plurality of RSUs in the database of RSU information that is close to the location of the first RAT device is determined, where the RSU is the second RAT RSU. At 1306, the V2X message is forwarded from the first RAT RSU to the second RAT RSU. [0130] The operations of the method 1300 may be performed by an application- specific processor, programmable application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like.

[0131] FIG. 14 illustrates an architecture of a system 1400 of a network in accordance with some embodiments. The system 1400 is shown to include a user equipment (UE) 1401 and a UE 1402. The UEs 1401 and 1402 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

[0132] In some embodiments, any of the UEs 1401 and 1402 can comprise an Internet of Things (loT) UE, which can comprise a network access layer designed for low-power loT applications utilizing short-lived UE connections. An loT UE can utilize technologies such as machine-to-machine (M2M) or machine-type

communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to- device (D2D) communication, sensor networks, or loT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An loT network describes interconnecting loT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.

[0133] The UEs 1401 and 1402 may be configured to connect, e.g.,

communicatively couple, with a radio access network (RAN) 1410. The RAN 1410 may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs 1401 and 1402 utilize connections 1403 and 1404, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 1403 and 1404 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like.

[0134] In this embodiment, the UEs 1401 and 1402 may further directly exchange communication data via a ProSe interface 1405. The ProSe interface 1405 may alternatively be referred to as a sidelink interface comprising one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery

Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0135] The UE 1402 is shown to be configured to access an access point (AP) 1406 via connection 1407. The connection 1407 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.1 1 protocol, wherein the AP 1406 would comprise a wireless fidelity (WiFi®) router. In this example, the AP 1406 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).

[0136] The RAN 1410 can include one or more access nodes that enable the connections 1403 and 1404. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNB), RAN nodes, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The RAN 1410 may include one or more RAN nodes for providing macrocells, e.g., macro RAN node 141 1 , and one or more RAN nodes for providing femtocells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low power (LP) RAN node 1412.

[0137] Any of the RAN nodes 141 1 and 1412 can terminate the air interface protocol and can be the first point of contact for the UEs 1401 and 1402. In some embodiments, any of the RAN nodes 141 1 and 1412 can fulfill various logical functions for the RAN 1410 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0138] In accordance with some embodiments, the UEs 1401 and 1402 can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 141 1 and 1412 over a multicarrier communication channel in accordance various communication techniques, such as, but not limited to, an Orthogonal Frequency- Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0139] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 141 1 and 1412 to the UEs 1401 and 1402, while uplink transmissions can utilize similar techniques. The grid can be a time- frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid

corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0140] The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the UEs 1401 and 1402. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 1401 and 1402 about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 1402 within a cell) may be performed at any of the RAN nodes 141 1 and 1412 based on channel quality information fed back from any of the UEs 1401 and 1402. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 1401 and 1402. [0141] The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1 , 2, 4, or 8).

[0142] Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

[0143] The RAN 1410 is shown to be communicatively coupled to a core network (CN) 1420—via an S1 interface 1413. In embodiments, the CN 1420 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface 1413 is split into two parts: the S1 -U interface 1414, which carries traffic data between the RAN nodes 141 1 and 1412 and a serving gateway (S-GW) 1422, and an S1 -mobility

management entity (MME) interface 1415, which is a signaling interface between the RAN nodes 141 1 and 1412 and MMEs 1421 .

[0144] In this embodiment, the CN 1420 comprises the MMEs 1421 , the S-GW 1422, a Packet Data Network (PDN) Gateway (P-GW) 1423, and a home subscriber server (HSS) 1424. The MMEs 1421 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 1421 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 1424 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The CN 1420 may comprise one or several HSSs 1424, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 1424 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

[0145] The S-GW 1422 may terminate the S1 interface 1413 towards the RAN 1410, and routes data packets between the RAN 1410 and the CN 1420. In addition, the S-GW 1422 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

[0146] The P-GW 1423 may terminate an SGi interface toward a PDN. The P- GW 1423 may route data packets between the CN 1420 (e.g., an EPC network) and external networks such as a network including the application server 1430

(alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 1425. Generally, an application server 1430 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW 1423 is shown to be communicatively coupled to an application server 1430 via an IP communications interface 1425. The application server 1430 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 1401 and 1402 via the CN 1420.

[0147] The P-GW 1423 may further be a node for policy enforcement and charging data collection. A Policy and Charging Enforcement Function (PCRF) 1426 is the policy and charging control element of the CN 1420. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP- CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF 1426 may be communicatively coupled to the application server 1430 via the P-GW 1423. The application server 1430 may signal the PCRF 1426 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 1426 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server 1430.

[0148] FIG. 15 illustrates example components of a device 1500 in accordance with some embodiments. In some embodiments, the device 1500 may include application circuitry 1502, baseband circuitry 1504, Radio Frequency (RF) circuitry 1506, front-end module (FEM) circuitry 1508, one or more antennas 1510, and power management circuitry (PMC) 1512 coupled together at least as shown. The components of the illustrated device 1500 may be included in a UE or a RAN node. In some embodiments, the device 1500 may include fewer elements (e.g., a RAN node may not utilize application circuitry 1502, and instead include a

processor/controller to process IP data received from an EPC). In some

embodiments, the device 1500 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

[0149] The application circuitry 1502 may include one or more application processors. For example, the application circuitry 1502 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 or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 1500. In some embodiments, processors of application circuitry 1502 may process IP data packets received from an EPC.

[0150] The baseband circuitry 1504 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1504 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1506 and to generate baseband signals for a transmit signal path of the RF circuitry 1506. Baseband processing circuity 1504 may interface with the application circuitry 1502 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1506. For example, in some embodiments, the baseband circuitry 1504 may include a third generation (3G) baseband processor 1504A, a fourth generation (4G) baseband processor 1504B, a fifth generation (5G) baseband processor 1504C, or other baseband processor(s) 1504D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 1504 (e.g., one or more of baseband processors 1504A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1506. In other embodiments, some or all of the functionality of baseband processors 1504A-D may be included in modules stored in the memory 1504G and executed via a Central Processing Unit (CPU) 1504E. 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 1504 may include Fast- Fourier Transform (FFT), precoding, or constellation mapping/demapping

functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1504 may include convolution, tail-biting convolution, turbo, Viterbi, 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.

[0151] In some embodiments, the baseband circuitry 1504 may include one or more audio digital signal processor(s) (DSP) 1504F. The audio DSP(s) 1504F 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 1504 and the application circuitry 1502 may be implemented together such as, for example, on a system on a chip (SOC).

[0152] In some embodiments, the baseband circuitry 1504 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1504 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), or a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 1504 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0153] RF circuitry 1506 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1506 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. The RF circuitry 1506 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1508 and provide baseband signals to the baseband circuitry 1504. RF circuitry 1506 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1504 and provide RF output signals to the FEM circuitry 1508 for transmission.

[0154] In some embodiments, the receive signal path of the RF circuitry 1506 may include mixer circuitry 1506A, amplifier circuitry 1506B and filter circuitry 1506C. In some embodiments, the transmit signal path of the RF circuitry 1506 may include filter circuitry 1506C and mixer circuitry 1506A. RF circuitry 1506 may also include synthesizer circuitry 1506D for synthesizing a frequency for use by the mixer circuitry 1506A of the receive signal path and the transmit signal path. In some

embodiments, the mixer circuitry 1506A of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1508 based on the synthesized frequency provided by synthesizer circuitry 1506D. The amplifier circuitry 1506B may be configured to amplify the down-converted signals and the filter circuitry 1506C 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 1504 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, the mixer circuitry 1506A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0155] In some embodiments, the mixer circuitry 1506A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1506D to generate RF output signals for the FEM circuitry 1508. The baseband signals may be provided by the baseband circuitry 1504 and may be filtered by the filter circuitry 1506C.

[0156] In some embodiments, the mixer circuitry 1506A of the receive signal path and the mixer circuitry 1506A of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 1506A of the receive signal path and the mixer circuitry 1506A 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 1506A of the receive signal path and the mixer circuitry 1506A may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1506A of the receive signal path and the mixer circuitry 1506A of the transmit signal path may be configured for super-heterodyne operation.

[0157] 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 1506 may include analog- to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1504 may include a digital baseband interface to communicate with the RF circuitry 1506.

[0158] 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.

[0159] In some embodiments, the synthesizer circuitry 1506D 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 1506D may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0160] The synthesizer circuitry 1506D may be configured to synthesize an output frequency for use by the mixer circuitry 1506A of the RF circuitry 1506 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1506D may be a fractional N/N+1 synthesizer. [0161] 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 1504 or the application circuitry 1502 (such as an applications processor) 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 application circuitry 1502.

[0162] Synthesizer circuitry 1506D of the RF circuitry 1506 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 flip-flop. 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.

[0163] In some embodiments, the synthesizer circuitry 1506D 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 1506 may include an IQ/polar converter.

[0164] FEM circuitry 1508 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1510, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1506 for further processing. The FEM circuitry 1508 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1506 for transmission by one or more of the one or more antennas 1510. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1506, solely in the FEM circuitry 1508, or in both the RF circuitry 1506 and the FEM circuitry 1508.

[0165] In some embodiments, the FEM circuitry 1508 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 1508 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 1508 may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1506). The transmit signal path of the FEM circuitry 1508 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by the RF circuitry 1506), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1510).

[0166] In some embodiments, the PMC 1512 may manage power provided to the baseband circuitry 1504. In particular, the PMC 1512 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1512 may often be included when the device 1500 is capable of being powered by a battery, for example, when the device 1500 is included in a UE. The PMC 1512 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0167] FIG. 15 shows the PMC 1512 coupled only with the baseband circuitry 1504. However, in other embodiments, the PMC 1512 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, the application circuitry 1502, the RF circuitry 1506, or the FEM circuitry 1508.

[0168] In some embodiments, the PMC 1512 may control, or otherwise be part of, various power saving mechanisms of the device 1500. For example, if the device 1500 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 1500 may power down for brief intervals of time and thus save power.

[0169] If there is no data traffic activity for an extended period of time, then the device 1500 may transition off to an RRCJdle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1500 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 1500 may not receive data in this state, and in order to receive data, it transitions back to an RRC_Connected state.

[0170] An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[0171] Processors of the application circuitry 1502 and processors of the baseband circuitry 1504 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1504, alone or in combination, may be used to execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1502 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g.,

transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

[0172] FIG. 16 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 1504 of FIG. 15 may comprise processors 1504A-1504E and a memory 1504G utilized by said processors. Each of the processors 1504A-1504E may include a memory interface, 1604A-1604E, respectively, to send/receive data to/from the memory 1504G.

[0173] The baseband circuitry 1504 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 1612 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1504), an application circuitry interface 1614 (e.g., an interface to send/receive data to/from the application circuitry 1502 of FIG. 15), an RF circuitry interface 1616 (e.g., an interface to send/receive data to/from RF circuitry 1506 of FIG. 15), a wireless hardware connectivity interface 1618 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 1620 (e.g., an interface to send/receive power or control signals to/from the PMC 1512.

[0174] FIG. 17 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

Specifically, FIG. 17 shows a diagrammatic representation of hardware resources 1700 including one or more processors (or processor cores) 1710, one or more memory/storage devices 1720, and one or more communication resources 1730, each of which may be communicatively coupled via a bus 1740. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1702 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1700.

[0175] The processors 1710 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1712 and a processor 1714.

[0176] The memory/storage devices 1720 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1720 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable

programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

[0177] The communication resources 1730 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1704 or one or more databases 1706 via a network 1708. For example, the communication resources 1730 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular

communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

[0178] Instructions 1750 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1710 to perform any one or more of the methodologies discussed herein. The instructions 1750 may reside, completely or partially, within at least one of the processors 1710 (e.g., within the processor's cache memory), the memory/storage devices 1720, or any suitable combination thereof. Furthermore, any portion of the instructions 1750 may be transferred to the hardware resources 1700 from any combination of the peripheral devices 1704 or the databases 1706. Accordingly, the memory of processors 1710, the memory/storage devices 1720, the peripheral devices 1704, and the databases 1706 are examples of computer-readable and machine-readable media.

Example Embodiments

[0179] Example 1 is an apparatus of a multi-mode user equipment (UE). The apparatus includes a memory and one or more processors. The memory is for storing an internet protocol (IP) address. The one or more processors are to decode a first vehicle-to-anything (V2X) message, the first V2X message having an IP address for a first radio access technology (RAT) road side unit (RSU), wherein the first RAT RSU uses a first RAT, and generate a reporting message for a second RAT RSU, the reporting message including the IP address for the first RAT RSU, wherein the second RAT RSU uses the second RAT, wherein the second RAT is different from the first RAT.

[0180] Example 2 is the apparatus of Example 1 , wherein the reporting message further includes a current location of the multi-mode UE.

[0181] Example 3 is the apparatus of Example 1 or 2, wherein the one or more processors are further to generate a second V2X message for the second RAT RSU, wherein the second V2X message includes at least a portion of the first V2X message.

[0182] Example 4 is the apparatus of Example 3, wherein the second V2X message includes an indication that the first V2X message is associated with the first RAT. [0183] Example 5 is the apparatus of Example 3, wherein the second V2X message further includes a current location of the multi-mode UE.

[0184] Example 6 is the apparatus of any of Examples 1 -5, wherein the first RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) device, a 3GPP 5G new radio (NR) device, a dedicated short range communication (DSRC) device, or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 device.

[0185] Example 7 is the apparatus of Example 6, wherein the second RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) device, a 3GPP 5G new radio (NR) device, a dedicated short range communication (DSRC) device; or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 device.

[0186] Example 8 is the apparatus of any of Examples 1 -7, wherein the one or more processors are further to generate a capabilities message for the second RAT RSU, the capabilities message indicating that the multi-mode UE supports the first RAT in addition to the second RAT.

[0187] Example 9 is an apparatus. The apparatus includes a memory and one or more processors. The memory is for storing a database of road side unit (RSU) information for a plurality of RSUs, wherein the plurality of RSUs include a first technology RSU that uses a first technology and a second technology RSU that uses a second technology, wherein the first technology is different than the second technology. The one or more processors are to decode a first registration message from the first technology RSU, decode a second registration message from the second technology RSU, the second registration message including a location of the second technology RSU and an internet protocol (IP) address of the second technology RSU, generate the database of RSU information based at least in part on the first registration message and the second registration message, and determine a next hop RSU for a vehicle-to-anything (V2X) message from a first technology device based at least in part on a location of the first technology device and the database of RSU information, wherein the next hop RSU is the second technology RSU.

[0188] Example 10 is the apparatus of Example 9, wherein the one or more processors are further to decode the V2X message from the first technology device, wherein the V2X message is forwarded to the apparatus from the first technology RSU, and forward the V2X message to the second technology RSU using the IP address of the second technology RSU. [0189] Example 1 1 is the apparatus of Examples 9 or 10, wherein the one or more processors are further to decode a query from the first technology RSU for next hops for the V2X message, and generate a response for the first technology RSU, wherein the response includes the IP address of the second technology RSU.

[0190] Example 12 is the apparatus of any of Examples 9-1 1 , wherein the V2X message is a first technology V2X message.

[0191] Example 13 is the apparatus of any of Examples 9-12, wherein the apparatus is a mobile edge compute application that is accessible via a mobile edge compute server, a mobile edge compute server, or a server that is accessible via the internet.

[0192] Example 14 is the apparatus of any of Examples 9-13, wherein the first technology is 3rd Generation Partnership Project (3GPP) long-term evolution (LTE), 3GPP 5G new radio (NR), dedicated short range communication (DSRC), or Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

[0193] Example 15 is the apparatus of Example 14, wherein the second technology is 3rd Generation Partnership Project (3GPP) long-term evolution (LTE), 3GPP 5G new radio (NR), dedicated short range communication (DSRC), or Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

[0194] Example 16 is the apparatus of any of Examples 9-15, wherein the first registration message includes a location of the first technology RSU and an internet protocol (IP) address of the first technology RSU.

[0195] Example 17 is a first radio access technology (RAT) road side unit (RSU) that uses a first RAT. The first RAT RSU includes a memory and one or more processors. The memory is to store a database of road side unit (RSU) information for a plurality of RSUs, wherein the plurality of RSUs include a second RAT RSU that uses a second RAT, the second RAT being different from the first RAT. The one or more processors are to decode a first vehicle-to-anything (V2X) message from a first RAT device, the first V2X message including a location of the first RAT device, determine an RSU from the plurality of RSUs in the database of RSU information that is close to the location of the first RAT device, wherein the RSU is the second RAT RSU, and forward the V2X message from the first RAT RSU to the second RAT RSU.

[0196] Example 18 is the first RAT RSU of Example 17, wherein the database of RSU information includes at least one of an internet protocol (IP) address and a fully qualified domain name (FQDN) of the second RAT RSU, and wherein the V2X message is forwarded to the second RAT RSU using the at least one of the IP address and the FQDN of the second RAT RSU.

[0197] Example 19 is the first RAT RSU of Example 18, wherein the one or more processors are further to decode a message from a multi-mode device that includes the at least one of the IP address and the FQDN of the second RAT RSU, update the database of RSU information with an entry for the second RAT RSU, and update the database of RSU information with the at least one of the IP address and the FQDN of the second RAT RSU.

[0198] Example 20 is the first RAT RSU of Example 19, wherein the one or more processors are further to determine an approximate location of the second RAT RSU based at least in part on at least one of a location of the multi-mode device and the IP address of the second RAT RSU, and update the database of RSU information with the approximate location of the second RAT RSU.

[0199] Example 21 is the first RAT RSU of any of Examples 17-20, wherein the first RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) device, a 3GPP 5G new radio (NR) device, a dedicated short range communication (DSRC) device, or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 device.

[0200] Example 22 is the first RAT RSU of Example 21 , wherein the second RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) device, a 3GPP 5G new radio (NR) device, a dedicated short range communication (DSRC) device, or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 device.

[0201] Example 23 is a method by a multi-mode user equipment (UE) for wireless communication. The method includes decoding a first vehicle-to-anything (V2X) message, the first V2X message having an internet protocol (IP) address for a first radio access technology (RAT) road side unit (RSU), wherein the first RAT RSU uses a first RAT, and generating a reporting message for a second RAT RSU, the reporting message including the IP address for the first RAT RSU, wherein the second RAT RSU uses the second RAT, wherein the second RAT is different from the first RAT.

[0202] Example 24 is the method of Example 23, wherein the reporting message further includes a current location of the multi-mode UE. [0203] Example 25 is the method of any of Examples 23 or 24, further includes generating a second V2X message for the second RAT RSU, wherein the second

V2X message includes at least a portion of the first V2X message.

[0204] Example 26 is the method of Example 25, wherein the second V2X message includes an indication that the first V2X message is associated with the first

RAT.

[0205] Example 27 is the method of Example 25, wherein the second V2X message further includes a current location of the multi-mode UE.

[0206] Example 28 is the method of any of Examples 23-27, wherein the first RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) RAT, a 3GPP 5G new radio (NR) RAT, a dedicated short range communication (DSRC) RAT, or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 RAT.

[0207] Example 29 is the method of Example 28, wherein the second RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) RAT, a 3GPP 5G new radio (NR) RAT, a dedicated short range communication (DSRC) RAT, or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 RAT.

[0208] Example 30 is the method of any of Examples 23-29, further including generating a capabilities message for the second RAT RSU, the capabilities message indicating that the multi-mode UE supports the first RAT in addition to the second RAT.

[0209] Example 31 is a method for wireless communication. The method includes decoding a first registration message from a first technology road side unit (RSU) that uses a first technology, decoding a second registration message from a second technology RSU that uses a second technology, wherein the first technology is different than the second technology, the second registration message including a location of the second technology RSU and an internet protocol (IP) address of the second technology RSU, generating a database of RSU information based at least in part on the first registration message and the second registration message, and determining a next hop RSU for a vehicle-to-anything (V2X) message from a first technology device based at least in part on a location of the first technology device and the database of RSU information, wherein the next hop RSU is the second technology RSU.

[0210] Example 32 is the method of Example 31 , further includes decoding the V2X message from the first technology device, wherein the V2X message is forwarded to the apparatus from the first technology RSU, forwarding the V2X message to the second technology RSU using the IP address of the second technology RSU.

[0211] Example 33 is the method of Example 31 or Example 32, further includes decoding a query from the first technology RSU for next hops for the V2X message, and generating a response for the first technology RSU, wherein the response includes the IP address of the second technology RSU.

[0212] Example 34 is the method of any of Examples 31 -33, wherein the V2X message is a first technology V2X message.

[0213] Example 35 is the method of any of Examples 31 -34, wherein the first technology is 3rd Generation Partnership Project (3GPP) long-term evolution (LTE), 3GPP 5G new radio (NR), dedicated short range communication (DSRC), or Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

[0214] Example 36 is the method of Example 35, wherein the second technology is 3rd Generation Partnership Project (3GPP) long-term evolution (LTE), 3GPP 5G new radio (NR), dedicated short range communication (DSRC), or Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

[0215] Example 37 is the method of any of Examples 31 -36, wherein the first registration message includes a location of the first technology RSU and an internet protocol (IP) address of the first technology RSU.

[0216] Example 38 is a method by a first radio access technology (RAT) road side unit (RSU) that uses a first RAT. The method includes generating a database of road side unit (RSU) information for a plurality of RSUs, wherein the plurality of RSUs include a second RAT RSU that uses a second RAT, the second RAT being different from the first RAT, decoding a first vehicle-to-anything (V2X) message from a first RAT device, the first V2X message including a location of the first RAT device, determining an RSU from the plurality of RSUs in the database of RSU information that is close to the location of the first RAT device, wherein the RSU is the second RAT RSU, and forwarding the V2X message from the first RAT RSU to the second RAT RSU.

[0217] Example 39 is the method of Example 38, wherein the database of RSU information includes at least one of an internet protocol (IP) address and a fully qualified domain name (FQDN) of the second RAT RSU, and wherein the V2X message is forwarded to the second RAT RSU using the at least one of the IP address and the FQDN of the second RAT RSU.

[0218] Example 40 is the method of any of Examples 38-39, further includes decoding a message from a multi-mode device that includes the at least one of the IP address and the FQDN of the second RAT RSU, updating the database of RSU information with an entry for the second RAT RSU, and updating the database of RSU information with the at least one of the IP address and the FQDN of the second RAT RSU.

[0219] Example 41 is the method of Example 40. The method further includes determining an approximate location of the second RAT RSU based at least in part on at least one of a location of the multi-mode device and the IP address of the second RAT RSU, and updating the database of RSU information with the

approximate location of the second RAT RSU.

[0220] Example 42 is the method of any of Examples 38-41 , wherein the first RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) RAT, a 3GPP 5G new radio (NR) RAT, a dedicated short range communication (DSRC) RAT, or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 RAT.

[0221] Example 43 is the method of Example 42, wherein the second RAT is a 3rd Generation Partnership Project (3GPP) long-term evolution (LTE) RAT, a 3GPP 5G new radio (NR) RAT, a dedicated short range communication (DSRC) RAT, or an Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 RAT.

[0222] Example 44 is an apparatus comprising means to perform a method as claimed in any of Examples 23-43.

[0223] Example 45 is a machine-readable storage including machine-readable instructions, when executed by a machine, cause the machine to implement a method or realize an apparatus as claimed in any preceding claim.

[0224] Example 46 is a User Equipment (UE) configured to report its physical location to the eNB when sending a request for resources to transmit a V2X message.

[0225] Example 47 is an eNB RSU that creates a database of nearby RSUs based on the location information provided by the UEs in Example 46.

[0226] Example 48 includes the eNB RSU from Example 47 that uses the database information to discover location of nearby RSUs. [0227] Example 49 includes the RSU from Example 47, where the eNB RSU creates the database with local RSU IP address and physical location.

[0228] Example 50 includes the UE from Example 46 that reports the MAC address and IP address of the nearby RSUs. The location of the nearby RSUs can be found using the MAC address and existing functionality in DHCP V4/V6.

[0229] Example 51 includes Example 50, where the eNB maps the DSRC RSU IP address to the location.

[0230] Example 52 includes the UE in Example 46 wherein the UE supports DSRC, and wherein the messages sent to eNB by the UE report the location and the IP address of nearby RSUs.

[0231] Example 53 includes the UE in Example 46 that can additionally report the velocity and direction of travel to enable the eNB RSU to find the closest DSRC RSU based on UE location.

[0232] Example 54 includes the eNB RSU from Example 50 that may query NEAD to provide correlation between MAC address and dispatch able location.

[0233] Example 55 may include a DSRC RSU that knows its location via a GNSS discovery and communication between DSRC RSU and eNB RSU is used to share the location information done via IKEv2 protocol.

[0234] Example 56 includes a DSRC RSU that registers with the V2X entity in a 3GPP network, which the eNB RSU queries to find the location of the DSRC RSU.

[0235] Example 57 includes the eNB RSU from Example 47, where the eNB decides the best DSRC RSU to forward the V2X message based on the parameters sent by the UE and the database with DSRC RSU information.

[0236] Example 58 may include RSU configured to report its physical location and IP address to the central authority.

[0237] Example 59 includes the RSU from Example 57, where the RSU requests service authorization from the Function Management Entity of the central authority.

[0238] Example 60 includes the RSU from Example 58, where the RSU keys and credentials from the Key Management Entity of the central authority.

[0239] Example 61 includes the Key Management Entity of the central authority from Example 60, where the Key Management Entity checks if the cryptographic algorithms are supported. [0240] Example 62 includes the Key Management Entity from example 61 , where the Key Management Entity reports the key, credentials and MIKey messages to the RSU.

[0241] Example 63 includes two RSUs from example 61 , where the RSUs can securely communicate to each other.

[0242] Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, a non-transitory computer-readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be a RAM, an EPROM, a flash drive, an optical drive, a magnetic hard drive, or another medium for storing electronic data. The eNodeB (or other base station) and UE (or other mobile station) may also include a transceiver component, a counter

component, a processing component, and/or a clock component or timer component. One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high-level procedural or an object-oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or an interpreted language, and combined with hardware implementations.

[0243] It should be understood that many of the functional units described in this specification may be implemented as one or more components, which is a term used to more particularly emphasize their implementation independence. For example, a component may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. [0244] Components may also be implemented in software for execution by various types of processors. An identified component of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, a procedure, or a function.

Nevertheless, the executables of an identified component need not be physically located together, but may comprise disparate instructions stored in different locations that, when joined logically together, comprise the component and achieve the stated purpose for the component.

[0245] Indeed, a component of executable code may be a single instruction, or many instructions, and may even be distributed over several different code

segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within components, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components may be passive or active, including agents operable to perform desired functions.

[0246] Reference throughout this specification to "an example" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment. Thus, appearances of the phrase "in an example" in various places throughout this specification are not necessarily all referring to the same embodiment.

[0247] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on its presentation in a common group without indications to the contrary. In addition, various embodiments and examples may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of embodiments. [0248] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered illustrative and not restrictive, and the embodiments are not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1 . An apparatus of a multi-mode user equipment (UE), the apparatus comprising:

a memory to store an internet protocol (IP) address; and

one or more processors to:

decode a first vehicle-to-anything (V2X) message, the first V2X message having an IP address for a first radio access technology (RAT) road side unit (RSU), wherein the first RAT RSU uses a first RAT; and

generate a reporting message for a second RAT RSU, the reporting message including the IP address for the first RAT RSU, wherein the second RAT RSU uses the second RAT, wherein the second RAT is different from the first RAT.

2. The apparatus of claim 1 , wherein the reporting message further includes a current location of the multi-mode UE.

3. The apparatus of claim 1 , wherein the one or more processors are further to:

generate a second V2X message for the second RAT RSU, wherein the second V2X message includes at least a portion of the first V2X message.

4. The apparatus of claim 3, wherein the second V2X message includes an indication that the first V2X message is associated with the first RAT.

5. The apparatus of claim 3, wherein the second V2X message further includes a current location of the multi-mode UE.

6. The apparatus of claim 1 , wherein the first RAT is selected from the group consisting of:

3rd Generation Partnership Project (3GPP) long-term evolution (LTE);

3GPP 5G new radio (NR);

dedicated short range communication (DSRC); and

Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

7. The apparatus of claim 6, wherein the second RAT is selected from the group consisting of:

3rd Generation Partnership Project (3GPP) long-term evolution (LTE);

3GPP 5G new radio (NR);

dedicated short range communication (DSRC); and Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

8. The apparatus of claim 1 , wherein the one or more processors are further to:

generate a capabilities message for the second RAT RSU, the capabilities message indicating that the multi-mode UE supports the first RAT in addition to the second RAT.

9. An apparatus, the apparatus comprising:

a memory to store a database of road side unit (RSU) information for a plurality of RSUs, wherein the plurality of RSUs include a first technology RSU that uses a first technology and a second technology RSU that uses a second

technology, wherein the first technology is different than the second technology; and one or more processors to:

decode a first registration message from the first technology RSU; decode a second registration message from the second technology

RSU, the second registration message including a location of the second technology RSU and an internet protocol (IP) address of the second technology RSU;

generate the database of RSU information based at least in part on the first registration message and the second registration message; and

determine a next hop RSU for a vehicle-to-anything (V2X) message from a first technology device based at least in part on a location of the first technology device and the database of RSU information, wherein the next hop RSU is the second technology RSU.

10. The apparatus of claim 9, wherein the one or more processors are further to:

decode the V2X message from the first technology device, wherein the V2X message is forwarded to the apparatus from the first technology RSU; and

forward the V2X message to the second technology RSU using the IP address of the second technology RSU.

1 1 . The apparatus of claim 9, wherein the one or more processors are further to:

decode a query from the first technology RSU for next hops for the V2X message; and generate a response for the first technology RSU, wherein the response includes the IP address of the second technology RSU.

12. The apparatus of any of claims 9-1 1 , wherein the V2X message is a first technology V2X message.

13. The apparatus of any of claims 9-1 1 , wherein the apparatus is selected from the group consisting of:

a mobile edge compute application that is accessible via a mobile edge compute server;

a mobile edge compute server; and

a server that is accessible via the internet.

14. The apparatus of any of claim 9-1 1 , wherein the first technology is selected from the group consisting of:

3rd Generation Partnership Project (3GPP) long-term evolution (LTE);

3GPP 5G new radio (NR);

dedicated short range communication (DSRC); and

Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

15. The apparatus of claim 14, wherein the second technology is selected from the group consisting of:

3rd Generation Partnership Project (3GPP) long-term evolution (LTE);

3GPP 5G new radio (NR);

dedicated short range communication (DSRC); and

Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

16. The apparatus of any of claims 9-1 1 , wherein the first registration message includes a location of the first technology RSU and an internet protocol (IP) address of the first technology RSU.

17. A first radio access technology (RAT) road side unit (RSU) that uses a first RAT, the first RAT RSU comprising:

a memory to store a database of road side unit (RSU) information for a plurality of RSUs, wherein the plurality of RSUs include a second RAT RSU that uses a second RAT, the second RAT being different from the first RAT; and

one or more processors to:

decode a first vehicle-to-anything (V2X) message from a first RAT device, the first V2X message including a location of the first RAT device; determine an RSU from the plurality of RSUs in the database of RSU information that is close to the location of the first RAT device, wherein the RSU is the second RAT RSU; and

forward the V2X message from the first RAT RSU to the second RAT

RSU.

18. The first RAT RSU of claim 17, wherein the database of RSU information includes at least one of an internet protocol (IP) address and a fully qualified domain name (FQDN) of the second RAT RSU, and wherein the V2X message is forwarded to the second RAT RSU using the at least one of the IP address and the FQDN of the second RAT RSU.

19. The first RAT RSU of claim 18, wherein the one or more processors are further to:

decode a message from a multi-mode device that includes the at least one of the IP address and the FQDN of the second RAT RSU;

update the database of RSU information with an entry for the second RAT RSU; and

update the database of RSU information with the at least one of the IP address and the FQDN of the second RAT RSU.

20. The first RAT RSU of claim 19, wherein the one or more processors are further to:

determine an approximate location of the second RAT RSU based at least in part on at least one of a location of the multi-mode device and the IP address of the second RAT RSU; and

update the database of RSU information with the approximate location of the second RAT RSU.

21 . The first RAT RSU of any of claims 17-20, wherein the first RAT is selected from the group consisting of:

3rd Generation Partnership Project (3GPP) long-term evolution (LTE);

3GPP 5G new radio (NR);

dedicated short range communication (DSRC); and

Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .

22. The first RAT RSU of claim 21 , wherein the second RAT is selected from the group consisting of:

3rd Generation Partnership Project (3GPP) long-term evolution (LTE); 3GPP 5G new radio (NR);

dedicated short range communication (DSRC); and

Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 .