WO2021035433A1 - Retransmission de l'ensemble du paquet ip lors de la détection d'un conflit d'id source dans v2x - Google Patents

Retransmission de l'ensemble du paquet ip lors de la détection d'un conflit d'id source dans v2x Download PDF

Info

Publication number
WO2021035433A1
WO2021035433A1 PCT/CN2019/102334 CN2019102334W WO2021035433A1 WO 2021035433 A1 WO2021035433 A1 WO 2021035433A1 CN 2019102334 W CN2019102334 W CN 2019102334W WO 2021035433 A1 WO2021035433 A1 WO 2021035433A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
src
transmission
pdus
processor
Prior art date
Application number
PCT/CN2019/102334
Other languages
English (en)
Inventor
Haizhou LIU
Xiaochen Chen
Chunxia LI
Zengyu Hao
Nan Zhang
Hongjin GUO
Yi Qin
Jintao HOU
Original Assignee
Qualcomm Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Priority to PCT/CN2019/102334 priority Critical patent/WO2021035433A1/fr
Publication of WO2021035433A1 publication Critical patent/WO2021035433A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • Cellular and wireless communication technologies have seen explosive growth over the past several 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 communications hardware, larger networks, and more reliable protocols.
  • the surface transportation industry has increasingly looked to leverage the growing capabilities of cellular and wireless communication technologies through the adoption of Intelligent Transportation Systems (ITS) technologies to increase intercommunication and safety for both driver-operated vehicles and autonomous vehicles.
  • ITS Intelligent Transportation Systems
  • the cellular vehicle-to-everything (C-V2X) protocol defined by the 3rd Generation Partnership Project (3GPP) supports ITS technologies and serves as the foundation for vehicles to communicate directly with the communication devices around them.
  • C-V2X defines two transmission modes that, together, provide a 360° non-line-of-sight awareness and a higher level of predictability for enhanced road safety and autonomous driving.
  • a first transmission mode includes direct C-V2X, which includes vehicle-to-vehicle (V2V) , vehicle-to-infrastructure (V2I) , and vehicle-to-pedestrian (V2P) , and that provides enhanced communication range and reliability in the dedicated ITS 5.9 gigahertz (GHz) spectrum that is independent of a cellular network.
  • Communications in the first transmission mode, including V2V, V2I, and V2P communications, can be conducted over the PC5 interface.
  • a second transmission mode includes vehicle-to-network communications (V2N) in mobile broadband systems and technologies, such as third generation wireless mobile communication technologies (3G) (e.g., global system for mobile communications (GSM) evolution (EDGE) systems, code division multiple access (CDMA) 2000 systems, etc. ) , fourth generation wireless mobile communication technologies (4G) (e.g., long term evolution (LTE) systems, LTE-Advanced systems, mobile Worldwide Interoperability for Microwave Access (mobile WiMAX) systems, etc. ) , fifth generation wireless mobile communication technologies (5G) (e.g., 5G New Radio (5G NR) systems, etc. ) , etc.
  • 3G third generation wireless mobile communication technologies
  • 3G e.g., global system for mobile communications (GSM) evolution (EDGE) systems, code division multiple access (CDMA) 2000 systems, etc.
  • 4G e.g., long term evolution (LTE) systems, LTE-Advanced systems, mobile Worldwide Interoperability for Microwave Access (mobile WiMA
  • V2X vehicle-to-everything
  • PC5 interface including retransmission of Internet Protocol (IP) packets by a sending V2X entity with a new source identifier (src-id) when a src-id conflict is detected by that sending V2X entity.
  • IP Internet Protocol
  • Various aspects include methods for V2X direct communication over a PC5 interface.
  • the methods for V2X direct communication over a PC5 interface may be performed by a processor of a V2X entity.
  • a method for V2X direct communication over a PC5 interface may include monitoring the PC5 interface for transmissions from remote entities, determining whether any transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity, dropping any unsent protocol data units (PDUs) associated with a service data unit (SDU) for transmission by the V2X entity in response to determining that any transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity, assigning a new different src-id in response to determining that any transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity, converting the SDU for transmission by the V2X entity into one or more new PDUs having the new different source identifier, and sending the one or more new PDUs via the PC5 interface.
  • PDUs uns
  • a method for V2X direct communication over a PC5 interface may include monitoring the PC5 interface for transmissions from remote entities, determining whether a transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity, determining whether the transmission from the remote entity has a same priority and same destination identifier as a priority and a destination identifier assigned to any unsent PDUs associated with an SDU for transmission from the V2X entity in response to determining that the transmission from the remote entity has the same src-id as the src-id currently being used by the V2X entity, dropping the unsent PDUs in response to determining that the transmission from the remote entity has the same priority and the same destination identifier as the priority and the destination identifier assigned to the protocol data units, assigning a new different src-id in response to determining that the transmission from the remote entity has the same priority and the same destination identifier as the priority and the
  • the V2X entity may be an in-vehicle communication device. In some aspects, the V2X entity may be an infrastructure communication device or a pedestrian carried communication device. In some aspects, the remote entity may be one of in-vehicle communication device, an infrastructure communication device, or a pedestrian carried communication device. In some aspects, the processor may be a modem processor.
  • the methods may include receiving the SDU for transmission by the V2X entity from a higher layer.
  • the higher layer may be a layer running on the processor or a layer running on a separate processor.
  • the monitoring, determining, dropping, assigning, and converting operations of the methods may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • Various aspects include a communication device including a processor configured with processor-executable instructions to perform operations of the methods summarized above.
  • Various aspects also include a non-transitory processor-readable medium on which is stored processor-executable instructions configured to cause a processor of a communication device to perform operations of the methods summarized above.
  • Various aspects also include a communication device including means for performing functions of the methods summarized above.
  • Various aspects also include a system on chip for use in a communication device that includes a processor configured to perform one or more operations of the methods summarized above.
  • Various aspects also include a system in a package that includes two or more systems on chip for use in a communication device that includes a processor configured to perform one or more operations of the methods summarized above.
  • FIG. 1 is a system block diagram conceptually illustrating an example cellular V2X (C-V2X) system.
  • FIG. 2 is a system block diagram of components of an automotive vehicle according to various embodiments.
  • FIG. 3 is a component block diagram illustrating a communication device that may be configured to implement methods for for V2X direct communication over PC5 interface performed by a processor of a V2X entity in accordance with various embodiments.
  • FIG. 4 is a block diagram illustrating an example of interactions between stack architecture layers in a transmitting communication device and a receiving communication device in accordance with various embodiments.
  • FIG. 5 is a process flow diagram illustrating a method for V2X direct communication over a PC5 interface according to various embodiments.
  • FIG. 6 is a process flow diagram illustrating a method for V2X direct communication over a PC5 interface according to various embodiments.
  • FIG. 7 is a component block diagram of a communication device that may be configured to implement methods for V2X direct communication over a PC5 interface in accordance with various embodiments.
  • the term “communication device” refers to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Internet-of-Things (IoT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers or routers, and similar electronic devices which include a programmable processor and memory and circuitry configured to perform operations as described herein. While the various aspects are particularly useful for in-vehicle communication systems and/or computing devices, the aspects are generally useful in any communication device that includes communication circuitry and a processor that executes application programs.
  • SoC system-on-chip
  • CPU central processing unit
  • DSP digital signal processor
  • GPU graphics processing unit
  • APU accelerated processing unit
  • sub-system processor a sub-system processor
  • auxiliary processor a single-core processor
  • multicore processor a multicore processor
  • the SoC may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA) , a configuration and status register (CSR) , an application-specific integrated circuit (ASIC) , other programmable logic device, discrete gate logic, transistor logic, registers, performance monitoring hardware, watchdog hardware, counters, and time references.
  • SoCs may be integrated circuits (ICs) configured such that the components of the IC reside on the same substrate, such as a single piece of semiconductor material (e.g., silicon, etc. ) .
  • SIP system in a package
  • a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration.
  • the SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unifying substrate.
  • MCMs multi-chip modules
  • a SIP may also include multiple independent SoCs coupled together via high speed communication circuitry and packaged in close proximity, such as on a single motherboard or in a single mobile communication device. The proximity of the SoCs facilitates high speed communications and the sharing of memory and resources.
  • multicore processor is used herein to refer to a single IC chip or chip package that contains two or more independent processing cores (e.g., CPU core, IP core, GPU core, etc. ) configured to read and execute program instructions.
  • An SoC may include multiple multicore processors, and each processor in an SoC may be referred to as a core.
  • multiprocessor may be used herein to refer to a system or device that includes two or more processing units configured to read and execute program instructions.
  • the cellular vehicle-to-everything (C-V2X) protocol defined by the 3rd Generation Partnership Project (3GPP) supports direct communication between two vehicle-to-everything (V2X) entities over a PC5 interface.
  • a V2X entity may be any communication device configured to support direct communication according to the C-V2X protocol, such as an in-vehicle communication device, a mobile communication device (e.g., a smartphone, laptop, etc. ) temporarily placed within a vehicle, a traffic sensor, a communication device (e.g., a smartphone, laptop, etc. ) in use by a pedestrian, etc.
  • Direct communications may be supported by device-to-device (D2D) links established over the PC5 interface.
  • D2D device-to-device
  • the V2X direct communication over the PC5 interface supported by the C-V2X protocol can include vehicle-to-vehicle (V2V) direct communication, vehicle-to-infrastructure (V2I) direct communication, and/or vehicle-to-pedestrian (V2P) direct communication.
  • V2V vehicle-to-vehicle
  • V2I vehicle-to-infrastructure
  • V2P vehicle-to-pedestrian
  • each V2X entity sending packets over the PC5 interface includes a source identifier (src-id) in the Internet Protocol (IP) packets the V2X entity transmits.
  • IP Internet Protocol
  • Each V2X entity independently assigns itself its own src-id and the Layer 2 sublayers, such as a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a media access control (MAC) layer, etc., of the V2X entity write the src-id into packets for transmission over the PC5 interface.
  • PDCP packet data convergence protocol
  • RLC radio link control
  • MAC media access control
  • the src-id assigned by the V2X entity itself is written into the one or more PDUs.
  • the src-id is recognized by Layer 2 sublayers, such as the PDCP layer, RLC layer, MAC layer, etc., in the stack architecture of the V2X entities and the src-id serves to identify the source of each packet transmitted over the PC5 interface.
  • a V2X entity receiving a PDU over the PC5 interface uses the src-id to associate the PDU with other PDUs from the same sending V2X entity.
  • the PDUs having the same src-id are grouped together and used by the receiving V2X entity’s Layer 2 sublayers, such as the PDCP layer, RLC layer, MAC layer, etc., to reconstruct the original SDU of the sending V2X entity.
  • the src-id is independently self assigned by each V2X entity, it is possible that two or more V2X entities could assign themselves the same src-id. Two or more entities using the same src-id at the same time for communications over the PC5 interface may represent a src-id conflict in V2X communications. When the same src-id is in use by two V2X entities, both entities will send IP packets over the PC5 interface including the same src-id.
  • a V2X entity receiving IP packets over the PC5 interface from those two sending V2X entities may not be able to distinguish that the IP packets originated from different sources because the src-id in the IP packets from both sending V2X entities is the same.
  • the receiving V2X entity may group the IP packets together.
  • the receiving V2X entity may not be able to correctly construct an SDU because PDUs from the two different sending V2X entities are grouped together due to the shared src-id.
  • the failure to correctly construct an SDU may result in IP packets from both the sending V2X entities using the same src-id being discarded by the receiving V2X entity.
  • IP packets from both the sending V2X entities using the same src-id may be discarded by the receiving V2X entity, neither of the sending V2X entities using the same src-id may effectively communicate directly with the receiving V2X entity over the PC5 interface.
  • data loss may occur in direct communications over the PC5 interface between one or more of the sending V2X entities and the receiving V2X entity because the IP packets from both of the sending V2X entities using the same src-id are being discarded by the receiving V2X entity.
  • Systems, methods, and devices of the various embodiments may enable V2X direct communication over the PC5 interface that supports retransmission of IP packets by a sending V2X entity with a new src-id when a src-id conflict is detected by that sending V2X entity.
  • the use of a new src-id for IP packet retransmission may prevent the retransmitted IP packets from being discarded by a receiving V2X entity because the new src-id may no longer match the src-id of another sending V2X entity.
  • various embodiments may support effective direct communication from the sending V2X entity to the receiving V2X entity over the PC5 interface. For example, various embodiments may reduce or prevent data loss because the retransmitted IP packets may not be discarded by a receiving V2X entity.
  • a V2X entity may monitor the PC5 interface for transmissions from remote entities. Monitoring may include parsing IP packets received over the PC5 interface for information contained in those IP packets, such as the src-id of the IP packets, priority of the IP packets, destination identifier of the IP packets, etc. For example, a V2X entity may monitor the PC5 interface by parsing PDUs received over the PC5 interface and passed from a Layer 1 level of the stack architecture of the V2X entity to a Layer 2 level in the stack architecture of the V2X entity.
  • a PDU received over the PC5 interface may be parsed to determine the src-id used by the remote entity (e.g., another V2X entity, etc. ) that sent the PDU, the priority assigned to the PDU by the remote entity (e.g., a V2X entity, etc. ) that sent the PDU, the destination identifier assigned to the PDU by the remote entity (e.g., another V2X entity, etc. ) that sent the PDU, and/or any other type of information that may be contained in the PDU.
  • the remote entity e.g., another V2X entity, etc.
  • the priority assigned to the PDU by the remote entity e.g., a V2X entity, etc.
  • the destination identifier assigned to the PDU by the remote entity e.g., another V2X entity, etc.
  • the V2X entity may determine whether any transmission from a remote entity (e.g., another V2X entity, etc. ) has a same src-id as a src-id currently being used by the V2X entity.
  • the V2X entity monitoring the PC5 interface may have previously assigned itself a src-id and that previously assigned src-id may be stored in a memory location available to the V2X entity for use as the V2X entity’s current src-id.
  • the V2X entity may determine whether any transmission from a remote entity (e.g., another V2X entity, etc.
  • the comparison between the src-id in a PDU received over the PC5 interface to the V2X entity’s own stored currently assigned src-id may be performed at a Layer 2 level in the stack architecture of the V2X entity.
  • a match between the src-id in a PDU received over the PC5 interface to the V2X entity’s stored currently assigned src-id may indicate the remote entity (e.g., another V2X entity, etc. ) that sent the PDU is using the same src-id as the V2X entity’s own stored currently assigned src- id.
  • Two entities using the same src-id for communications over the PC5 interface may indicate a src-id conflict is occurring.
  • the src-id in a PDU received over the PC5 interface being different from the V2X entity’s own stored currently assigned src-id may indicate that no src-conflict is occurring.
  • the V2X entity may drop any unsent PDUs associated with an SDU for transmission by the V2X entity in response to determining that any transmission from a remote entity (e.g., another V2X entity, etc. ) has a same src-id as a src-id currently being used by the V2X entity.
  • SDUs may be received from a higher layer (e.g., Layer 3) at middle layer (e.g., Layer 2) of the stack architecture and converted to one or more PDUs for transmission over the PC5 interface by a lower layer (e.g., Layer 1) of the stack architecture of the V2X entity.
  • the one or more PDUs may be buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface.
  • the one or more PDUs may be undergoing further processing in preparation for transmission, may be being buffered in a transmission queue buffer, etc.
  • PDUs that are buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface may be unsent PDUs. These unsent PDUs may already include the src-id currently being used by the V2X entity.
  • Sending these unsent PDUs including the src-id currently being used by the V2X entity may result in further conflicts with transmissions by the other remote entity using that same src-id.
  • the V2X entity may drop the unsent PDUs to prevent such conflicts from occurring on the PC5 interface.
  • the dropping of the unsent PDUs may prevent processing resources and radio resources from being expended on PDUs that will likely be discarded by an entity that receives the PDUs due to src-id conflicts.
  • the V2X entity may assign a new different src-id in response to determining that any transmission from a remote entity (e.g., another V2X entity, etc. ) has a same src-id as a src-id currently being used by the V2X entity. Ensuring the newly assigned src-id is different than the previously assigned src-id may ensure the new different src-id does not conflict with the src-id of the remote entity (e.g., another V2X entity, etc. ) .
  • the assignment of the new different src-id may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • a V2X entity may determine whether the transmission from the remote entity (e.g., another V2X entity, etc. ) has a same priority and same destination identifier as a priority and a destination identifier assigned to any unsent PDUs associated with an SDU for transmission from the V2X entity in response to determining that the transmission from the remote entity has the same src-id as the src-id currently being used by the V2X entity.
  • the remote entity e.g., another V2X entity, etc.
  • SDUs may be received from a higher layer (e.g., Layer 3) at middle layer (e.g., Layer 2) of the stack architecture and converted to one or more PDUs for transmission over the PC5 interface by a lower layer (e.g., Layer 1) of the stack architecture of the V2X entity.
  • the one or more PDUs may be buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface.
  • the one or more PDUs may be undergoing further processing in preparation for transmission, may be being buffered in a transmission queue buffer, etc.
  • Such PDUs that are buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface may be unsent PDUs. These unsent PDUs may already include the src-id currently being used by the V2X entity. Additionally, unsent PDUs may include a priority assigned to the PDUs and a destination identifier. The priority may indicate the relative importance of the transmission. The destination identifier may indicate the communication device to which the unsent PDUs are addressed. Sending these unsent PDUs including the src-id currently being used by the V2X entity with the same priority and same destination identifier may result in further conflicts with transmissions by the other remote entity (e.g., another V2X entity, etc.
  • the other remote entity e.g., another V2X entity, etc.
  • the comparison between the priority and destination identifier in a PDU received over the PC5 interface to the V2X entity’s unsent PDUs may be performed at a Layer 2 level in the stack architecture of the V2X entity.
  • a match between the priority and the destination identifier in a PDU received over the PC5 interface to the priority and the destination identifier of the V2X entity’s unsent PDUs may indicate the remote entity (e.g., another V2X entity, etc. ) that sent the PDU is using the same priority and the same destination identifier as the V2X entity’s own unsent PDUs.
  • Two entities using the same src-id, same priority, and same destination ID for communications over the PC5 interface may indicate a src-id conflict is occurring and a receiving communication device may be unable to resolve the conflict between such PDUs.
  • the priority and the destination identifier in a PDU received over the PC5 interface being different from those of the unsent PDUs of the V2X entity may indicate, that even though an src-conflict is occurring, a receiving communication device may be able to resolve the conflict because the different priorities and different destination identifiers may enable the receiving communication device to distinguish the PDUs as originating from different sources despite the same src-id being used in the PDUs.
  • the V2X entity may drop any unsent PDUs associated with an SDU for transmission by the V2X entity in response to determining that the transmission from the remote entity has the same priority and the same destination identifier as the priority and the destination identifier assigned to the PDUs.
  • the V2X entity may drop the unsent PDUs to prevent src-id conflicts from occurring on the PC5 interface.
  • the dropping of the unsent PDUs may prevent processing resources and radio resources from being expended on PDUs that will likely be discarded by an entity that receives the PDUs due to src-id conflicts.
  • the V2X entity may assign a new different src-id in response to determining that any transmission from a remote entity (e.g., another V2X entity, etc. ) has the same priority and the same destination identifier as the priority and the destination identifier assigned to the PDUs. Ensuring the newly assigned src-id is different than the previously assigned src-id may ensure the new different src-id does not conflict with the src-id of the remote entity (e.g., another V2X entity, etc. ) even though the priority and the destination identifier may remain the same.
  • the assignment of the new different src-id may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • the V2X entity may convert an SDU for transmission by the V2X entity into one or more new PDUs having the new different source identifier.
  • new PDUs including the new different source identifier may be created from the same SDU for transmission over the PC5 interface.
  • the retransmission of the IP packets corresponding to the SDU may be accomplished using the one or more new PDUs and any receiving device may not experience a src-id conflict because the src-ids in the one or more new PDUs are different from the previously assigned src-id.
  • the operations to convert the SDU to one or more new PDUs may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • the V2X entity may send the one or more new PDUs via the PC5 interface.
  • the operations to send the one or more new PDUs via the PC5 interface may be performed at a Layer 1 level in a stack architecture of the V2X entity.
  • the one or more new PDUs may no longer conflict with the PDUs sent by the remote entity (e.g., another V2X entity, etc. ) as the src-id in use by that remote entity (e.g., another V2X entity, etc. ) may not match the new different src-id written into the one or more new PDUs.
  • FIG. 1 illustrates an example C-V2X system 100 suitable for implementing various embodiments.
  • a C-V2X system 100 may include an in-vehicle communication device 102 configured to exchange wireless communications with other communication devices around a vehicle 112 in which the in-vehicle communication device 102 is located.
  • the vehicle 112 may be any type of vehicle, such as an autonomous vehicle (e.g., driverless car, etc. ) , semi-autonomous vehicle, remotely operated vehicle, etc.
  • the in-vehicle communication device 102 may be a computing device mounted in the vehicle 112 or may be a mobile communication device (e.g., a smartphone, laptop, etc. ) temporarily placed within the vehicle 112.
  • the C-V2X system 100 may include various devices in addition to the in-vehicle communication device 102, such as another in-vehicle communication device 103 of another vehicle 114, traffic sensors 106 and 107 connected to transportation management server 110, communication device 105 (e.g., a smartphone, laptop, etc. ) , cellular tower or base station 113 connected to a network 115 and network server 116, etc.
  • Various components of the C-V2X system 100 may be configured to operate as an ITS network to support intercommunication and safety for surface vehicles.
  • the in-vehicle communication device 102 may be configured to perform vehicle-to-vehicle (V2V) communications, vehicle-to-infrastructure (V2I) communications, and vehicle-to-pedestrian (V2P) communications.
  • V2V vehicle-to-vehicle
  • V2I vehicle-to-infrastructure
  • V2P vehicle-to-pedestrian
  • the in-vehicle communication device 102 may establish a device-to-device (D2D) link with another in-vehicle communication device 103 of another vehicle 114 to exchange V2V communications.
  • the in-vehicle communication device 102 may establish D2D links with traffic sensors 106 and 107 connected to transportation management server 110 to exchange V2I communications.
  • the in-vehicle communication device 102 may establish a D2D link with the communication device 105, such as a smartphone, laptop, etc., of a user 111 to exchange V2P communications.
  • the D2D links between the in-vehicle communication device 102, the in-vehicle communication device 103, the communication device 105, the traffic sensor 106, and the traffic sensor 107 may be communication links established independent of a cellular network, such as links establish in the dedicated ITS 5.9 gigahertz (GHz) spectrum.
  • the D2D links may be dedicated short range communication (DSRC) links, LTE direct (LTE-D) links, or any other type link supporting direct device communication.
  • DSRC dedicated short range communication
  • LTE-D LTE direct
  • the D2D links between the in-vehicle communication device 102, the in-vehicle communication device 103, the communication device 105, the traffic sensor 106, and the traffic sensor 107 may be communication links established using the PC5 interface as defined by 3GPP.
  • the D2D links between the in-vehicle communication device 102, the in-vehicle communication device 103, the communication device 105, the traffic sensor 106, and the traffic sensor 107 may support sidelink communications over the PC5 interface between the various communication devices 102, 103, 105, 106, and 107.
  • the in-vehicle communication device 102 may be configured to perform vehicle-to-network (V2N) communications.
  • V2N vehicle-to-network
  • the in-vehicle communication device 102 may establish network-to-device links with a cellular tower or base station 113 connected to a network 115 and a network server 116 to exchange V2N communications.
  • the network-to-device links may include, without limitation, uplinks (or reverse links) , downlinks (or forward links) , bidirectional links, etc.
  • the network-to-device links may be established according to mobile broadband systems and technologies, such as third generation wireless mobile communication technologies (3G) (e.g., global system for mobile communications (GSM) evolution (EDGE) systems, code division multiple access (CDMA) 2000 systems, etc.
  • 3G third generation wireless mobile communication technologies
  • GSM global system for mobile communications
  • EDGE global system for mobile communications
  • CDMA code division multiple access
  • fourth generation wireless mobile communication technologies (4G) e.g., long term evolution (LTE) systems, LTE-Advanced systems, mobile Worldwide Interoperability for Microwave Access (mobile WiMAX) systems, etc.
  • 4G fourth generation wireless mobile communication technologies
  • 5G fifth generation wireless mobile communication technologies
  • 5G NR 5G New Radio
  • the in-vehicle communication device 102 and the cellular tower or base station 113 may include 5G NR functionality with an air interface based on orthogonal frequency division multiplexing (OFDM) .
  • the functionality of the cellular tower or base station 113 may be similar in one or more aspects to (or incorporated into) the functionality of a cellular IoT (CIoT) base station (C-BS) , a NodeB, an evolved NodeB (eNodeB) , 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 the radio technology used to establish the network-to-device links between the cellular tower or base station 113 and the in-vehicle communication device 102.
  • C-BS cellular I
  • the cellular tower or base station 113 may be in communication with respective routers that may connect to the network 115 (e.g., core network, Internet, etc. ) . Using the connections to the cellular tower or base station 113, the in-vehicle communication device 102 may exchange data with the network 115 as well as devices connected to the network 115, such as a network server 116 or any other communication device connected to the network 115.
  • the network 115 e.g., core network, Internet, etc.
  • FIG. 2 is a system block diagram of components of an automotive vehicle 200 suitable for implementing various embodiments.
  • the vehicle 200 may be a vehicle in a C-V2X system, such as vehicle 112, vehicle 114, etc.
  • the automotive vehicle 200 may include an in-vehicle communication device 202 (e.g., in-vehicle communication device 102, in-vehicle communication device 103, etc. ) connected to a bus 213, such as a controller area network (CAN) bus or other type vehicle bus.
  • a bus 213 such as a controller area network (CAN) bus or other type vehicle bus.
  • CAN controller area network
  • the bus 213 may interconnect various systems and devices in the automotive vehicle 200, such as a rear-view camera 205, tire pressure monitoring system 203, collision warning system 220, display system 210, and Advanced Driver Assistance System (ADAS) 204.
  • Other systems and devices that may be connected to the bus 213 may include an autonomous driving system, traffic sign recognition system, parking assistance system, telematics unit, or any other type system suitable for use on an automotive vehicle.
  • images and/or sensor data from the rear-view camera 205, tire pressure monitoring system 203, collision warning system 220, display system 210, ADAS 204, and/or other systems may be sent to the in-vehicle communication device via the bus 213.
  • the in-vehicle communication device 202 may be a vehicle communication system configured to exchange C-V2X communications with other communication devices around the automotive vehicle 200.
  • the in-vehicle communication device 202 may include a system in a package (SIP) 207.
  • the SIP 207 may be configured to support wireless communications to and from the automotive vehicle 200.
  • the SIP 207 may be connected to the bus 213 and to one or more antennas 221.
  • the connection to the bus 213 may enable the SIP 207 to send/receive data to/from various devices on the automotive vehicle 200.
  • the one or more antennas 221 may be configured for sending and receiving electromagnetic radiation and the connections to the one or more antennas 221 may enable the SIP 207 to send/receive data to/from various devices around the automotive vehicle 200.
  • messages over the PC5 interface may be sent/received by the SIP 207 to/from various devices around the automotive vehicle 200 via the one or more antennas 221 and those messages may be sent/received by the SIP 207 to/from various device on the automotive vehicle 200 via the bus 213.
  • FIG. 3 illustrates an example SIP 300 architecture that may be configured to implement methods for for V2X direct communication over a PC5 interface performed by a processor of a V2X entity in accordance with various embodiments.
  • example SIP 300 architecture may be implemented in any SIP, (e.g., SIP 207) and may be used in any communication device (e.g., in-vehicle communication device 102, in-vehicle communication device 103, in-vehicle communication device 202, etc. ) implementing various embodiments.
  • the SIP 300 includes three SoCs 302, 304, 371.
  • the first SoC 302 may operate as a central processing unit (CPU) of the communication device that carries out the instructions of software application programs by performing the arithmetic, logical, control and input/output (I/O) operations specified by the instructions.
  • the second SoC 304 may operate as a specialized processing unit.
  • the second SoC 304 may operate as a specialized 5G processing unit responsible for managing high volume, high speed (e.g., 5 Gbps, etc. ) , and/or very high frequency short wave length (e.g., 28 GHz mmWave spectrum, etc.
  • the third SoC 371 may operate as a specialized processing unit.
  • the third SoC 371 may operate as a specialized C-V2X processing unit responsible for managing V2V, V2I, and V2P communications over D2D links, such as D2D links establish in the dedicated ITS 5.9 GHz spectrum communications.
  • the third SoC 371 may support direct communication over the PC5 interface.
  • the SoCs and organization of functionality illustrated in FIG. 3 are a non-limiting example of an SIP as other architectures and organizations of functionality among SoCs, including fewer or more SoCs, are contemplated.
  • the first SoC 302 includes a digital signal processor (DSP) 310, a modem processor 312, a graphics processor 314, an application processor 316, one or more coprocessors 318 (e.g., vector co-processor) connected to one or more of the processors, memory 320, custom circuity 322, system components and resources 324, an interconnection/bus module 326, one or more temperature sensors 330, and a thermal management unit 332.
  • the second SoC 304 includes a 5G modem processor 352, a power management unit 354, an interconnection/bus module 364, a plurality of mmWave transceivers 356, memory 358, and various additional processors 360, such as an applications processor, packet processor, etc.
  • the third SoC 371 includes an ITS modem processor 372, a power management unit 374, an interconnection/bus module 384, a plurality of transceivers 376 (e.g., transceivers configured to operate in the dedicated ITS 5.9 GHz spectrum) , memory 378, and various additional processors 380, such as an applications processor, packet processor, etc.
  • Each processor 310, 312, 314, 316, 318, 352, 360, 372, 380 may include one or more cores, and each processor/core may perform operations independent of the other processors/cores.
  • 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 WINDOWS 10) .
  • a first type of operating system e.g., FreeBSD, LINUX, OS X, etc.
  • a second type of operating system e.g., MICROSOFT WINDOWS 10.
  • 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. ) .
  • a processor cluster architecture e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.
  • the first, second, and third SoCs 302, 304, 371 may include various system components, resources and custom circuitry for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser or other display application.
  • 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 used to support the processors and software clients running on a wireless device.
  • the system components and resources 324 and/or custom circuitry 322 may also include circuitry to interface 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, ADASs, vehicle buses, etc.
  • 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, ADASs, vehicle buses, etc.
  • the first, second, and third SoCs 302, 304, 371 may communicate via one or more interconnection/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 circuitry 322, and a thermal management unit 332 via an interconnection/bus module 326.
  • the processors 352, 360 may be interconnected to the power management unit 354, the mmWave transceivers 356, memory 358, and various additional processors 360 via the interconnection/bus module 364.
  • the processors 372, 380 may be interconnected to the power management unit 374, the transceivers 376, memory 378, and various additional processors 380 via the interconnection/bus module 384.
  • the interconnection/bus module 326, 350, 364, 384 may include an array of reconfigurable logic gates 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 (NoCs) .
  • NoCs high-performance networks-on chip
  • the first, second, and/or third SoCs 302, 304, 371 may further include an input/output module (not illustrated) for communicating with resources external to the SoCs.
  • Resources external to the SoCs may be shared by two or more of the internal SoC processors/cores.
  • the various aspects may be implemented in a wide variety of communication devices, which may include a single processor, multiple processors, multicore processors, or any combination thereof.
  • FIG. 4 illustrates interactions between stack architecture layers in a transmitting communication device 401 and a receiving communication device 415 in accordance with various embodiments.
  • the communication devices 401, 415 may each be any type of communication device (e.g., in-vehicle communication device 102, in-vehicle communication device 103, in-vehicle communication device 202, SIP 300, etc. ) implementing various embodiments.
  • the communication devices 401, 415 may be communication devices configured to exchange information using C-V2X communications.
  • layers in stack architecture of the communication device 401 may form logical connections with corresponding layers in the stack architecture of the communication device 415.
  • the stack architecture may be distributed among one or more processors (e.g., the processors 310, 312, 314, 316, 318, 352, 360, 372, 380) . While illustrated with respect to one radio protocol stack, in a multi-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., two protocol stacks associated with two SIMs, respectively, in a dual-SIM communication device) . While described below with reference to LTE communication layers, the stack architecture may support any of variety of standards and protocols for wireless communications, and/or may include additional protocol stacks that support any of variety of standards and protocols wireless communications.
  • SIM subscriber identity module
  • 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.
  • the higher data layers 402 may be one or more ITS layers, one or more service layers, one or more messaging layers, application layers, etc.
  • the functionality performed in the higher data layers 402 may include applications 403 (e.g., ITS safety critical applications, ITS non-safety 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. ) , other higher data layer functionality, or any combination thereof.
  • IP Internet Protocol
  • the higher data layers 402 may, individually or collectively, be sublayers of Layer 3 in the stack architecture.
  • the higher data layers 402 and the modem stack 406 on the communication device 401, 415 may be running on the same processor of the communication device 401, 415. In some embodiments, the higher data layers 402 and the modem stack 406 on the communication device 401, 415 may run on different processors of the communication device 401, 415. As an example, the higher data layers 402 may run on an application processor (e.g., application processor 316) and the modem stack 406 may run on a modem processor (e.g., modem processor 312, modem processor 352, modem processor 372) . While illustrated in FIG.
  • the higher data layers 402 may run on a processor of a separate communication device.
  • the higher data layers 402 may run on a processor of an ADAS (e.g., ADAS 204) and the modem stack 406 may run on a processor of a SIP (e.g., SIP 300) connected to the processor of the ADAS.
  • ADAS e.g., ADAS 204
  • SIP Session Init
  • the modem stack 406 may include a packet data convergence protocol (PDCP) layer 407, a radio link control (RLC) layer 408, a media 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, RLC layer 408, and 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.
  • the PDCP layer 407 may handle PDCP packets and may provide multiplexing between different radio bearers and logical channels, compression, ciphering, and/or integrity protection for the PDCP packets.
  • the PDCP layer 407 may receive packets from the higher data layers 402 and may output packets to the higher data layers 402.
  • the PDCP layer 407 may receive packets from the RLC layer 408 and may output packets to the RLC layer 408.
  • the PDCP layer 407 may provide functions including multiplexing between different radio bearers and logical channels, sequence number addition, handover data handling, integrity protection, ciphering, and header compression.
  • the PDCP layer 407 may provide functions that include in-sequence delivery of data packets, duplicate data packet detection, integrity validation, deciphering, and header decompression.
  • the RLC layer 408 may handle RLC packets and may provide error correction, concatenation, segmentation, reassembly, reordering, duplication detection, error detection, and/or error recovery for the RLC packets. Additionally, the RLC layer 408 may buffer RLC packets in a reception buffer, such as to support reordering, await missing RLC packets, etc. The RLC layer 408 may operate in different modes, such as an acknowledge mode (AM) , unacknowledged mode (UM) , and transparent mode (TM) . The RLC layer 408 may receive packets from the PDCP layer 407 and may output packets to the PDCP layer 407.
  • AM acknowledge mode
  • UM unacknowledged mode
  • TM transparent mode
  • the RLC layer 408 may receive packets from the MAC layer 409 and may output packets to the MAC layer 409.
  • the RLC layer 408 may provide segmentation and concatenation of upper layer data packets, retransmission of lost data packets, and Automatic Repeat Request (ARQ) .
  • ARQ Automatic Repeat Request
  • the RLC layer 408 functions may include reordering of data packets to compensate for out-of-order reception, reassembly of upper layer data packets, and ARQ.
  • the MAC layer 409 may handle MAC packets and may provide frame delimiting/recognition, addressing, and/or error protection for the MAC packets. Additionally, 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.
  • the MAC layer 409 may provide functions including multiplexing between logical and transport channels, random access procedure, logical channel priority, and hybrid-ARQ (HARQ) operations.
  • the MAC layer 409 functions may include channel mapping within a cell, de-multiplexing, discontinuous reception (DRX) , and HARQ operations.
  • the PHY layer 410 may handle PHY packets and may provide the 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 bitstream for transmission and/or convert a received bitstream into PHY packets.
  • the PHY layer 410 provide encoding, transmission, reception, and/or decoding for the PHY packets.
  • the PHY layer 410 may receive packets from the MAC layer 409 and may output packets to the MAC layer 409.
  • the packets transferred to/from a higher data layer of the modem stack 406 may be referred to as service data units (SDUs) in a given layer and packets transferred to/from a lower layer of the modem stack 406 may be referred to as protocol data units (PDUs) .
  • SDUs service data units
  • PDUs protocol data units
  • the packets received into the RLC layer 408 from the PDCP layer 407, as well as the packets transferred from the RLC layer 408 to the PDCP layer 407 may be referred to as RLC SDUs.
  • the packets received into the RLC layer 408 from the MAC layer 409, as well as the packets transferred from the RLC layer 408 to the MAC layer 409 may be referred to as RLC PDUs.
  • a layer’s SDU may be the next higher layer’s PDU, just as the layer’s PDU may be the next lower layer’s SDU.
  • a PDCP PDU sent to the RLC layer 408 from the PDCP layer 407 may be referred to as an RLC SDU upon receipt by the RLC layer 408.
  • a MAC SDU sent from the MAC layer 409 to the RLC layer 408 may be referred to as an RLC PDU upon receipt by the RLC layer 408.
  • Layers within the protocol stack may convert PDUs to SDUs and SDUs to PDUs by performing on the packets various operations assigned to that layer.
  • an RLC SDU may be segmented by the RLC layer 408 to cover the RLC SDU into one or more RLC PDUs.
  • a plurality of received RLC PDUs may be reordered and reassembled to covert the plurality of received RLC PDUs to an RLC SDU.
  • a layer may add data to a packet to covert an SDU to a PDU or a layer may remove data from a packet to convert a PDU to an SDU.
  • an RLC layer 408 may add a packet header/footer to an RLC SDU to convert the RLC SDU to an RLC PDU.
  • an RLC layer 408 may remove a packet header/footer from an RLC PDU to covert the RLC PDU to an RLC SDU.
  • the following is an example of packet handling when one communication device 401 transmits a communication that is received by another communication device 415.
  • An application of the higher data layer 402 of the transmitting communication device 401 may generate a packet of a message 420 for transmission to an application 403 of the receiving communication device.
  • the packet of the message 420 may be sent from the higher data later 401 to the PDCP layer 407 of the modem stack 406 on the transmitting communication device 401.
  • the PDCP layer 407 may receive the packet of the message 420 as a PDCP SDU and convert the PDCP SDU to a PDCP PDU 421.
  • the PDCP layer 407 may transfer the PDCP PDU 421 to the lower RLC layer 408.
  • 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) to one or more RLC PDUs 422 by, for example, adding an RLC packet header/footer and/or applying segmentation.
  • segmentation to split the RLC SDU into multiple RLC PDUs 422 may be needed when the RLC SDU (i.e., the PDCP PDU 421) is larger than a maximum RLC PDU size.
  • each created RLC PDU 422 may be associated with a single RLC SDU (i.e., a single PDCP PDU 421) .
  • the RLC layer 408 may add sequence numbers to the one or more RLC PDUs 422.
  • the sequence numbers may indicate an ordering of the one or more RLC PDUs 422.
  • the RLC layer 408 may transfer the one or more RLC PDUs 422 to the lower MAC layer 409.
  • the MAC layer 409 may receive the one or more RLC PDUs 422 as one or more MAC SDUs.
  • the MAC layer 409 may convert the one or more MAC SDUs (i.e., the one or more RLC PDUs 422) to one or more MAC PDUs 424.
  • the MAC layer 409 may convert the one or more MAC SDUs (i.e., the one or more RLC PDUs 422) by adding HARQ indicators to the MAC SDU (i.e., the one or more RLC PDUs 422) to support HARQ operations.
  • the MAC layer 409 may transfer the one or more MAC PDUs 424 to the lower PHY layer 410
  • the PHY layer 410 may receive the one or more MAC PDUs as one or more PHY SDUs.
  • the PHY layer 410 may convert the one or more PHY SDUs (i.e., the one or more MAC PDUs 424) to a PHY PDU bitstream for transmission as a flow 426 to the receiving communication device 415.
  • the flow 426 between the communication devices 401, 415 may occur as part of direct communications over the PC5 interface.
  • the PHY layer 410 of the receiving communication device 415 may receive the PHY PDU bitstream flow 426 and convert the PHY PDU bitstream flow 426 to one or more PHY SDUs 428.
  • the PHY layer 410 may transfer the one or more PHY SDUs 428 to the higher MAC layer 409
  • the MAC layer 409 may receive the one or more PHY SDUs 428 as one or more MAC PDUs.
  • the MAC layer 409 may convert the one or more MAC PDUs (i.e., one or more PHY SDUs 428) to one or more MAC SDUs 430. Additionally, the MAC layer 409 may perform HARQ operations (e.g., acknowledgements, retransmission requests, etc. ) and remove HARQ data from the MAC PDUs.
  • the MAC layer 409 may transfer the one or more MAC SDUs 430 to the higher RLC layer 408.
  • the RLC layer 408 may receive the one or more MAC SDUs 430 as one or more RLC PDUs.
  • the RLC layer 408 may convert the one or more RLC PDUs (i.e., the one or more MAC SDUs 430) to a single RLC SDU 432.
  • converting the one or more RLC PDUs (i.e., the one or more MAC SDUs 430) to 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 together, and reordering RLC PDUs as needed.
  • the RLC layer 408 may buffer one or more RLC PDUs in a reception buffer, such as to support reordering, await missing RLC PDUs, etc.
  • the RLC layer 408 may transfer the RLC SDU 432 to the higher PDCP layer 407.
  • 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) to a PDCP SDU 434.
  • the PDCP SDU 434 at the receiving communication device 415 may correspond to the packet of a message 420 originated by the transmitting communication device 401.
  • the PDCP layer 407 may transfer the PDCP SDU 434 to the higher data layer 402 and the application 403.
  • FIG. 5 illustrates a method 500 for V2X direct communication over a PC5 interface according to various embodiments.
  • the method 500 may be performed by a processor of V2X entity, such as a processor of a communication device (e.g., in-vehicle communication device 102, in-vehicle communication device 103, in-vehicle communication device 202, SIP 300, communication devices 401, 415, communication device 105, etc. ) and/or traffic sensors 106, 107.
  • a communication device e.g., in-vehicle communication device 102, in-vehicle communication device 103, in-vehicle communication device 202, SIP 300, communication devices 401, 415, communication device 105, etc.
  • traffic sensors 106 e.g., traffic sensors 106, 107.
  • the processor may perform operations including monitoring the PC5 interface for transmissions from remote entities. Monitoring may include parsing IP packets received over the PC5 interface for information contained in those IP packets, such as the src-id of the IP packets, priority of the IP packets, destination identifier of the IP packets, etc.
  • a V2X entity may monitor the PC5 interface by parsing PDUs received over the PC5 interface and passed from a Layer 1 level of the stack architecture of the V2X entity to a Layer 2 level in the stack architecture of the V2X entity.
  • a PDU received over the PC5 interface may be parsed to determine the src-id used by the remote entity (e.g., another V2X entity, etc.
  • the priority assigned to the PDU by the remote entity e.g., a V2X entity, etc.
  • the destination identifier assigned to the PDU by the remote entity e.g., another V2X entity, etc.
  • any other type of information that may be contained in the PDU
  • the processor may perform operations including determining whether any transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity.
  • the V2X entity monitoring the PC5 interface may have previously assigned itself a src-id and that previously assigned src-id may be stored in a memory location available to the V2X entity for use as the V2X entity’s current src-id.
  • the V2X entity may determine whether any transmission from a remote entity (e.g., another V2X entity, etc.
  • the comparison between the src-id in a PDU received over the PC5 interface to the V2X entity’s own stored currently assigned src-id may be performed at a Layer 2 level in the stack architecture of the V2X entity.
  • a match between the src-id in a PDU received over the PC5 interface to the V2X entity’s stored currently assigned src-id may indicate the remote entity (e.g., another V2X entity, etc. ) that sent the PDU is using the same src-id as the V2X entity’s own stored currently assigned src-id.
  • Two entities using the same src-id for communications over the PC5 interface may indicate a src-id conflict is occurring.
  • the src-id in a PDU received over the PC5 interface being different from the V2X entity’s own stored currently assigned src-id may indicate that no src-conflict is occurring.
  • the processor may perform operations including dropping any unsent PDUs associated with an SDU for transmission by the V2X entity in response to determining that any transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity.
  • SDUs may be received from a higher layer (e.g., Layer 3) at middle layer (e.g., Layer 2) of the stack architecture and converted to one or more PDUs for transmission over the PC5 interface by a lower layer (e.g., Layer 1) of the stack architecture of the V2X entity.
  • the one or more PDUs may be buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface.
  • the one or more PDUs may be undergoing further processing in preparation for transmission, may be being buffered in a transmission queue buffer, etc.
  • Such PDUs that are buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface may be unsent PDUs. These unsent PDUs may already include the src-id currently being used by the V2X entity.
  • Sending these unsent PDUs including the src-id currently being used by the V2X entity may result in further conflicts with transmissions by the other remote entity using that same src-id.
  • the V2X entity may drop the unsent PDUs to prevent such conflicts from occurring on the PC5 interface.
  • the dropping of the unsent PDUs may prevent processing resources and radio resources from being expended on PDUs that will likely be discarded by an entity that receives the PDUs due to src-id conflicts.
  • the processor may perform operations including assigning a new different src-id in response to determining that any transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity. Ensuring the newly assigned src-id is different than the previously assigned src-id may ensure the new different src-id does not conflict with the src-id of the remote entity (e.g., another V2X entity, etc. ) .
  • the assignment of the new different src-id may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • the processor may perform operations including converting the SDU for transmission by the V2X entity into one or more new PDUs having the new different source identifier.
  • new PDUs including the new different source identifier may be created from the same SDU for transmission over the PC5 interface.
  • the retransmission of the IP packets corresponding to the SDU may be accomplished using the one or more new PDUs and any receiving device may not experience a src-id conflict because the src-ids in the one or more new PDUs are different from the previously assigned src-id.
  • the operations to convert the SDU to one or more new PDUs may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • the processor may perform operations including sending the one or more new PDUs via the PC5 interface.
  • the operations to send the one or more new PDUs via the PC5 interface may be performed at a Layer 1 level in a stack architecture of the V2X entity.
  • the one or more new PDUs may no longer conflict with the PDUs sent by the remote entity (e.g., another V2X entity, etc. ) as the src-id in use by that remote entity (e.g., another V2X entity, etc. ) may not match the new different src-id written into the one or more new PDUs.
  • FIG. 6 is a process flow diagram illustrating a method for V2X direct communication over a PC5 interface according to various embodiments.
  • the method 600 may be performed by a processor of V2X entity, such as a processor of a communication device (e.g., in-vehicle communication device 102, in-vehicle communication device 103, in-vehicle communication device 202, SIP 300, communication devices 401, 415, communication device 105, etc. ) and/or traffic sensors 106, 107.
  • a communication device e.g., in-vehicle communication device 102, in-vehicle communication device 103, in-vehicle communication device 202, SIP 300, communication devices 401, 415, communication device 105, etc.
  • traffic sensors 106 e.g., traffic sensors 106, 107.
  • the processor may perform operations including monitoring the PC5 interface for transmissions from remote entities as described with reference to like numbered block of method 500 (FIG. 5) .
  • the processor may perform operations including determining whether a transmission from a remote entity has a same src-id as a src-id currently being used by the V2X entity as described with reference to like numbered block of method 500 (FIG. 5) .
  • the processor may perform operations including determining whether the transmission from the remote entity has a same priority and same destination identifier as a priority and a destination identifier assigned to any unsent PDUs associated with an SDU for transmission from the V2X entity in response to determining that the transmission from the remote entity has the same src-id as the src-id currently being used by the V2X entity.
  • SDUs may be received from a higher layer (e.g., Layer 3) at middle layer (e.g., Layer 2) of the stack architecture and converted to one or more PDUs for transmission over the PC5 interface by a lower layer (e.g., Layer 1) of the stack architecture of the V2X entity.
  • the one or more PDUs may be buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface.
  • the one or more PDUs may be undergoing further processing in preparation for transmission, may be being buffered in a transmission queue buffer, etc.
  • Such PDUs that are buffered or otherwise held for some period of time by the V2X entity prior to being sent via the PC5 interface may be unsent PDUs. These unsent PDUs may already include the src-id currently being used by the V2X entity.
  • unsent PDUs may include a priority assigned to the PDUs and a destination identifier.
  • the priority may indicate the relative importance of the transmission.
  • the destination identifier may indicate the communication device to which the unsent PDUs are addressed. Sending these unsent PDUs including the src-id currently being used by the V2X entity with the same priority and same destination identifier may result in further conflicts with transmissions by the other remote entity (e.g., another V2X entity, etc. ) using that same src-id, same priority, and same destination identifier.
  • the PDUs having different priorities and/or different may not cause a conflict with transmissions by the remote entity (e.g., another V2X entity, etc. ) .
  • the comparison between the priority and destination identifier in a PDU received over the PC5 interface to the V2X entity’s unsent PDUs may be performed at a Layer 2 level in the stack architecture of the V2X entity.
  • a match between the priority and the destination identifier in a PDU received over the PC5 interface to the priority and the destination identifier of the V2X entity’s unsent PDUs may indicate the remote entity (e.g., another V2X entity, etc. ) that sent the PDU is using the same priority and the same destination identifier as the V2X entity’s own unsent PDUs.
  • Two entities using the same src-id, same priority, and same destination ID for communications over the PC5 interface may indicate a src-id conflict is occurring and a receiving communication device may be unable to resolve the conflict between such PDUs.
  • the priority and the destination identifier in a PDU received over the PC5 interface being different from those of the unsent PDUs of the V2X entity may indicate that even though a src-conflict is occurring a receiving communication device may be able to resolve the conflict because the different priorities and different destination identifiers may enable the receiving communication device to distinguish the PDUs as originating from different sources despite the same src-id being used in the PDUs.
  • the processor may perform operations including dropping the unsent PDUs in response to determining that the transmission from the remote entity has the same priority and the same destination identifier as the priority and the destination identifier assigned to the protocol data units.
  • the V2X entity may drop the unsent PDUs to prevent src-id conflicts from occurring on the PC5 interface.
  • the dropping of the unsent PDUs may prevent processing resources and radio resources from being expended on PDUs that will likely be discarded by an entity that receives the PDUs due to src-id conflicts.
  • the processor may perform operations including assigning a new different src-id in response to determining that the transmission from the remote entity has the same priority and the same destination identifier as the priority and the destination identifier assigned to the protocol data units. Ensuring the newly assigned src-id is different than the previously assigned src-id may ensure the new different src-id does not conflict with the src-id of the remote entity (e.g., another V2X entity, etc. ) even though the priority and the destination identifier may remain the same.
  • the assignment of the new different src-id may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • the processor may perform operations including converting the SDU for transmission by the V2X entity into one or more new PDUs having the new different src-id the same priority and the same destination identifier.
  • new PDUs including the new different source identifier may be created from the same SDU for transmission over the PC5 interface.
  • the new PDUs may include the new different src-id along with the same priority and the same destination identifier as the dropped PDUs.
  • the retransmission of the IP packets corresponding to the SDU may be accomplished using the one or more new PDUs and any receiving device may not experience a src-id conflict because the src-ids in the one or more new PDUs are different from the previously assigned src-id.
  • the operations to convert the SDU to one or more new PDUs may be performed at a Layer 2 level in a stack architecture of the V2X entity.
  • the processor may perform operations including sending the one or more new PDUs via the PC5 interface as described with reference to like numbered block of method 500 (FIG. 5) .
  • a smartphone 700 may include a first SoC 702 (e.g., a SoC-CPU) coupled to a second SoC 724 (e.g., a 5G capable SoC) and a third SoC 716 (e.g., a C-V2X SoC configured for managing V2V, V2I, and V2P communications over D2D links, such as D2D links establish in the dedicated ITS 5.9 GHz spectrum communications, D2D links over the PC5 interface, etc) .
  • SoC 702 e.g., a SoC-CPU
  • second SoC 724 e.g., a 5G capable SoC
  • a third SoC 716 e.g., a C-V2X SoC configured for managing V2V, V2I, and V2P communications over D2D links, such as D2D links establish in the dedicated ITS 5.9 GHz spectrum communications, D2D links over the PC5 interface, etc
  • the first, second, and/or third SoCs 702, 724, and 716 may be coupled to internal memory 706, a display 712, and to a speaker 714. Additionally, the smartphone 700 may include one or more antenna 704 for sending and receiving electromagnetic radiation that may be connected to one or more transceiver 708 (e.g., a wireless data link and/or cellular transceiver, etc. ) coupled to one or more processors in the first, second, and/or third SoCs 702, 724, and 716. Smartphones 700 typically also include menu selection buttons or rocker switches 720 for receiving user inputs.
  • transceiver 708 e.g., a wireless data link and/or cellular transceiver, etc.
  • a typical smartphone 700 also includes a sound encoding/decoding (CODEC) circuit 710, which digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes received sound data packets to generate analog signals that are provided to the speaker to generate sound.
  • CODEC sound encoding/decoding
  • one or more of the processors in the first, second, and/or third SoCs 702, 724, and 716, transceiver 708 and CODEC circuit 710 may include a digital signal processor (DSP) circuit (not shown separately) .
  • DSP digital signal processor
  • the processors implementing various embodiments may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various aspects described in this application.
  • multiple processors may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications.
  • software applications may be stored in the internal memory (e.g., memory 706) before they are accessed and loaded into the processor.
  • the processor may include internal memory sufficient to store the application software instructions.
  • a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a processor of a communication device and the communication device may be referred to as a component.
  • One or more components may reside within a process and/or thread of execution and a component may be localized on one processor or core and/or distributed between two or more processors or cores. In addition, these components may execute from various non-transitory computer readable media having various instructions and/or data structures stored thereon. Components may communicate by way of 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 methodologies.
  • Such services and standards may include, e.g., third generation partnership project (3GPP) , long term evolution (LTE) systems, 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) systems (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
  • 3GPP third generation partnership project
  • LTE long term evolution
  • 4G fourth generation wireless mobile communication technology
  • 5G fifth generation wireless
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.
  • 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 code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium.
  • the operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium.
  • Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor.
  • non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer.
  • Disk and disc includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor- readable media.
  • 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 computer-readable storage medium, which may be incorporated into a computer program product.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention porte, dans divers modes de réalisation, sur des procédés et sur des dispositifs qui permettent des communications de véhicule à tout (V2X) sur une interface PC5 comprenant la retransmission de paquets IP avec un nouvel identifiant de source (src-id) lorsqu'un conflit src-id est détecté. Des modes de réalisation consistent à surveiller l'interface PC5 pour des transmissions, à déterminer si une transmission quelconque possède un même src-id que le src-id qui est utilisé par l'entité V2X, à abandonner toutes les unités de données de protocole (PDU) non envoyées d'une unité de données de service (SDU) pour une entité de transmission à la suite de la détermination qu'une transmission à partir d'une entité distante possède un même src-id que le src-id qui est utilisé par l'entité V2X, à attribuer un nouveau src-id différent à la suite de la détermination qu'une transmission à partir d'une entité distante possède un même src-id que le src-id qui est utilisé par l'entité V2X, à convertir l'unité SDU pour une transmission par l'entité V2X en de nouvelles unités PDU ayant le nouveau src-id, et à envoyer les nouvelles unités PDU par le biais de l'interface PC5.
PCT/CN2019/102334 2019-08-23 2019-08-23 Retransmission de l'ensemble du paquet ip lors de la détection d'un conflit d'id source dans v2x WO2021035433A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/102334 WO2021035433A1 (fr) 2019-08-23 2019-08-23 Retransmission de l'ensemble du paquet ip lors de la détection d'un conflit d'id source dans v2x

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/102334 WO2021035433A1 (fr) 2019-08-23 2019-08-23 Retransmission de l'ensemble du paquet ip lors de la détection d'un conflit d'id source dans v2x

Publications (1)

Publication Number Publication Date
WO2021035433A1 true WO2021035433A1 (fr) 2021-03-04

Family

ID=74683392

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/102334 WO2021035433A1 (fr) 2019-08-23 2019-08-23 Retransmission de l'ensemble du paquet ip lors de la détection d'un conflit d'id source dans v2x

Country Status (1)

Country Link
WO (1) WO2021035433A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108029072A (zh) * 2015-09-24 2018-05-11 株式会社Ntt都科摩 用户装置、基站、通信方法及通知方法
WO2018149265A1 (fr) * 2017-02-20 2018-08-23 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil de commande de liaison latérale

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108029072A (zh) * 2015-09-24 2018-05-11 株式会社Ntt都科摩 用户装置、基站、通信方法及通知方法
WO2018149265A1 (fr) * 2017-02-20 2018-08-23 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil de commande de liaison latérale

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CATT: "Evaluation results of PC5-based V2V", 3GPP DRAFT; R1-162268, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG1, no. Busan; 20160411 - 20160415, 2 April 2016 (2016-04-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP051080073 *
HUAWEI, HISILICON: "Analysis on resource allocation for PC5 CA", 3GPP DRAFT; R2-1712752 ANALYSIS ON RESOURCE ALLOCATION FOR PC5 CA, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20171127 - 20171201, 17 November 2017 (2017-11-17), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP051371655 *
INTEL CORPORATION: "Considerations on Layer-2 Destination ID", 3GPP DRAFT; R2-1906297_NR_V2X_PC5_DESTID_INTEL, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20190513 - 20190517, 13 May 2019 (2019-05-13), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP051729764 *

Similar Documents

Publication Publication Date Title
US20230008624A1 (en) Road side unit message scheduling and congestion control
US20210266923A1 (en) Generating Resource Allocation Coordination Information for Sidelink Communications
US11876719B2 (en) Systems and methods for managing transmission control protocol (TCP) acknowledgements
US11985695B2 (en) Generating coordination information for sidelink communications
EP4158878B1 (fr) Réalisation des couches supérieures d'unicast pour c-v2x
US20220279399A1 (en) User equipment (ue) mobility history information management
WO2021147690A1 (fr) Systèmes et procédés pour répondre à une condition d'exposition admissible maximale
US11523301B2 (en) Physical uplink control channel with buffer status report
WO2021035433A1 (fr) Retransmission de l'ensemble du paquet ip lors de la détection d'un conflit d'id source dans v2x
US11533613B2 (en) Providing secure communications between computing devices
EP4158472B1 (fr) Traitement de données à l'aide de ressources informatiques de réseau à distance
WO2023029013A1 (fr) Dispositifs de communication et procédés de concaténation d'unités de données de service
US11949510B2 (en) Hardware-based dynamic cyclic-redundancy check (CRC) generator for automotive application
US11895036B2 (en) Managing acknowledgement packets in an uplink data packet stream
US20240237052A1 (en) Generating coordination information for sidelink communications
WO2021243547A1 (fr) Gestion de communication de protocole de commande de transmission avec un réseau de communication
US20230403732A1 (en) Managing Downlink Traffic Reception And Cross-Link Interference

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19943785

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19943785

Country of ref document: EP

Kind code of ref document: A1