Upper layer implementation of unicast for C-V2X

Abstract

Various embodiments provide methods, vehicle computing devices, storage media, and systems for unicast transmission of cellular vehicle-to-everything (C‑V2X) Internet Protocol (IP) packets. Various embodiments may enable upper layers in a stack architecture to implement unicast transmission of C‑V2X IP packets. In various embodiments, a source port and destination IP address pair may be associated with a destination layer 2 (L2) address. In various embodiments, a source port indication and a destination IP address indication may be added to a unicast C‑V2X IP packet, such as a transmission control protocol (TCP) packet, a user datagram protocol (UDP) packet, etc., and the source port and destination IP address indication may be used by a modem to determine a destination L2 address for the unicast C‑V2X IP packet.

Description

[0001] Related Applications

[0002] This application claims the benefit of priority to U.S. Patent Application No. 16 / 887,384, filed on May 29, 2020, entitled “Upper Layers Realization of Unicast for C-V2X,” which is hereby incorporated by reference in its entirety for all purposes. Background Art

[0003] Cellular and wireless communication technologies have experienced explosive growth over the past few years and are being used to support communications between a host of different types of communication devices, such as smartphones, vehicle-based communication devices, infrastructure communication devices, network communication devices, etc. This growth has been fueled by better communication hardware, larger networks, and more reliable protocols.

[0004] The ground transportation industry is increasingly looking to take advantage of the growing capabilities of cellular and wireless communication technologies by adopting Intelligent Transportation System (ITS) technologies to increase intercommunication and safety of both driver-operated and autonomous vehicles. The Cellular Vehicle-to-Everything (C-V2X) protocol defined by the 3rd Generation Partnership Project (3GPP) supports ITS technologies and serves as the basis for vehicles to communicate directly with the communication devices around them. C-V2X communication technology holds promise for improving vehicle safety, managing traffic congestion, and supporting autonomous and semi-autonomous vehicles. Summary of the invention

[0005] Various aspects include methods for providing and receiving unicast transmission of cellular vehicle-to-everything (C-V2X) Internet Protocol (IP) packets. Various aspects may enable upper layers in a stack architecture to implement unicast transmission and reception of C-V2X IP packets. Various aspects may include methods for providing and receiving unicast transmission of C-V2X IP packets performed by a modem of a vehicle.

[0006] Various aspects may include: receiving a unicast C-V2X IP packet, wherein an IP header of the unicast C-V2X IP packet indicates a source port and a destination IP address; determining a destination layer 2 (L2) address based at least in part on the indicated destination IP address; adding a packet data convergence protocol (PDCP) header indicating the determined destination L2 address to the unicast C-V2X IP packet; and transmitting the unicast C-V2X IP packet to the determined destination L2 address.

[0007] Certain aspects may also include: receiving a flow registration that associates one or more source port and destination IP address pairs with corresponding destination L2 addresses; and caching the flow registration in a memory available to the modem. In such aspects, determining the destination L2 address based at least in part on the indicated destination IP address may include comparing the indicated source port and the indicated destination IP address with the cached flow registration to determine a matching source port and destination IP address pair, and determining the destination L2 address as the corresponding destination L2 address associated with the matching source port and destination IP address pair in the cached flow registration. In certain aspects, the flow registration may associate one or more flow attributes with each corresponding destination L2 address. Such aspects may also include determining one or more flow attributes associated with the determined destination L2 address based at least in part on the flow registration. In such aspects, transmitting a unicast C-V2X IP packet to the determined destination L2 address may include transmitting a unicast C-V2X IP packet to the determined destination L2 address according to the determined one or more flow attributes. In such aspects, the one or more flow attributes may include periodicity, a semi-persistent scheduling (SPS) sidelink identifier, priority, a packet delay budget (PDB), or a transmit power.

[0008] Certain aspects may also include: receiving a destination address registration indicating one or more destination IP addresses and corresponding destination L2 address pairs; and storing the one or more destination IP addresses and corresponding destination L2 address pairs in an address mapping table in a memory available to the modem, wherein determining the destination L2 address based at least in part on the indicated destination IP address may include: comparing the indicated destination IP address with the address mapping table to determine a matching destination IP address; and determining the destination L2 address as the corresponding destination L2 address associated with the matching destination IP address in the address mapping table. Such aspects may also include: receiving a flow registration associated with the destination address registration, the flow registration indicating one or more flow attributes to be used for all corresponding destination L2 addresses in the destination address registration; and setting the one or more flow attributes as default flow attributes for the address mapping table. In such aspects, transmitting a unicast C-V2X IP packet to the determined destination L2 address may include transmitting a unicast C-V2X IP packet to the determined destination L2 address according to the default flow attributes set for the address mapping table. In such aspects, the one or more flow attributes may include periodicity, an SPS sidelink identifier, priority, a PDB, or a transmit power.

[0009] In certain aspects, the unicast C-V2X IP packet may be a Transmission Control Protocol (TCP) packet or a User Datagram Protocol (UDP) packet. In certain aspects, the determined destination L2 address may be a Media Access Control (MAC) address of another vehicle.

[0010] Various aspects may include a method for providing unicast transmission of a C-V2X IP packet executed by a processor of a vehicle, comprising: generating a unicast C-V2X IP packet to be transmitted to another device via unicast transmission, wherein an IP header of the unicast C-V2X IP packet indicates a source port and a destination IP address for the other device, and transmitting the unicast C-V2X IP packet to a modem of the vehicle.

[0011] Certain aspects may also include: generating a flow registration that associates one or more source port and destination IP address pairs with corresponding destination L2 addresses before generating a unicast C-V2X IP packet, wherein at least one of the one or more source port and destination IP address pairs associated with the corresponding destination L2 address includes a pair of source port and destination IP addresses for other devices associated with the destination L2 address of other devices; and transmitting the flow registration to the modem of the vehicle. In certain aspects, the flow registration may also associate one or more flow attributes with the destination L2 address of the other device. In such aspects, the one or more flow attributes may include periodicity, SPS side link identifier, priority, PDB, or transmit power. In such aspects, the other device may be another vehicle, and the destination L2 address of the other device may be a media access control (MAC) address of the other vehicle.

[0012] Certain aspects may also include: before generating a unicast C-V2X IP packet, generating a destination address registration indicating one or more destination IP address and corresponding destination L2 address pairs, wherein at least one of the one or more destination IP address and corresponding destination L2 address pairs includes a pairing of a destination IP address for another device and a destination L2 address of the other device, transmitting the destination address registration to a modem of the vehicle, generating a flow registration associated with the destination address registration, the flow registration indicating one or more flow attributes to be used for all destination L2 addresses indicated in the destination address registration, and transmitting the flow registration to the modem of the vehicle. In such aspects, the one or more flow attributes may include periodicity, an SPS side link identifier, priority, PDB, or transmit power. In such aspects, the processor may be an application processor, the other device may be another vehicle, and the destination L2 address of the other device may be a MAC address of the other vehicle. In various aspects, the unicast C-V2X IP packet may be a TCP packet or a UDP packet.

[0013] A further aspect includes a vehicle including a vehicle computing device having a processor configured with processor-executable instructions to perform the operations of any of the methods outlined above. A further aspect includes a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause the processor to perform the operations of any of the methods outlined above. A further aspect includes a computing device for use in a vehicle and configured to perform the operations of any of the methods outlined above. A further aspect includes a vehicle having components for performing the functions of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain features of the claims.

[0015] Figure 1A and 1B is a block diagram illustrating components of a vehicle suitable for implementing various embodiments.

[0016] Figure 1C An example cellular vehicle-to-everything (C-V2X) system suitable for implementing various embodiments is illustrated.

[0017] Figure 2 is a system block diagram illustrating components of a vehicle computing device suitable for implementing various embodiments for communicating with roadside units and other vehicles.

[0018] Figure 3 is a block diagram illustrating components of an example system-on-chip for use in a vehicle that may be configured to broadcast, receive, and / or otherwise use C-V2X messages in accordance with various embodiments.

[0019] Figure 4 is a block diagram illustrating an example of interactions between stack architecture layers in a transmitting communication device and a receiving communication device according to various embodiments.

[0020] Figure 5A and 5B is a process flow diagram illustrating a method for unicast transmission of C-V2X Internet Protocol (IP) packets in accordance with various embodiments.

[0021] Fig. 6A Illustrated are example associations for unicast C-V2X IP packet flows in accordance with various embodiments.

[0022] Figure 6BAn example of adding a Packet Data Convergence Protocol (PDCP) header to a Transmission Control Protocol (TCP) packet according to various embodiments is illustrated.

[0023] Figure 6C An example of adding a PDCP header to a User Datagram Protocol (UDP) packet according to various embodiments is illustrated.

[0024] Fig. 7A and 7B is a process flow diagram illustrating a method for unicast transmission of C-V2X IP packets according to various embodiments.

[0025] Figure 8 is a call flow diagram illustrating example interactions between vehicles transmitting unicast C-V2X IP packets according to various embodiments.

[0026] Fig.9A and 9B is a process flow diagram illustrating a method for unicast transmission of C-V2X IP packets according to various embodiments.

[0027] Fig.10 is a call flow diagram illustrating example interactions between vehicles transmitting unicast C-V2X IP packets according to various embodiments. DETAILED DESCRIPTION

[0028] Various aspects will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0029] Various embodiments provide methods for unicast transmission and reception of cellular vehicle-to-everything (C-V2X) Internet Protocol (IP) packets. Various embodiments may enable upper layers in a stack architecture to implement unicast transmission and reception of C-V2X IP packets. In various embodiments, a source port and destination IP address pair may be associated with a destination layer 2 (L2) address. In various embodiments, a source port indication and a destination IP address indication may be added to a unicast C-V2X IP packet, such as a transmission control protocol (TCP) packet, a user datagram protocol (UDP) packet, etc., and the source port and destination IP address indication may be used by a modem to determine a destination L2 address for the unicast C-V2X IP packet. In various embodiments, the destination L2 address may be indicated by the modem in a packet data convergence protocol (PDCP) header added to a unicast C-V2X IP packet, such as a TCP packet, a UDP packet, etc.

[0030] Various embodiments improve the capabilities and performance of C-V2X communications by enabling unicast IP transmission and reception. The presence of source port and destination IP address indication enables the modem to distinguish different flows with the same source port, thereby successfully adding a PDCP header to a unicast C-V2X IP packet (such as a TCP packet, UDP packet, etc.) with the correct destination L2 address. The ability to distinguish different flows with the same source port using a source port and destination IP address pairing associated with a destination L2 address can enable a vehicle's modem to support multiple unicast vehicle-to-everything (V2X) flows per source port, thereby improving C-V2X communication capabilities.

[0031] As used herein, the term "communication device" refers to any or all of a cellular telephone, a smart phone, a portable computing device, a driver assistance system, a vehicle controller, a vehicle system controller, a vehicle communication system, an infotainment system, a vehicle telematics system or subsystem, a vehicle display system or subsystem, a vehicle data controller or router, and similar electronic devices that include a programmable processor and memory and circuitry configured to perform operations as described herein. While various aspects are particularly useful for in-vehicle communication systems and / or computing devices, these aspects are generally useful in any communication device that includes communication circuitry and a processor that executes an application.

[0032] The term "system on chip" (SOC) is used herein to refer to a collection of interconnected electronic circuits that typically, but not exclusively, include one or more processors, memory, and communication interfaces. SOCs may include various types of processors and processor cores, such as general-purpose processors, central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), accelerated processing units (APUs), subsystem processors, auxiliary processors, single-core processors, and multi-core processors. SOCs may also embody other hardware and hardware combinations, such as field programmable gate arrays (FPGAs), configuration and status registers (CSRs), application-specific integrated circuits (ASICs), other programmable logic devices, discrete gate logic, transistor logic, registers, performance monitoring hardware, watchdog hardware, counters, and time references. SOCs may be integrated circuits (ICs) that are configured so that components of the IC reside on the same substrate, such as a monolithic semiconductor material (e.g., silicon, etc.).

[0033] The term "system-in-package" (SIP) is used herein to refer to a single module or package that may include multiple resources, computing units, cores, and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SOCs that are coupled together via high-speed communication circuits and packaged in close proximity (such as on a single motherboard or in a single mobile communication device). The proximity of SoCs facilitates high-speed communication and the sharing of memory and resources.

[0034] The cellular vehicle-to-everything (C-V2X) protocol defined by the third generation partnership project (3GPP) supports direct communication between two vehicle-to-everything (V2X) entities through a PC5 interface. As used herein, a V2X entity may be any communication device configured to support C-V2X communication (including direct communication according to the C-V2X protocol), such as an on-board communication device, a mobile communication device temporarily placed in a vehicle (e.g., a smart phone, a laptop computer, etc.), a traffic sensor, a communication device used by a pedestrian (e.g., a smart phone, a laptop computer, etc.), etc. Direct communication may be supported by a device-to-device (D2D) link established through a PC5 interface. V2X direct communication through a PC5 interface supported by the C-V2X protocol may include vehicle-to-vehicle (V2V) direct communication, vehicle-to-infrastructure (V2I) direct communication, and / or vehicle-to-pedestrian (V2P) direct communication.

[0035] In C-V2X communications, such as V2X direct communications over a PC5 interface, each V2X entity transmitting or receiving a unicast C-V2X IP packet may be identified by its own corresponding unique layer 2 (L2) address (also referred to as an entity L2 address). As an example, a media access control (MAC) address of each V2X entity may be a destination L2 address for that V2X entity. A C-V2X packet to be transmitted to another V2X entity (such as a unicast C-V2X packet to be transmitted over a PC5 interface) may be accompanied by a PDCP header including a destination L2 address of a V2X entity (e.g., a vehicle, a roadside unit (RSU), etc.), which is the final destination for the C-V2X packet. The destination L2 address, which is a V2X entity (e.g., a vehicle, a roadside unit (RSU), etc.) for the final destination of the C-V2X packet, can enable a modem of a transmitting communication device (such as a modem of a transmitting vehicle) to properly process and transmit the C-V2X packet via a layer 2 sublayer of the modem via C-V2X transmission. The layer 2 sublayer of the modem may include a PDCP layer, a radio link control (RLC) layer, a MAC layer, etc. The C-V2X transmission may include a V2X transmission through a PC5 interface, a wireless wide area network (WWAN) transmission through a Uu interface, etc. Specifically, as part of converting a C-V2X IP packet (such a packet is often referred to as a service data unit (SDU)) passed from a higher data layer (e.g., Layer 3) into one or more packets (such a packet is often referred to as a protocol data unit (PDU)) for transmission via a lower layer (e.g., Layer 1), over the air (such as over a PC5 interface, over a Uu interface, etc.), a destination L2 address of a V2X entity (e.g., a vehicle, a roadside unit (RSU), etc.) as the final destination of the C-V2X IP packet may be written into the one or more PDUs, such as by being indicated in a PDCP header appended to the C-V2X IP packet. The destination L2 address may be recognized by a layer 2 sublayer (e.g., a PDCP layer, an RLC layer, a MAC layer, etc.) in a stack architecture of the V2X entity, and the destination L2 address is used to identify the destination of each packet to be sent.

[0036] In an example C-V2X implementation, a V2X entity (such as a vehicle, etc.) may include an application processor (AP) (e.g., an automotive AP, etc.) connected to a modem. The AP may run various applications and / or stacks residing on a high-level operating system (HLOS) of the AP, such as an intelligent transportation system (ITS) stack, a telemetry application, an application programming interface (API), etc. The AP may be connected to the modem via various physical interconnects (such as a peripheral component interconnect express (PCIe) connection, a universal serial bus (USB) connection, a high-speed inter-chip (HSIC) connection, an Ethernet connection, etc.). The AP and the modem may exchange data with each other via one or more interconnects between the AP and the modem. For example, an application and / or stack running on the AP may transmit C-V2X packets for transmission to other devices (such as other vehicles), such as C-V2X IP packets (e.g., TCP packets, UDP packets, etc.) or C-V2X non-IP packets to the modem via one or more interconnects between the AP and the modem. The modem may transmit C-V2X packets (IP or non-IP) over the air (such as via device-to-device transmission through a PC5 interface, WWAN transmission through a Uu interface, etc.). Similarly, the modem may receive C-V2X packets (IP or non-IP) over the air (such as via device-to-device transmissions over a PC5 interface, WWAN transmissions over a Uu interface, etc.), and may provide C-V2X packets to the AP via one or more interconnections between the AP and the modem.

[0037] For broadcast transmissions, in response to receiving a C-V2X IP packet from a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.), an upper layer (e.g., a PDCP layer) of the modem stack may be configured to identify that the C-V2X IP packet should be given to the broadcast PC5 MAC layer based on a mapping of a source port indicated in an IP header of the C-V2X IP packet to a service identifier (ID) of a destination device mapped to a destination L2 address of the destination device (e.g., a MAC address of the destination device). Although suitable for broadcast transmissions, this source port to service ID to destination L2 address will not work for many unicast transmissions (such as transmission of TCP packets, transmission of UDP packets, etc.) because the same source destination may simultaneously serve different destination points with different destination L2 addresses. Since many unicast transmission protocols (such as TCP, UDP, etc.) provide listening on well-known ports and serve many clients, the same port may be utilized by different clients, and a source port may be associated with several service IDs and / or destination L2 addresses. As an example, the RSU may operate a TCP and / or UDP server using the same source port with different destination L2 addresses for different unicast flows, and different on-board units (OBUs) with different destination L2 addresses may be served by the same source port with different unicast flows.

[0038] In various embodiments, a source port and destination IP address pair may be associated with a destination L2 address, a source port indication and a destination IP address indication may be added to a unicast C-V2X IP packet, such as a Transmission Control Protocol (TCP) packet, a User Datagram Protocol (UDP) packet, etc., and the source port and destination IP address indication may be used by a modem to determine a destination L2 address for the unicast C-V2X IP packet. The presence of the source port and destination IP address indication may enable the modem to distinguish between different flows with the same source port. In various embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may include a source port indication and a destination IP address indication in an IP header of a unicast C-V2X IP packet transmitted to a modem (e.g., an upper layer (e.g., a PDCP layer) of a modem stack). In various embodiments, the modem may determine the destination L2 address based at least in part on the destination IP address indicated in the IP header of the C-V2X packet. The destination L2 address may be indicated by the modem in a PDCP header added to a unicast C-V2X IP packet (such as a TCP packet, a UDP packet, etc.). In this way, the C-V2X IP packet with the added PDCP header indicating the destination L2 address may be a PDCP PDU that is transmitted to a lower layer of the modem stack (e.g., an RLC layer, a MAC layer, a PHY layer, etc.) and transmitted to the destination via an over-the-air unicast transmission.

[0039] In various embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may negotiate a flow registration with a modem (e.g., an upper layer of a modem stack (e.g., a PDCP layer)). The flow registration may define one or more flow attributes to be used for transmission of unicast C-V2X IP packets on the flow, such as periodicity, a semi-persistent scheduling (SPS) sidelink identifier, priority, a packet delay budget (PDB), transmit power, etc. The flow registration may associate one or more source and destination IP address pairs with corresponding destination L2 addresses.

[0040] In some embodiments, the flow registration may be negotiated for each unicast destination. In some embodiments, the modem may cache the flow registration for use in determining a destination L2 address for a received unicast C-V2X IP packet and / or for use in determining flow attributes for a received unicast C-V2X IP packet. In some embodiments, the modem may compare an indicated source port and an indicated destination IP address in a received unicast C-V2X IP packet with the cached flow registration to determine a matching source port and destination IP address pair. In some embodiments, the modem may determine a destination L2 address for a received unicast C-V2X IP packet as a corresponding destination L2 address associated with a matching source port and destination IP address pair in the cached flow registration. In some embodiments, the modem may determine one or more flow attributes associated with the destination L2 address based on the flow registration, and may transmit a unicast C-V2X IP packet to the destination L2 address based on the determined one or more flow attributes.

[0041] In some embodiments, the flow attributes may be applied to all destination L2 addresses associated with the same source port. For example, all flows on the same source port may have the same priority and the same transmit power. The only difference between flows may be the destination L2 address.

[0042] In some embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may negotiate with a modem (e.g., an upper layer (e.g., a PDCP layer) of a modem stack) a single default flow registration for flows to all destination L2 addresses associated with the same source port. In some embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may generate a destination address registration indicating a destination IP address and a destination L2 address pairing and transmit the destination address registration to the modem. The modem may store the destination IP address and the destination L2 address pairing in an address mapping table.

[0043] In some embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may generate a flow registration associated with a destination address registration and transmit the flow registration to the modem. The flow registration may indicate one or more flow attributes to be used for all destination L2 addresses in the destination address registration.

[0044] In some embodiments, the modem may set one or more flow attributes as default flow attributes for the address mapping table. In some embodiments, the modem may compare the indicated destination IP address in the received unicast C-V2X IP packet with the address mapping table to determine a matching destination IP address. The modem may determine the destination L2 address as the corresponding destination L2 address associated with the matching destination IP address in the address mapping table. The modem may transmit the received unicast C-V2X IP packet to the determined destination L2 address according to the default flow attributes set for the address mapping table.

[0045] Various embodiments may be implemented in various vehicles. Figure 1A and 1B An example vehicle 100 is shown in FIG. Figure 1A and 1B , the vehicle 100 may include a vehicle computing device 140 (also referred to as an onboard communication device) and a plurality of sensors 102 - 138 , including a satellite geo-positioning system receiver 108 , occupancy sensors 112 , 116 , 118 , 126 , 128 , tire pressure sensors 114 , 120 , cameras 122 , 136 , microphones 124 , 134 , an impact sensor 130 , a radar 132 , and a lidar 138 .

[0046] A plurality of sensors 102-138 disposed in or on the vehicle may be used for various purposes, such as autonomous and semi-autonomous navigation and control, collision avoidance, location determination, etc., and to provide sensor data about objects and persons in or on the vehicle 100. The sensors 102-138 may include one or more of a variety of sensors capable of detecting a variety of information useful for navigation and collision avoidance. Each of the sensors 102-138 may communicate with the vehicle computing device 140 and with each other by wire or wireless communication. In particular, the sensors may include one or more cameras 122, 136, or other optical sensors or photographic optical sensors. The sensors may also include other types of object detection and ranging sensors, such as radar 132, lidar 138, IR sensors, and ultrasonic sensors. Sensors may also include tire pressure sensors 114, 120, humidity sensors, temperature sensors, satellite geolocation sensors 108, accelerometers, vibration sensors, gyroscopes, gravimeters, impact sensors 130, force gauges, strain gauges, strain sensors, fluid sensors, chemical sensors, gas content analyzers, pH sensors, radiation sensors, Geiger counters, neutron detectors, biomaterial sensors, microphones 124, 134, occupancy sensors 112, 116, 118, 126, 128, proximity sensors, and other sensors.

[0047] The vehicle computing device 140 (sometimes referred to as an on-board unit (OBU)) may be configured with processor-executable instructions to perform various embodiments using information received from various sensors, particularly the cameras 122, 136. In certain embodiments, the vehicle computing device 140 may supplement the processing of camera images using distance and relative positioning (e.g., relative azimuth) obtained from the radar 132 and / or lidar 138 sensors. The vehicle computing device 140 may also be configured to use information about other vehicles determined using various embodiments to control the steering, braking, and speed of the vehicle 100 when operating in an autonomous or semi-autonomous mode.

[0048] Figure 1C An example C-V2X system 150 suitable for implementing various embodiments is illustrated. Figures 1A-1C , the C-V2X system 150 may include an in-vehicle communication device 152 (also referred to as a vehicle computing device) configured to exchange wireless communications with other communication devices around a vehicle 162 in which the in-vehicle communication device 152 is located. The vehicle 162 may be any type of vehicle, such as an autonomous vehicle (e.g., a driverless car, etc.), a semi-autonomous vehicle, a remotely operated vehicle, etc. The in-vehicle communication device 152 may be a computing device installed in the vehicle 162, or may be a mobile communication device (e.g., a smart phone, a laptop, etc.) temporarily placed in the vehicle 162. The C-V2X system 150 may include various devices other than the in-vehicle communication device 152, such as another in-vehicle communication device 153 (also referred to as a vehicle computing device) of another vehicle 164, transmitters 156 and 157 connected to roadside units (RSUs) 158, 159, a communication device 155 (e.g., a smart phone, a laptop, etc.), a cellular tower or base station 163 connected to a network 165 and a network server 166, etc. The various components of the C-V2X system 150 may be configured to operate as an ITS network to support intercommunication and safety for ground vehicles.

[0049] The in-vehicle communication device 152 may be configured to perform vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, and vehicle-to-pedestrian (V2P) communication. For example, the in-vehicle communication device 152 may establish a device-to-device (D2D) link with another in-vehicle communication device 153 of another vehicle 164 to exchange V2V communication. As another example, the in-vehicle communication device 152 may establish a D2D link with transmitters 156 and 157 connected to RSUs 158 and 159 to exchange V2I communication. As another example, the in-vehicle communication device 152 may establish a D2D link with a communication device 155 (such as a smart phone, laptop, etc.) of a user 161 to exchange V2P communication. The D2D link between the in-vehicle communication device 152, the in-vehicle communication device 153, the communication device 155, the RSUs 158 and 159 may be a communication link established independently of a cellular network, such as a link established in a dedicated ITS 5.9 gigahertz (GHz) spectrum. As a specific example, the D2D link may be a dedicated short range communication (DSRC) link, an LTE direct (LTE-D) link, a link established via a PC5 interface, or any other type of link that supports direct device communication.

[0050] The in-vehicle communication device 152 may be configured to perform vehicle-to-network (V2N) communications. For example, the in-vehicle communication device 152 may establish a network-to-device link with a cellular tower or base station 163 connected to a network 165 and other vehicles 164 to exchange V2N communications. The network-to-device link may include, but is not limited to, an uplink (or reverse link), a downlink (or forward link), a bidirectional link, and the like. The network-to-device link may be established based on mobile broadband systems and technologies such as the following: third generation wireless mobile communication technology (3G) (e.g., Global System for Mobile Communications (GSM) Evolution (EDGE) system, Code Division Multiple Access (CDMA) 2000 system, etc.), fourth generation wireless mobile communication technology (4G) (e.g., Long Term Evolution (LTE) system, LTE-Advanced system, Mobile Microwave Access Global Interoperability (Mobile WiMAX) system, etc.), fifth generation wireless mobile communication technology (5G) (e.g., 5G New Radio (5G NR) system, etc.), etc. As a specific example, the network-to-device link may be a WWAN link via a Uu interface.

[0051] In some embodiments, the in-vehicle communication device 152 and the cellular tower or base station 163 may include 5G NR functionality utilizing an orthogonal frequency division multiplexing (OFDM) based air interface. The functionality of the cellular tower or base station 163 may be similar to (or incorporated into) the functionality of a cellular IoT (CIoT) base station (C-BS), a NodeB, an evolved NodeB (eNodeB), a radio access network (RAN) access node, a radio network controller (RNC), a base station (BS), a macro cell, a macro node, a home eNB (HeNB), a femto cell, a femto node, a pico node, or some other suitable entity based on a radio technology for establishing a network-to-device link between the cellular tower or base station 163 and the in-vehicle communication device 152. The cellular tower or base station 163 may communicate with a corresponding router that may be connected to a network 165 (e.g., a core network, the Internet, etc.). Using the connection to the cellular tower or base station 163 , the in-vehicle communication device 152 can exchange data with the network 165 and devices connected to the network 165 , such as other vehicles 164 or any other communication devices connected to the network 165 .

[0052] Figure 2 is a component block diagram illustrating a system 200 suitable for implementing various embodiments of the components and supporting systems. Figure 1A-2 , the system 200 may include a vehicle computing device 140 (and / or 152 , 153 ) in a vehicle 100 , 162 , 164 , 230 configured to communicate with other vehicles and an RSU 220 via wireless communications (e.g., C-V2X protocol messages 222 , such as C-V2X messages transmitted as unicast C-V2X IP packets (e.g., TCP packets, UDP packets, etc.)), and the RSU 220 may communicate with a network server 224 (e.g., via a wireless communication link or a wired communication link 226 ).

[0053] The roadside units 220, network servers 224, and the wired communication links 226 and wireless communication links that connect such units together into an integrated communication and tracking system may include and are generally referred to herein as a ground transportation network 435. The network servers 224 of the ground transportation network 435 may be coupled to a wide area network (e.g., the Internet 228) and configured to route permanent vehicle information to the computing platforms of authorized parties and certificate authorities 430 using any of a variety of known network message transmission protocols.

[0054] The vehicle computing device 140 (and / or 152 , 153 ) may include various circuits and devices for controlling the operation of the vehicle 100 , 162 , 164 , 230 and communicating with other devices within the ground transportation network 200 .

[0055] exist Figure 2 In the example shown, the vehicle computing device 140 (and / or 152, 153) includes a processor 204, a memory 206, an input module 208, an output module 210, and a radio transceiver 212. The vehicle computing device 140 (and / or 152, 153) can be coupled to and configured to control the driving control components 214, the navigation components 216, and one or more sensors 218 of the vehicle 100, 162, 164, 230. The processor 204 can be configured with processor-executable instructions to control the maneuvering, navigation, and / or other operations of the vehicle 100, 162, 164, 230, including the operations of various embodiments. The processor 204 can be coupled to the memory 206. The vehicle computing device 140 (and / or 152, 153) can include an input module 208, an output module 210, and a radio transceiver 212.

[0056] The radio transceiver 212 may be configured to send and receive C-V2X protocol messages (such as C-V2X messages transmitted as unicast C-V2X IP packets (e.g., TCP packets, UDP packets, etc.)) with the RSU 220 and other vehicles 230.

[0057] The input module 208 can receive sensor data from one or more vehicle sensors 218 and electronic signals from other components, including the driving control component 214 and the navigation component 216. The output module 210 can be used to communicate with or activate various components of the vehicle 100, 162, 164, 230, including the driving control component 214, the navigation component 216, and the sensor(s) 218.

[0058] The vehicle computing device 140 (and / or 152, 153) may be coupled to the driving control component 214 to control physical elements of the vehicle 100, 162, 164, 230 related to the handling and navigation of the vehicle, such as the engine, motor, throttle, steering elements, flight control elements, braking or deceleration elements, etc. The driving control component 214 may also include components for controlling other devices of the vehicle, including environmental controls (e.g., air conditioning and heating), exterior and / or interior lighting, interior and / or exterior information displays (which may include display screens or other devices that display information), safety devices (e.g., tactile devices, audible alarms, etc.), and other similar devices.

[0059] The vehicle computing device 140 (and / or 152, 153) can be coupled to the navigation component 216 and can receive data from the navigation component 216 and is configured to use such data to determine the current location and orientation of the vehicle 100, 162, 164, 230, and the appropriate route towards the destination. In various embodiments, the navigation component 216 can include or be coupled to a global navigation satellite system (GNSS) receiver system (e.g., one or more global positioning system (GPS) receivers) to enable the vehicle 100, 162, 164, 230 to determine its current location using GNSS signals. Alternatively or additionally, the navigation component 216 can include a radio navigation receiver for receiving navigation beacons or other signals from radio nodes (such as Wi-Fi access points, cellular network sites, radio stations, remote computing devices, other vehicles, etc.). Through the control of the driving control element 214, the processor 204 can control the vehicle 100, 162, 164, 230 for navigation and maneuvering. The processor 204 and / or the navigation component 216 may be configured to communicate with the roadside unit 230 to receive commands to control maneuvers, receive data useful in navigation, provide real-time location reports, and evaluate other data.

[0060] The vehicle computing device 140 (and / or 152, 153) may be coupled to one or more sensors 218. The sensor(s) 218 ​​may include sensors 102-138 as described, and may be configured to provide various data to the processor 204.

[0061] The processor 204 of the vehicle computing device 140 (and / or 152 , 153 ) may be configured to receive information regarding the vehicle's location and direction of travel (e.g., from the navigation component 216 ), speed (e.g., from the driving control component 214 ), and other information (e.g., from the sensor(s) 218 ​​), and generate C-V2X messages, such as C-V2X messages transmitted as unicast C-V2X IP packets (e.g., TCP packets, UDP packets, etc.), for transmission by the radio transceiver 212 .

[0062] The processor 204 of the vehicle computing device 140 (and / or 152, 153) may be configured to receive C-V2X messages from other vehicles 230, such as C-V2X messages transmitted as unicast C-V2X IP packets (e.g., TCP packets, UDP packets, etc.), and use such messages in controlling vehicle operation (e.g., providing other vehicle positions to the driving control component 214 and / or the navigation component 216). As an example, the processor 204 may also be configured to receive and process other C-V2X messages from the RSU 220 and use information in such messages, and use such information in controlling vehicle operation, notifying an operator of a safety condition, etc.

[0063] Although the vehicle computing device 140 (and / or 152, 153) is described as including separate components, in some embodiments, some or all of the components (e.g., the processor 204, the memory 206, the input module 208, the output module 210, and the radio transceiver 212) may be integrated into a single device or module, such as a system-on-chip (SOC) processing device. Such an SOC processing device may be configured for use in a vehicle and, when installed in the vehicle, is configured, such as having processor-executable instructions executed in the processor 204 to perform the operations of the various embodiments.

[0064] Various embodiments may be implemented on a number of single-processor and multi-processor communication devices (including SoCs and / or SIPs). Figure 3 An example SIP 300 architecture is illustrated that may be configured to implement methods for communicating path history according to various embodiments. Figure 1A-3 The example SIP 300 architecture may be implemented in any SIP and may be used in any communication device (eg, the in-vehicle communication device 140 , the in-vehicle communication device 152 , the in-vehicle communication device 153 , the RSUs 158 , 159 , etc.) implementing the various embodiments.

[0065] exist Figure 3 In the illustrated example, SIP 300 includes three SoCs 302, 304, 371, which include processors, modems, and memories, and can be configured to perform operations of various embodiments. In some embodiments, the first SoC 302 can operate as a central processing unit (CPU) of a communication device, which executes instructions of a software application by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions. In some embodiments, the second SoC 304 can operate as a dedicated processing unit. For example, the second SoC 304 can operate as a dedicated 5G processing unit, which is responsible for managing high-capacity, high-speed (e.g., 5Gbps, etc.) and / or very high frequency short wavelength (e.g., 28GHz mmWave (millimeter wave) spectrum, etc.) communications to support 5G NR functions using an OFDM-based air interface. In some embodiments, the third SoC 371 can operate as a dedicated processing unit. For example, the third SoC 371 can operate as a dedicated C-V2X processing unit, which is responsible for managing V2V, V2I and V2P communications over D2D links (such as D2D links established in dedicated ITS 5.9 GHz spectrum communications). Figure 3The organization of the SoC and functionality illustrated in is a non-limiting example of a SIP, as other architectures and organizations of functionality between SoCs (including fewer or more SoCs) are contemplated. For ease of reference, the term "modem" is used herein and in the claims to refer to an integration of modem circuitry, one or more processors (e.g., a modem processor, a DSP, etc.), and memory, which may be integrated in a SoC (e.g., 304 or 371) and configured with processor-executable instructions (e.g., in firmware and / or software) to perform the operations of the various embodiments.

[0066] exist Figure 3 In the illustrated example, the first SoC 302 includes a digital signal processor (DSP) 310, a modem processor 312, a graphics processor 314, an application processor (AP) 316, one or more coprocessors 318 (e.g., vector coprocessors) connected to one or more of the processors, a memory 320, a custom circuit 322, system components and resources 324, an interconnect / bus module 326, one or more temperature sensors 330, a thermal management unit 332, and a wireless transceiver 366 configured to transmit and receive wireless communications to / from other devices via an antenna (not shown). The second SoC 304 includes a 5G modem processor 352, a power management unit 354, an interconnect / bus module 364, multiple mmWave transceivers 356, a memory 358, and various additional processors 360, such as an application processor, a packet processor, etc. The third SoC 371 includes an ITS modem processor 372, a power management unit 374, an interconnect / bus module 384, multiple transceivers 376 (e.g., transceivers configured to operate in the dedicated ITS 5.9 GHz spectrum), a memory 378, and various additional processors 380, such as an application processor, a packet processor, etc.

[0067] Each processor 310, 312, 314, 316, 318, 352, 360, 372, 380 may include one or more cores, and each processor / core may perform operations independently of other processors / cores. For example, the first SOC 302 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.), and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS10). In addition, any or all of the processors 310, 312, 314, 316, 318, 352, 360, 372, 380 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.). As a specific example, higher layers (e.g., layer 3 applications and / or stacks such as an ITS stack, telemetry applications, APIs, etc.) running on the AP 316, additional processors 360, 380 may perform operations to generate and transmit unicast C-V2X packets to upper layers (e.g., PDCP layer) of the modem processor 312, 352, 372.

[0068] The first, second and third SoCs 302, 304, 371 may include various system components, resources and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other dedicated operations, such as decoding data packets and processing encoded audio and video signals for presentation in a web browser or other display application. For example, the system components and resources 324 of the first SoC 302 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients running on wireless devices. The system components and resources 324 and / or custom circuits 322 may also include circuits for interfacing with peripheral devices (such as cameras, electronic displays, wireless communication devices, external memory chips, autonomous driving systems, traffic sign recognition systems, parking assistance systems, telematics units, tire pressure monitoring systems, collision warning systems, display systems, vehicle buses, etc.).

[0069] The first, second, and third SOCs 302, 304, 371 may communicate via one or more interconnect / bus modules 350. The processors 310, 312, 314, 316, 318 may be interconnected to one or more memory elements 320, system components and resources 324, and custom circuits 322, and thermal management units 332 via interconnect / bus modules 326. Similarly, the processors 352, 360 may be interconnected to a power management unit 354, a mmWave transceiver 356, a memory 358, and various additional processors 360 via interconnect / bus modules 364. Similarly, the processors 372, 380 may be interconnected to a power management unit 374, a transceiver 376, a memory 378, and various additional processors 380 via interconnect / bus modules 384. The interconnect / bus modules 326, 350, 364, 384 may include reconfigurable logic gate arrays and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects such as high-performance networks-on chip (NoC). The various interconnect / bus modules 326, 350, 364, 384 may include physical interconnects such as PCIe connections, USB connections, HSIC connections, Ethernet connections, and the like.

[0070] The first, second and / or third SoC 302, 304, 371 may also include input / output modules (not shown) for communicating with resources external to the SoC. The resources external to the SoC may be shared by two or more of the internal SoC processors / cores.

[0071] In addition to the SIP 300 discussed above, various aspects may be implemented in various communication devices, which may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0072] Figure 4 The interaction between stack architecture layers in a transmitting communication device 410 and a receiving communication device 415 according to various embodiments is illustrated. Figure 1A-4, the communication devices 401, 415 can each be any type of communication device that implements various embodiments (e.g., vehicle communication devices 140, 152, 153, RSU 158, 159, communication device 155, SIP 300, etc.). As a specific example, the communication devices 401, 415 can be communication devices configured to exchange information using C-V2X communication (such as via unicast C-V2X IP transmission, such as TCP transmission, UDP transmission, etc.). In various embodiments, the layers in the stack architecture of the communication device 401 can form a logical connection with the corresponding layers in the stack architecture of the communication device 415. The stack architecture can be distributed between one or more processors (e.g., processors 310, 312, 314, 316, 318, 352, 360, 372, 380). Although described with respect to one radio protocol stack, in a multiple subscriber identity module (SIM) (multi-SIM) communication device, the stack architecture may include multiple protocol stacks, each of which may be associated with a different SIM (e.g., in a dual SIM communication device, two protocol stacks are associated with the two SIMs, respectively). Although described below with reference to LTE communication layers, the stack architecture may support any of a variety of standards and protocols for wireless communication, and / or may include additional protocol stacks that support any of a variety of standards and protocols wireless communication.

[0073] Each communication device 401, 415 may include one or more higher data layers 402 configured to exchange data with a modem stack (or radio protocol stack) 406. As an example, the higher data layer 402 may be one or more ITS layers, one or more service layers, one or more messaging layers, an application layer, etc. As an example, the functions performed in the higher data layer 402 may include applications 403 (e.g., ITS security-critical applications, ITS non-security-critical applications, messaging applications, etc.), security services 404, Internet Protocol (IP) services 405 (e.g., Transmission Control Protocol (TCP) services, Uniform Datagram Protocol (UDP) services, etc.), application programming interface (API) services, other higher data layer functions, or any combination thereof. The higher data layers 402 may be individually or collectively sublayers of layer 3 in the stack architecture.

[0074] In some embodiments, the higher data layers 402 and the modem stack 406 on the communication devices 401, 415 may run on the same processor of the communication devices 401, 415. In some embodiments, the higher data layers 402 and the modem stack 406 on the communication devices 401, 415 may run on different processors of the communication devices 401, 415. As an example, the higher data layers 402 may run on an AP (e.g., AP 316) and the modem stack 406 may run on a modem processor (e.g., modem processor 312, modem processor 352, modem processor 372). Although in Figure 4 401, 415, but in some embodiments the higher data layer 402 may run on a processor of a separate communication device.

[0075] In certain embodiments, the modem stack 406 may include a packet data convergence protocol (PDCP) layer 407, a radio link control (RLC) layer 408, a medium access control (MAC) layer 409, and a physical (PHY) layer 410. The PHY layer 410 may be the lowest layer of the modem stack 406, and the PDCP layer 407 may be the highest layer of the modem stack 406. The PDCP layer 407, the RLC layer 408, and the MAC layer 409 may be sublayers of layer 2 in the stack architecture. The PHY layer 410 may be a sublayer of layer 1 in the stack architecture.

[0076] The PDCP layer 407 may process PDCP packets and may provide multiplexing, compression, encryption, and / or integrity protection between different radio bearers and logical channels for PDCP packets. The PDCP layer 407 may receive packets from the higher data layer 402 and may output packets to the higher data layer 402. The PDCP layer 407 may receive packets from the RLC layer 408 and may output packets to the RLC layer 408. As a specific example, in the uplink, the PDCP layer 407 may provide functions including multiplexing between different radio bearers and logical channels, sequence number addition, handover data processing, integrity protection, encryption, and header compression. In the downlink, the PDCP layer 407 may provide functions including in-sequence delivery of data packets, duplicate data packet detection, integrity verification, decryption, and header decompression.

[0077] The RLC layer 408 can process RLC packets and can provide error correction, concatenation, segmentation, reorganization, reordering, duplicate detection, error detection and / or error recovery for RLC packets. In addition, the RLC layer 408 can buffer RLC packets in a receive buffer to support reordering, waiting for lost RLC packets, etc. The RLC layer 408 can operate in different modes such as acknowledgement mode (AM), unacknowledgement mode (UM), and transparent mode (TM). The RLC layer 408 can receive packets from the PDCP layer 407 and can output packets to the PDCP layer 407. The RLC layer 408 can receive packets from the MAC layer 409 and can output packets to the MAC layer 409. As a specific example, in the uplink, the RLC layer 408 can provide segmentation and concatenation of upper layer data packets, retransmission of lost data packets, and automatic repeat request (ARQ). In the downlink, the RLC layer 408 functions may include reordering of data packets to compensate for out-of-order reception, reorganization of upper layer data packets, and ARQ.

[0078] The MAC layer 409 may process MAC packets and may provide frame delimitation / identification, addressing and / or error protection for MAC packets. In addition, the MAC layer may be responsible for hybrid automatic repeat request (HARQ) operations. The MAC layer 409 may receive packets from the RLC layer 408 and may output packets to the RLC layer 408. The MAC layer 409 may receive packets from the PHY layer 410 and may output packets to the PHY layer 410. As a specific example, in the uplink, the MAC layer 409 may provide functions including multiplexing between logical channels and transport channels, random access procedures, logical channel priorities, and hybrid ARQ (HARQ) operations. In the downlink, the MAC layer 409 functions may include channel mapping, demultiplexing, discontinuous reception (DRX), and HARQ operations within a cell.

[0079] The PHY layer 410 may process PHY packets and may provide a communication interface between the hardware supporting the physical transmission medium (e.g., transceivers, antennas, etc.) and the higher layers of the modem stack 406. The PHY layer 410 may convert PHY packets into a bit stream for transmission and / or convert a received bit stream into a PHY packet. The PHY layer 410 provides encoding, transmission, reception, and / or decoding for PHY packets. The PHY layer 410 may receive packets from the MAC layer 409 and may output packets to the MAC layer 409.

[0080] Packets delivered to / from a higher data layer of the modem stack 406 may be referred to as a service data unit (SDU) in a given layer, and packets delivered to / from a lower layer of the modem stack 406 may be referred to as a protocol data unit (PDU). For example, packets received from the PDCP layer 407 into the RLC layer 408 and packets delivered from the RLC layer 408 to the PDCP layer 407 may be referred to as RLC SDUs. Similarly, packets received from the MAC layer 409 into the RLC layer 408 and packets delivered from the RLC layer 408 to the MAC layer 409 may be referred to as RLC PDUs.

[0081] The SDU of a layer may be the PDU of the next higher layer, just as the PDU of a layer may be the SDU of the next lower layer. For example, a PDCP PDU transmitted from the PDCP layer 407 to the RLC layer 408 may be referred to as an RLC SDU when received by the RLC layer 408. Similarly, a MAC SDU transmitted from the MAC layer 409 to the RLC layer 408 may be referred to as an RLC PDU when received by the RLC layer 408.

[0082] The layers within the protocol stack can convert PDUs to SDUs and SDUs to PDUs by performing various operations assigned to the layer on the packets. For example, an RLC SDU can be segmented by the RLC layer 408 to encompass the RLC SDU into one or more RLC PDUs. Similarly, multiple received RLC PDUs can be reordered and reorganized to convert multiple received RLC PDUs into RLC SDUs. In addition, the layer can add data to the packet to convert the SDU into a PDU, or the layer can remove data from the packet to convert the PDU into an SDU. For example, the RLC layer 408 can add a packet header / footer to the RLC SDU to convert the RLC SDU into an RLC PDU. Similarly, the RLC layer 408 can remove a packet header / footer from the RLC PDU to convert the RLC PDU into an RLC SDU.

[0083] refer to Figure 4 , the following is an example of packet processing when one communication device 401 sends a communication that is received by another communication device 415.

[0084] An application of a higher data layer 402 of a sending communication device 401 may generate packets of a message 420 for transmission to an application 403 of a receiving communication device. For example, the packets of the message 420 may be unicast C-V2X IP packets, such as TCP packets, UDP packets, etc. The packets of the message 420 may be transmitted from the higher data layer 401 to the PDCP layer 407 of the modem stack 406 on the sending communication device 401. In various embodiments, when the packets of the message 420 may be unicast C-V2X IP packets (such as TCP packets, UDP packets, etc.), the higher data layer 402 may indicate the source port and destination IP address of the receiving communication device in the IP header of the unicast C-V2X IP packet.

[0085] The PDCP layer 407 may receive the packet of the message 420 as a PDCP SDU and convert the PDCP SDU into a PDCP PDU 421. The PDCP layer 407 may deliver the PDCP PDU 421 to the lower RLC layer 408. The PDCP layer 407 may determine the destination L2 address of the receiving communication device. The PDCP layer 407 may add the destination L2 address to the PDCP header added to the PDCP SDU to convert the PDCP SDU into the PDCP PDU 421.

[0086] The RLC layer 408 may receive the PDCP PDU 421 as an RLC SDU and may convert the RLC SDU (i.e., the PDCP PDU 421) into one or more RLC PDUs 422 by, for example, adding an RLC packet header / footer and / or applying segmentation. As an example, when the RLC SDU (i.e., the PDCP PDU 421) is larger than the maximum RLC PDU size, it may be necessary to split the RLC SDU into segments of multiple RLC PDUs 422. When segmentation is applied to convert the RLC SDU into multiple RLC PDUs 422, each created RLC PDU 422 may be associated with a single RLC SDU (i.e., a single PDCP PDU 421). In addition, the RLC layer 408 may add a sequence number to the one or more RLC PDUs 422. The sequence number may indicate the ordering of the one or more RLC PDUs 422. The RLC layer 408 may deliver the one or more RLC PDUs 422 to the lower MAC layer 409.

[0087] The MAC layer 409 may receive one or more RLC PDUs 422 as one or more MAC SDUs. The MAC layer 409 may convert one or more MAC SDUs (i.e., one or more RLC PDUs 422) into one or more MAC PDUs 424. For example, the MAC layer 409 may convert one or more MAC SDUs (i.e., one or more RLC PDUs 422) by adding a HARQ indicator to the MAC SDUs (i.e., one or more RLC PDUs 422) to support HARQ operations. The MAC layer 409 may pass one or more MAC PDUs 424 to the lower PHY layer 410.

[0088] The PHY layer 410 may receive one or more MAC PDUs as one or more PHY SDUs. The PHY layer 410 may convert one or more PHY SDUs (i.e., one or more MAC PDUs 424) into a PHY PDU bit stream for transmission to the receiving communication device 415 as a stream 426. The stream 426 between the communication devices 401, 415 may exist as part of a direct communication through a PC5 interface, a WWAN transmission through Uu, etc. In various embodiments, the stream 426 between the communication devices 401, 415 may be a unicast stream.

[0089] The PHY layer 410 of the receiving communication device 415 may receive the PHY PDU bit stream 426 and convert the PHY PDU bit stream 426 into one or more PHY SDUs 428. The PHY layer 410 may pass the one or more PHY SDUs 428 to the higher MAC layer 409.

[0090] The MAC layer 409 may receive one or more PHY SDUs 428 as one or more MAC PDUs. The MAC layer 409 may convert one or more MAC PDUs (i.e., one or more PHY SDUs 428) into one or more MAC SDUs 430. In addition, the MAC layer 409 may perform HARQ operations (e.g., acknowledgment, retransmission request, etc.) and remove HARQ data from the MAC PDUs. The MAC layer 409 may pass one or more MAC SDUs 430 to the higher RLC layer 408.

[0091] The RLC layer 408 may receive one or more MAC SDUs 430 as one or more RLC PDUs. The RLC layer 408 may convert one or more RLC PDUs (i.e., one or more MAC SDUs 430) into a single RLC SDU 432. For example, converting one or more RLC PDUs (i.e., one or more MAC SDUs 430) into a single RLC SDU 432 may include removing any RLC headers, removing any RLC footers, combining / concatenating multiple RLC PDUs associated with the same RLC SDU, and reordering the RLC PDUs as needed. In addition, the RLC layer 408 may buffer one or more RLC PDUs in a receive buffer to support reordering, waiting for lost RLC PDUs, etc. The RLC layer 408 may pass the RLC SDU 432 to the higher PDCP layer 407.

[0092] The PDCP layer 407 may receive the RLC SDU 432 as a PDCP PDU and convert the PDCP PDU (i.e., the RLC SDU 432) into a PDCP SDU 434. The PDCP SDU 434 at the receiving communication device 415 may correspond to a packet of the message 420 initiated by the sending communication device 401. The PDCP layer 407 may deliver the PDCP SDU 434 to the higher data layer 402 and the application 403.

[0093] Figure 5A and 5B is a process flow diagram illustrating a method for unicast transmission of C-V2X IP packets according to various embodiments. Figure 5A and 5B The operations of the methods shown in are intended to be illustrative. In some embodiments, these methods may be performed with one or more additional operations not described and / or without one or more of the operations discussed. Figure 5A and 5B The order in which the operations of the methods are shown and described is not intended to be limiting.

[0094] In some embodiments, the exemplary methods shown in 5A and 5B may be implemented in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information). One or more processing devices may include processors that execute in response to instructions electronically stored on an electronic storage medium. Figure 5A and 5BOne or more devices that perform some or all of the operations of the method illustrated in the embodiment. One or more processing devices may include hardware, firmware and / or software configured to be specifically designed to perform the operations of the method illustrated in the embodiment. Figure 5A and 5B One or more devices of one or more of the operations of the method illustrated in the figure. For example, referring to Figures 1A-5B , Figure 5A and 5B The operations of the method shown in the method 500 may be performed by one or more processors of the communication devices implementing various embodiments (e.g., the vehicle communication devices 140, 152, 153, the RSU 158, 159, the communication device 155, the SIP 300, the communication devices 401, 415, etc.). As a specific example, the method 500 ( Figure 5A ) operations may be performed by an AP (eg, AP 316) of the vehicle operating a higher data layer (eg, 402), and method 550 ( Figure 5B ) operations may be performed by a modem (eg, modem processor 312, modem processor 352, modem processor 372) of the vehicle running a modem stack (eg, 406). Figure 5A and 5B The method shown in is discussed with reference to the example of an AP and a modem, but the AP and modem are merely one example implementation and are not intended to limit the scope of the various embodiments.

[0095] refer to Figure 5A In the method 500 shown in FIG. 5 , in block 502, a processor of a vehicle (e.g., an AP processor (e.g., AP 316)) may perform operations to generate a unicast C-V2X IP packet to be transmitted to another device via unicast transmission, wherein an IP header of the unicast C-V2X packet indicates a source port and a destination IP address. As an example, the unicast C-V2X IP packet may be a TCP packet. As another example, the unicast C-V2X IP packet may be a UDP packet. The source port and the destination IP address may be the source port and the destination IP address of the other device that is the destination of the unicast C-V2X packet.

[0096] In block 504, the processor may perform operations to transmit a unicast C-V2X IP packet to a modem of the vehicle. For example, the processor may transmit the unicast C-V2X IP packet to the modem via a physical interconnect / bus.

[0097] refer to Figure 5BIn block 552 of method 550, a modem (e.g., modem processor 312, modem processor 352, modem processor 372) may perform an operation of receiving a unicast C-V2X IP packet, wherein an IP header of the unicast C-V2X IP packet indicates a source port and a destination IP address. As an example, the unicast C-V2X IP packet may be a TCP packet. As another example, the unicast C-V2X IP packet may be a UDP packet. The source port and the destination IP address may be a source port and a destination IP address of another device that is a destination of the unicast C-V2X packet.

[0098] In block 554, the modem may perform an operation to determine a destination L2 address based at least in part on the indicated destination IP address. For example, the destination L2 address may be a MAC address of another device that is the destination of the unicast C-V2X packet. In some embodiments, a source port and destination IP address pair may be associated with the destination L2 address. In some embodiments, as part of a flow negotiation operation, an association between a source port and a destination IP address for a corresponding destination L2 address may be indicated to the modem. For example, as part of a flow negotiation with the modem, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may indicate an association between a source port and a destination IP address for a corresponding destination L2 address. The modem may store an association between a source port and a destination IP address for a corresponding destination L2 address. For example, the modem may cache the association for each flow, and / or may store an address mapping table that associates a destination IP address with a destination L2 address. In some embodiments, the modem can determine the destination address based at least in part on the indicated destination IP address by matching the indicated destination IP address and / or the indicated destination IP address and the indicated source port with a stored destination IP address and / or a stored destination IP address and source port associated with the destination L2 address.

[0099] In block 556, the modem may perform an operation of adding a PDCP header indicating the determined destination L2 address to the unicast C-V2X IP packet. For example, the modem may prepend a PDCP header including an indication of the determined destination L2 address to the unicast C-V2X IP packet. Adding the PDCP header to the unicast C-V2X IP packet (alone or in combination with other operations) may convert the unicast C-V2X IP packet into a PDCP packet.

[0100] In block 558, the modem may perform an operation of transmitting a unicast C-V2X IP packet to the determined destination L2 address. For example, the unicast C-V2X IP packet with an added PDCP header indicating the destination L2 address may be transmitted to a lower layer of the modem stack (e.g., RLC layer, MAC layer, PHY layer, etc.) and transmitted to the destination (e.g., other device) via an over-the-air unicast transmission (e.g., unicast transmission via a PC5 interface, a Uu interface, etc.).

[0101] Fig. 6A FIGURES illustrate example associations for unicast C-V2X IP packet flows according to various embodiments. Figure 1A-6A , Fig. 6A It is illustrated that in various embodiments, a source port and destination IP address pair 602 can be associated with a destination L2 address 603 (e.g., a MAC address). The destination L2 address 603 can be associated with a flow instance 604 (e.g., a PC5 flow instance) for the destination L2 address, which can include one or more flow attributes for the PC5 flow, such as periodicity, SPS side link identifier, priority, PDB, transmit power, etc. In various embodiments, the association between the source port and destination IP address pair 602, the destination L2 address 603, and the flow instance 604 can be determined by a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) and indicated to the modem (e.g., an upper layer of the modem stack (e.g., a PDCP layer)) in a flow registration and / or a destination address registration.

[0102] Figure 6B An example of adding a PDCP header 626 to a TCP packet 620 is illustrated in accordance with various embodiments. Figure 1A-6B , TCP packet 620 may be configured according to method 500 ( Figure 5A ) operation. TCP packet 620 may be an example of a unicast C-V2X IP packet. TCP packet 620 may include an IP header 621, a TCP header 622, and a V2X payload 623. IP header 621 may include an indication of a source port for the destination of TCP packet 620. For example, the source port indication may be as follows: Figure 6B The IP header 621 may include an indication of the destination IP address for the destination of the TCP packet 620. For example, the destination IP address indication may be as follows: Figure 6B, where addr1 is the IP address of the destination. The TCP packet 620 may be received by the modem, and the PDCP header 626 may be added, thereby converting the TCP packet 620 into a PDCP packet 625. For example, the modem may perform method 550 ( Figure 5B ) to add a PDCP header 626. The PDCP header 626 may include a destination L2 address (e.g., a MAC address) of the destination of the TCP packet 620. For example, the destination L2 address indication may be as follows: Figure 6B ”dest (destination) L2 addrs1” indicated in , where addrs1 is the destination L2 address.

[0103] Figure 6C An example of adding a PDCP header 636 to a UDP packet 630 is illustrated according to various embodiments. Figure 1A-6C UDP packet 630 may be transmitted according to method 500 ( Figure 5A ) operation. UDP packet 630 may be an example of a unicast C-V2X IP packet. UDP packet 630 may include an IP header 631, a UDP header 632, and a V2X payload 633. IP header 631 may include an indication of a source port for the destination of UDP packet 630. For example, the source port indication may be as follows: Figure 6C The IP header 631 may include an indication of the destination IP address for the destination of the UDP packet 630. For example, the destination IP address indication may be as follows: Figure 6C The destination IP=addr2 is indicated in the table, where addr2 is the destination IP address. Figure 6B TCP packets 620 and Figure 6C As can be seen from UDP packet 630, two different unicast C-V2X packets may have the same source port (e.g., source port 123) but may have different destination IP addresses (e.g., addr1 and addr2).

[0104] The UDP packet 630 may be received by the modem and the PDCP header 636 may be added, thereby converting the UDP packet 630 into a PDCP packet 635. For example, the modem may perform method 550 ( Figure 5B ) to add a PDCP header 636. The PDCP header 636 may include a destination L2 address (e.g., a MAC address) of the destination of the UDP packet 630. For example, the destination L2 address indication may be as follows: Figure 6CThe destination L2 addrs2 is indicated in , where addrs2 is the destination L2 address. By comparing Figure 6B TCP packets 620 and Figure 6C It can be seen from the UDP packet 630 that, although the source port may be the same (e.g., source port 123), different destination IP addresses (e.g., addr1 and addr2) may enable different PDCP packets 625 and 635 to be addressed to different destination L2 addresses (e.g., addrs1 and addrs2).

[0105] Fig. 7A and 7B is a process flow diagram illustrating a method for unicast transmission of C-V2X IP packets according to various embodiments. Fig. 7A and 7B The operation of the method shown in 7A and 7B is intended to be illustrative. In certain embodiments, these methods can be completed with one or more additional operations not described and / or without one or more of the operations discussed. In addition, the order of operations of the method as shown and described in 7A and 7B is not intended to be limited.

[0106] In some embodiments, the methods shown in 7A and 7B may be implemented in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information). One or more processing devices may include executing in response to instructions stored electronically on an electronic storage medium. Fig. 7A and 7B One or more devices that perform some or all of the operations of the method illustrated in the embodiment. One or more processing devices may include hardware, firmware and / or software configured to be specifically designed to perform Fig. 7A and 7B One or more devices of one or more of the operations of the method illustrated in the figure. For example, referring to Figure 1A-7B , Fig. 7A and 7B The operations of the method shown in the method 700 can be performed by one or more processors of the communication devices implementing various embodiments (e.g., the vehicle communication devices 140, 152, 153, the RSU 158, 159, the communication device 155, the SIP 300, the communication devices 401, 415, etc.). As a specific example, the method 700 ( Fig. 7A ) operations may be performed by an AP (eg, AP 316) of the vehicle operating a higher data layer (eg, 402), and method 750 ( Figure 7B) operations may be performed by a modem (eg, modem processor 312, modem processor 352, modem processor 372) of the vehicle running a modem stack (eg, 406). Fig. 7A and 7B The method shown in is discussed with reference to an example of an AP and a modem, but the AP and the modem are merely an example implementation and are not intended to limit the scope of the various embodiments. In some embodiments, the method 700 ( Fig. 7A ) and / or 750( Figure 7B ) can be combined with the method 500 ( Figure 5A ) and / or 550( Figure 5B ) operations are performed. For example, in various embodiments, method 750 ( Figure 7B ) operations may be performed at least in part to determine a destination L2 address based at least in part on the indicated destination IP address.

[0107] refer to Fig. 7A In block 702 of method 700, a processor of the vehicle (e.g., an AP processor (e.g., AP 316)) may perform an operation of generating a flow registration that associates one or more source port and destination IP address pairs with corresponding destination L2 addresses. In various embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may negotiate a flow registration with a modem (e.g., an upper layer of a modem stack (e.g., a PDCP layer)). The flow registration may define one or more flow attributes to be used for transmission of unicast C-V2X IP packets on the flow, such as periodicity, an SPS side link identifier, priority, PDB, transmit power, etc. The flow registration may associate one or more source and destination IP address pairs with corresponding destination L2 addresses. In some embodiments, the flow registration may be negotiated for each unicast destination.

[0108] In block 704, the processor may perform an operation of transmitting a stream registration to a modem of the vehicle. For example, the processor may transmit the stream registration via a physical interconnect / bus to the modem.

[0109] In some embodiments, in response to the transport stream registration, the processor may execute method 500 ( Figure 5A ) to generate a unicast C-V2X IP packet to be transmitted to another device via a unicast transmission.

[0110] refer to Figure 7BIn block 752 of method 750, a modem (e.g., modem processor 312, modem processor 352, modem processor 372) may perform an operation of receiving a flow registration that associates one or more source port and destination IP address pairs with corresponding destination L2 addresses. For example, the modem may receive the flow registration via a physical interconnect / bus to a processor (e.g., AP processor 316).

[0111] In block 754, the modem may perform an operation of caching the flow registration in a memory available to the modem. In various embodiments, the modem may cache the flow registration for use in determining a destination L2 address for received unicast C-V2X IP packets and / or for use in determining flow attributes for received unicast C-V2X IP packets.

[0112] In block 552, the modem may perform the method described in reference method 550 ( Figure 5B ) to receive a unicast C-V2X IP packet, wherein an IP header of the unicast C-V2X IP packet indicates a source port and a destination IP address.

[0113] In block 756, the modem may perform an operation of comparing the indicated source port and the indicated destination IP address to the cached flow registration to determine a matching source port and destination IP address pair. For example, the modem may parse the cached flow registration and compare the source port and destination IP address pair in the flow registration to the indicated source port and the indicated destination IP address to determine a matching source port and destination IP address pair.

[0114] In block 758, the modem may perform an operation of determining the destination L2 address as the corresponding destination L2 address associated with the matching source port and destination IP address pair in the cached flow registration. In certain embodiments, since each cached flow registration includes a corresponding destination L2 address associated with the source port and destination IP address pair, a match between the source port and destination IP address pair in the cached flow registration and the indicated source port and indicated destination IP address in the IP header of the unicast C-V2X IP packet may indicate that the corresponding destination L2 address of the matching source port and destination IP address pair is the destination L2 address for the destination of the unicast C-V2X IP packet.

[0115] In block 556, the modem may perform the method described in reference method 550 ( Figure 5B ) to add a PDCP header indicating the determined destination L2 address to a unicast C-V2X IP packet.

[0116] In block 760, the modem may perform an operation of determining one or more flow attributes associated with the determined destination L2 address based at least in part on the flow registration. The cached flow registration may define one or more flow attributes to be used for transmission of unicast C-V2X IP packets on the flow, such as periodicity, SPS side link identifier, priority, PDB, transmit power, etc.

[0117] In block 762, the modem may perform operations for transmitting a unicast C-V2X IP packet to the determined destination L2 address in accordance with the determined one or more flow attributes. For example, the unicast C-V2X IP packet may be transmitted using a periodicity, an SPS sidelink identifier, a priority, a PDB, and / or a transmit power indicated in the flow attributes for the flow associated with the determined destination L2 address.

[0118] Figure 8 is a call flow diagram illustrating example interactions between vehicles (such as vehicle 1, vehicle 2, and vehicle 3) transmitting unicast C-V2X IP packets (such as UDP packets, TCP packets, etc.) according to various embodiments. Figure 1A-8 , Figure 8 The call flow diagram of illustrates that vehicle 1 transmits unicast C-V2X IP packets to vehicle 2 and vehicle 3. Figure 8 , but the UDP packet is only one example of a unicast C-V2X IP packet and may be replaced by other types of unicast C-V2X IP packets (such as TCP packets). Vehicles 1, 2, and 3 may be specific examples of communication devices (e.g., on-board communication devices 140, 152, 153, RSUs 158, 159, communication devices 155, SIP 300, communication devices 401, 415, etc.) implementing various embodiments. Figure 8 As shown, vehicle 1 may include an AP 802 (e.g., AP 316) connected to a modem 803 (e.g., modem 312, 352, 372) via a physical interconnect or bus 800 (e.g., 326, 350, 364, 384). As an example, Figure 8 The interaction shown in FIG. 5 may be performed by AP 802 and / or modem 803 according to method 500 ( Figure 5A )、550( Figure 5B )、700( Fig. 7A ) and / or 750( Figure 7B ) to perform one or more operations.

[0119] Vehicle 1 may have its own corresponding IP address (e.g., addr1) and destination L2 address (e.g., addrs1), such as a MAC address. Vehicle 2 may have its own corresponding IP address (e.g., addr2) and destination L2 address (e.g., addrs2), such as a MAC address. Vehicle 3 may have its own corresponding IP address (e.g., addr3) and destination L2 address (e.g., addrs3), such as a MAC address.

[0120] In operation 850, the modem 803 and AP 802 of vehicle 1 may establish an IP and non-IP V2X virtual packet data network (PDN). In operation 852, the AP 802 of vehicle 1 may perform a unicast address discovery operation to identify the IP addresses and destination L2 addresses of vehicles 2 and 3.

[0121] In operation 854, the AP 802 of vehicle 1 may generate and transmit a flow registration for a first flow for unicast transmission to vehicle 2. The flow registration for unicast transmission to vehicle 2 may indicate the source port 200, IP address addr2, destination L2 address addrs2, and flow attributes to be used for the unicast flow for the unicast transmission to vehicle 2. The indication of the source port 200, IP address addr2, destination L2 address addrs2, and flow attributes in the same flow registration may indicate to the modem 803 that the source port 200 and IP address addr2 pairing are associated with the destination L2 address (addrs2) of vehicle 2. In operation 856, the modem 803 may receive the flow registration and cache the flow registration.

[0122] In operation 858, AP 802 may transmit a unicast C-V2X packet destined for vehicle 2 to modem 803. The unicast C-V2X packet destined for vehicle 2 may indicate a source port 200 and a destination IP address addr2 in an IP header. Modem 803 may receive the unicast C-V2X packet and may determine, based on the cached flow registration, in operation 860 that a destination L2 address of vehicle 2 is associated with a source port 200 and a destination IP address addr2 pair in the unicast C-V2X packet. Modem 803 may add a PDCP header indicating a destination L2 address of vehicle 2 to the unicast C-V2X packet and transmit the unicast C-V2X packet to vehicle 2.

[0123] In operation 862, AP 802 of vehicle 1 may generate and transmit a flow registration for a second flow for unicast transmission to vehicle 3. The flow registration for unicast transmission to vehicle 3 may indicate the source port 200, IP address addr3, destination L2 address addrs3, and flow attributes to be used for the unicast flow for the unicast transmission to vehicle 3. The indication of source port 200, IP address addr3, destination L2 address addrs3, and flow attributes in the same flow registration may indicate to modem 803 that the source port 200 and IP address addr3 pairing is associated with the destination L2 address (addrs3) of vehicle 3. In operation 864, modem 803 may receive the flow registration and cache the flow registration. Figure 8 As shown, the cached flow registrations may include a flow registration for a first flow to vehicle 2 and a flow registration for a second flow to vehicle 3. The cached flow registrations may enable the modem 803 to differentiate the destinations (e.g., vehicle 2 versus vehicle 3) for unicast C-V2X IP packets.

[0124] In operation 866, the AP 802 may transmit a unicast C-V2X packet destined for the vehicle 3 to the modem 803. The unicast C-V2X packet destined for the vehicle 3 may indicate a source port 200 and a destination IP address addr3 in an IP header. The modem 803 may receive the unicast C-V2X packet and may determine, based on the cached flow registration, that the destination L2 address of the vehicle 3 is associated with the source port 200 and the destination IP address addr3 pair in the unicast C-V2X packet in operation 868. The modem 803 may add a PDCP header indicating the destination L2 address of the vehicle 3 to the unicast C-V2X packet and transmit the unicast C-V2X packet to the vehicle 3.

[0125] Fig.9A and 9B is a process flow diagram illustrating a method for unicast transmission of C-V2X IP packets according to various embodiments. Fig.9A and 9B The operations of the methods illustrated in 9A and 9B are intended to be illustrative. In certain embodiments, the methods may be performed with one or more additional operations not described and / or without one or more of the operations discussed. Additionally, the order in which the operations of the methods as shown and described in 9A and 9B are not intended to be limiting.

[0126] In some embodiments, the methods shown in 9A and 9B may be implemented in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information). One or more processing devices may include executing in response to instructions stored electronically on an electronic storage medium. Fig.9A and 9B One or more devices that perform some or all of the operations of the method illustrated in the embodiment. One or more processing devices may include hardware, firmware and / or software configured to be specifically designed to perform the operations of the method illustrated in the embodiment. Fig.9A and 9B One or more devices of one or more of the operations of the method illustrated in the figure. For example, referring to Figure 1A-9B , Fig.9A and 9B The operations of the method shown in the method 900 can be performed by one or more processors of the communication devices implementing various embodiments (e.g., the vehicle communication devices 140, 152, 153, the RSU 158, 159, the communication device 155, the SIP 300, the communication devices 401, 415, etc.). As a specific example, the method 900 ( Fig.9A ) operations may be performed by an AP (eg, AP 316) of the vehicle operating a higher data layer (eg, 402), and method 950 ( Fig. 9B ) operations may be performed by a modem (eg, modem processor 312, modem processor 352, modem processor 372) of the vehicle running a modem stack (eg, 406). Fig.9A and 9B The method shown in is discussed with reference to an example of an AP and a modem, but the AP and the modem are merely an example implementation and are not intended to limit the scope of the various embodiments. In some embodiments, the method 900 ( Fig.9A ) and / or 950( Fig. 9B ) can be combined with the method 500 ( Figure 5A ) and / or 550( Figure 5B ) operations are performed. For example, in various embodiments, method 950 ( Fig. 9B ) operations may be performed at least in part to determine a destination L2 address based at least in part on the indicated destination IP address.

[0127] refer to Fig.9AIn block 902 of method 900, a processor of the vehicle (e.g., an AP processor (e.g., AP 316)) may perform an operation of generating a destination address registration indicating a pairing of one or more destination IP addresses and corresponding destination L2 addresses. In some embodiments, flow attributes may be applied to all destination L2 addresses associated with the same source port. For example, all flows on the same source port may have the same priority and the same transmit power. The only difference between flows may be the destination L2 address. In some embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may generate a destination address registration indicating a pairing of a destination IP address and a destination L2 address. For example, a destination address registration may indicate all destination IP addresses discovered during a unicast address discovery operation that are paired with their corresponding destination L2 addresses.

[0128] In block 904, the processor may perform operations to transmit a destination address registration to a modem of the vehicle. For example, the processor may transmit the destination address registration via a physical interconnect / bus to the modem.

[0129] In block 906, the processor may perform an operation of generating a flow registration associated with a destination address registration, the flow registration indicating one or more flow attributes to be used for all destination L2 addresses indicated in the destination address registration. In some embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may negotiate with a modem (e.g., an upper layer of a modem stack (e.g., a PDCP layer)) a single default flow registration for flows to all destination L2 addresses associated with the same source port. In some embodiments, a higher layer (e.g., a layer 3 application and / or stack, such as an ITS stack, a telemetry application, an API, etc.) may generate a flow registration associated with a destination address registration. The flow registration may indicate one or more flow attributes to be used for all destination L2 addresses in the destination address registration.

[0130] In block 704, the processor may execute the method as described in reference method 700 ( Fig. 7A ) to register a transport stream with the modem of the vehicle. In certain embodiments, in response to the transport stream registration, the processor may perform method 500 ( Figure 5A ) to generate a unicast C-V2X IP packet to be transmitted to another device via a unicast transmission.

[0131] refer to Fig. 9BIn block 952 of method 950, a modem (e.g., modem processor 312, modem processor 352, modem processor 372) may perform an operation of receiving a destination address registration indicating pairing of one or more destination IP addresses and corresponding destination L2 addresses. In various embodiments, the destination address registration may indicate pairing of all destination L2 addresses and their corresponding destination IP addresses for all destinations discovered during the unicast address discovery operation.

[0132] In block 954, the modem may perform an operation to store one or more destination IP address and corresponding destination L2 address pairs in an address mapping table in a memory available to the modem. The address mapping table may be a table stored in a memory location available to the modem that relates a destination IP address to its corresponding destination L2 address for each destination discovered during the unicast address discovery operation.

[0133] In block 956, the modem may perform an operation of receiving a flow registration associated with a destination address registration, the flow registration indicating one or more flow attributes to be used for all corresponding destination L2 addresses in the destination address registration. In various embodiments, the flow registration may be associated with a destination indicated in a destination address registration and / or an address mapping table.

[0134] In block 958, the modem may perform an operation of setting one or more flow attributes as default flow attributes for the address mapping table. For example, the modem may set the flow attributes in the flow registration as default flow attributes, such as default periodicity, default SPS side link identifier, default priority, default PDB, default transmit power, etc., for transmission of unicast C-V2X IP packets to any destination L2 address indicated in the address mapping table.

[0135] In block 552, the modem may perform the method described in reference method 550 ( Figure 5B ) is to receive a unicast C-V2X IP packet, wherein the IP header of the unicast C-V2X IP packet indicates a source port and a destination IP address.

[0136] In block 960, the modem may perform an operation to compare the indicated destination IP address with an address mapping table to determine a matching destination IP address. For example, the modem may parse a stored address mapping table and compare the destination IP address in the address mapping table with the indicated destination IP address to determine a matching destination IP address.

[0137] In block 962, the modem may perform an operation of determining the destination L2 address as a corresponding destination L2 address associated with the matching destination IP address in the address mapping table. In various embodiments, since the address mapping table includes a corresponding destination L2 address associated with each destination IP address, a match between the destination IP address in the address mapping table and the indicated destination IP address in the IP header of the unicast C-V2X IP packet may indicate that the corresponding destination L2 address of the matching destination IP address is the destination L2 address for the destination of the unicast C-V2X IP packet.

[0138] In block 556, the modem may perform the method described in reference method 550 ( Figure 5B ) to add a PDCP header indicating the determined destination L2 address to a unicast C-V2X IP packet.

[0139] In block 964, the modem may perform an operation of transmitting a unicast C-V2X IP packet to the determined destination L2 address according to the default flow attributes set for the address mapping table. For example, the unicast C-V2X IP packet may be transmitted using a default periodicity, a default SPS side link identifier, a default priority, a default PDB, and / or a default transmit power indicated in the default flow attributes associated with the address mapping table.

[0140] Fig.10 is a call flow diagram illustrating example interactions between vehicles (such as vehicle 1, vehicle 2, and vehicle 3) transmitting unicast C-V2X IP packets (such as UDP packets, TCP packets, etc.) according to various embodiments. Figure 1A-10 , Fig.10 The call flow diagram of illustrates that vehicle 1 transmits unicast C-V2X IP packets to vehicle 2 and vehicle 3. Fig.10 , but the UDP packet is only one example of a unicast C-V2X IP packet and may be replaced by other types of unicast C-V2X IP packets (such as TCP packets). Vehicles 1, 2, and 3 may be specific examples of communication devices (e.g., on-board communication devices 140, 152, 153, RSUs 158, 159, communication devices 155, SIP 300, communication devices 401, 415, etc.) implementing various embodiments. Fig.10 As shown, vehicle 1 may include an AP 802 (e.g., AP 316) connected to a modem 803 (e.g., modem 312, 352, 372) via a physical interconnect or bus 800 (e.g., 326, 350, 364, 384). As an example, Fig.10The interaction shown in FIG. 5 may be performed by AP 802 and / or modem 803 according to method 500 ( Figure 5A )、550( Figure 5B )、900( Fig.9A ) and / or 950( Fig. 9B ) to perform one or more operations.

[0141] Vehicle 1 may have its own corresponding IP address (e.g., addr1) and destination L2 address (e.g., addrs1), such as a MAC address. Vehicle 2 may have its own corresponding IP address (e.g., addr2) and destination L2 address (e.g., addrs2), such as a MAC address. Vehicle 3 may have its own corresponding IP address (e.g., addr3) and destination L2 address (e.g., addrs3), such as a MAC address.

[0142] In operation 850, the modem 803 and AP 802 of vehicle 1 may establish an IP and non-IP V2X virtual packet data network (PDN). In operation 852, the AP 802 of vehicle 1 may perform a unicast address discovery operation to identify the IP addresses and destination L2 addresses of vehicles 2 and 3.

[0143] In operation 1002, AP 802 may generate and transmit a destination address registration to modem 803. The destination address registration may indicate a destination IP address and destination L2 address pairing of the destination devices (Vehicle 2 and Vehicle 3) identified during unicast address discovery operation 852. Modem 803 may store the destination IP address and destination L2 pairing in address mapping table 1004.

[0144] In operation 1006, AP 802 may register default flow attributes for unicast IP packets to be transmitted to any destination L2 address in the destination address registration. In operation 1008, modem 803 may set one or more flow attributes as default flow attributes for the address mapping table.

[0145] In operation 1010, the AP 802 may transmit a unicast C-V2X packet destined for vehicle 2 to the modem 803. The unicast C-V2X packet destined for vehicle 2 may indicate a source port 200 and a destination IP address addr2 in an IP header. The modem 803 may receive the unicast C-V2X packet and may determine, based on the address mapping table 1004, in operation 1012 that a destination L2 address of vehicle 2 is associated with a source port 200 and a destination IP address addr2 pair in the unicast C-V2X packet. The modem 803 may add a PDCP header indicating the destination L2 address of vehicle 2 to the unicast C-V2X packet and transmit the unicast C-V2X packet to the vehicle 2 using a default flow attribute associated with the address mapping table 1004.

[0146] In operation 1014, the AP 802 may transmit a unicast C-V2X packet destined for the vehicle 3 to the modem 803. The unicast C-V2X packet destined for the vehicle 3 may indicate a source port 200 and a destination IP address addr3 in an IP header. The modem 803 may receive the unicast C-V2X packet and may determine, based on the stored address mapping table 1004, in operation 1016 that the destination L2 address of the vehicle 3 is associated with the source port 200 and the destination IP address addr3 pair in the unicast C-V2X packet. The modem 803 may add a PDCP header indicating the destination L2 address of the vehicle 3 to the unicast C-V2X packet and transmit the unicast C-V2X packet to the vehicle 3 using the default flow attributes associated with the address mapping table 1004.

[0147] The processor implementing various embodiments may be any programmable microprocessor, microcomputer, or one or more multi-processor chips that may be configured by software instructions (applications) to perform various functions, including the functions of the various aspects described in this application. In some communication devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in internal memory before they are accessed and loaded into the processor. The processor may include internal memory sufficient to store application software instructions.

[0148] As used in this application, the terms "component", "module", "system", etc. are intended to include computer-related entities, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution, which are configured to perform specific operations or functions. For example, a component can be, but is not limited to, a process, a processor, an object, an executable file, an execution thread, a program, and / or a computer running on a processor. As an illustration, both an application running on a processor of a communication device and a communication device can be referred to as a component. One or more components can reside in a process and / or an execution thread, and a component can be located on a processor or core and / or distributed between two or more processors or cores. In addition, these components can be executed from various non-transient computer-readable media having various instructions and / or data structures stored thereon. Components can communicate through local and / or remote processes, function or procedure calls, electronic signals, data packets, memory read / writes, and other known network, computer, processor, and / or process-related communication methods.

[0149] Many different cellular and mobile communication services and standards are available or expected in the future, all of which can implement various aspects and benefit from various aspects. Such services and standards may include, for example, the Third Generation Partnership Project (3GPP), Long Term Evolution (LTE) system, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G), global system for mobile communications (GSM), universal mobile telecommunications system (UMTS), 3GSM, general packet radio service (GPRS), code division multiple access (CDMA) system (e.g., cdmaOne, CDMA1020TM), EDGE, advanced mobile phone system (AMPS), digital AMPS (IS-136 / TDMA), evolution data optimized (EV-DO), digital enhanced cordless telecommunications (DECT), worldwide interoperability for microwave access (WiMAX), wireless local area network (WLAN), Wi-Fi protected access I & II (WPA, WPA2), integrated digital enhanced network (iden), C-V2X, V2V, V2P, V2I and V2N, etc. Each of these technologies involves, for example, the transmission and reception of voice, data, signaling and / or content messages. It should be understood that any reference to terms and / or technical details related to individual telecommunication standards or technologies is for illustrative purposes only, and is not intended to limit the scope of the claims to a particular communication system or technology, unless specifically stated in the claim language.

[0150] The various aspects illustrated and described are provided only as examples to illustrate the various features of the claims. However, the features shown and described with respect to any given aspect are not necessarily limited to the associated aspects and may be used or combined with other aspects shown and described. In addition, the claims are not intended to be limited to any one example aspect. For example, one or more of the operations of the method may replace one or more operations of the method or be combined with one or more operations of the method.

[0151] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the operations of the various aspects must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the foregoing aspects may be performed in any order. Words such as "thereafter," "subsequently," "next" are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. In addition, any reference to a claim element in the singular form, such as using the articles "a," "an," or "the," should not be construed as limiting the element to the singular.

[0152] The various illustrative logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the aspects disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functions. Whether such functions are implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. Those skilled in the art may implement the described functions in different ways for each specific application, but such aspect decisions should not be interpreted as causing a departure from the scope of the claims.

[0153] Hardware for implementing the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented or performed using a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any common processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver smart objects, for example, a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, certain operations or methods may be performed by circuits specific to a given function.

[0154] In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-transient computer-readable storage medium or a non-transient processor-readable storage medium. The operation of the method or algorithm disclosed herein may be embodied in a processor-executable software module or processor-executable instructions that may reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. As an example and not limitation, such non-transient computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage smart objects, or any other medium that can be used to store the required program code in the form of an instruction or data structure and can be accessed by a computer. The disks and optical disks used herein include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and blue-ray disks, wherein the disks typically reproduce data magnetically, while the optical disks reproduce data optically with lasers. The above combinations are also included within the scope of non-transient computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable storage medium and / or a computer-readable storage medium, which may be incorporated into a computer program product.

[0155] The foregoing description of the disclosed aspects is provided to enable any person skilled in the art to make or use the claims. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the claims. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but will conform to the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method for unicast transmission of Cellular Vehicle-to-Everything (C-V2X) Internet Protocol (IP) packets performed by a modem of a vehicle, comprising: receiving a flow registration associating one or more source port and destination IP address pairs with respective destination L2 addresses, wherein the flow registration associates one or more flow attributes with each respective destination L2 address; cache the stream registration in memory available to the modem; receiving a unicast C-V2XIP packet, wherein an IP header of the unicast C-V2XIP packet indicates a source port and a destination IP address; comparing the indicated source port and the indicated destination IP address to the cached flow registration to determine a matching source port and destination IP address pair; determining the destination L2 address as the corresponding destination L2 address associated with the matching source port and destination IP address pair in the cached flow registration; adding a Packet Data Convergence Protocol (PDCP) header indicating the determined destination L2 address to the unicast C-V2X IP packet; as well as determining the one or more flow attributes associated with the determined destination L2 address based at least in part on the flow registration; The unicast C-V2X IP packet is transmitted to the determined destination L2 address according to the determined one or more flow attributes.

2. The method of claim 1, wherein the one or more flow attributes include periodicity, a semi-persistent scheduling (SPS) side link identifier, priority, a packet delay budget (PDB), or a transmit power.

3. The method of claim 1, wherein the unicast C-V2X IP packet is a Transmission Control Protocol (TCP) packet or a User Datagram Protocol (UDP) packet. The method of claim 1 , wherein the determined destination L2 address is a media access control (MAC) address of another vehicle.

5. A method for unicast transmission of Cellular Vehicle-to-Everything (C-V2X) Internet Protocol (IP) packets performed by a modem of a vehicle, comprising: receiving a destination address registration indicating a pairing of one or more destination IP addresses and corresponding destination L2 addresses; storing the one or more destination IP addresses and corresponding destination L2 address pairs in an address mapping table in a memory available to the modem, receiving a flow registration associated with the destination address registration, the flow registration indicating one or more flow attributes to be used for all corresponding destination L2 addresses in the destination address registration; setting the one or more flow attributes as default flow attributes for the address mapping table; receiving a unicast C-V2XIP packet, wherein an IP header of the unicast C-V2XIP packet indicates a source port and a destination IP address; comparing the indicated destination IP address with the address mapping table to determine a matching destination IP address; determining the destination L2 address as the corresponding destination L2 address associated with the matching destination IP address in the address mapping table; adding a Packet Data Convergence Protocol (PDCP) header indicating the determined destination L2 address to the unicast C-V2X IP packet; and The unicast C-V2X IP packet is transmitted to the determined destination L2 address according to the determined one or more flow attributes.

6. The method of claim 5, wherein the one or more flow attributes include periodicity, a semi-persistent scheduling (SPS) sidelink identifier, priority, a packet delay budget (PDB), or a transmit power.

7. The method of claim 5, wherein the unicast C-V2X IP packet is a Transmission Control Protocol (TCP) packet or a User Datagram Protocol (UDP) packet.

8. The method of claim 5, wherein the determined destination L2 address is a media access control (MAC) address of another vehicle.

9. A vehicle computing device comprising: A modem, the modem being configured to: receiving a flow registration associating one or more source port and destination IP address pairs with respective destination L2 addresses, wherein the flow registration associates one or more flow attributes with each respective destination L2 address; cache the stream registration in memory available to the modem; receiving a unicast C-V2XIP packet, wherein an IP header of the unicast C-V2XIP packet indicates a source port and a destination IP address; comparing the indicated source port and the indicated destination IP address to the cached flow registration to determine a matching source port and destination IP address pair; determining the destination L2 address as the corresponding destination L2 address associated with the matching source port and destination IP address pair in the cached flow registration; adding a Packet Data Convergence Protocol (PDCP) header indicating the determined destination L2 address to the unicast C-V2X IP packet; as well as determining the one or more flow attributes associated with the determined destination L2 address based at least in part on the flow registration; The unicast C-V2X IP packet is transmitted to the determined destination L2 address according to the determined one or more flow attributes.

10. The vehicle computing device of claim 9, wherein the one or more flow attributes include periodicity, a semi-persistent scheduling (SPS) sidelink identifier, priority, a packet delay budget (PDB), or a transmit power.

11. The vehicle computing device of claim 9, wherein the unicast C-V2XIP packet is a Transmission Control Protocol (TCP) packet or a User Datagram Protocol (UDP) packet.

12. The vehicle computing device of claim 9, wherein the determined destination L2 address is a media access control (MAC) address of another vehicle.

13. A vehicle computing device comprising: A modem, the modem being configured to: receiving a destination address registration indicating a pairing of one or more destination IP addresses and corresponding destination L2 addresses; storing the one or more destination IP addresses and corresponding destination L2 address pairs in an address mapping table in a memory available to the modem, receiving a flow registration associated with the destination address registration, the flow registration indicating one or more flow attributes to be used for all corresponding destination L2 addresses in the destination address registration; setting the one or more flow attributes as default flow attributes for the address mapping table; receiving a unicast C-V2X IP packet, wherein an IP header of the unicast C-V2X IP packet indicates a source port and a destination IP address; comparing the indicated destination IP address with the address mapping table to determine a matching destination IP address; determining the destination L2 address as the corresponding destination L2 address associated with the matching destination IP address in the address mapping table; adding a Packet Data Convergence Protocol (PDCP) header indicating the determined destination L2 address to the unicast C-V2X IP packet; and The unicast C-V2X IP packet is transmitted to the determined destination L2 address according to the determined one or more flow attributes.

14. The vehicle computing device of claim 13, wherein the one or more flow attributes include periodicity, a semi-persistent scheduling (SPS) sidelink identifier, priority, a packet delay budget (PDB), or a transmit power.

15. The vehicle computing device of claim 13, wherein the unicast C-V2X IP packet is a Transmission Control Protocol (TCP) packet or a User Datagram Protocol (UDP) packet.

16. The vehicle computing device of claim 13, wherein the determined destination L2 address is a media access control (MAC) address of another vehicle.

Images