Method performed by a source device, source device, and medium

Abstract

Embodiments of the present disclosure relate to aggregating messages into a single transmission. In some examples, a source device classifies a plurality of messages for transmission to a recipient device, the plurality of messages including vehicle-related information. Based on the classification, the source device identifies selected messages of the plurality of messages to be aggregated. The source device aggregates the selected messages into a single transmission from the source device to the recipient device.

Description

[0001] This application is a divisional application of the invention patent application filed on October 14, 2020, with Chinese national application number 202011099367.5 and entitled "Aggregating Messages into a Single Transmission". Technical Field

[0002] Embodiments of this disclosure relate to aggregating messages into a single transmission. Background Technology

[0003] Electronic devices can communicate via wired or wireless networks. Wireless networks can include wireless local area networks (WLANs), which include wireless access points (APs) that devices can wirelessly connect to. Other types of wireless networks include cellular networks, which include wireless access network nodes that devices can wirelessly connect to.

[0004] Electronic devices can transmit data from multiple sources, both inside and / or outside the electronic device. Summary of the Invention

[0005] According to one aspect of this disclosure, a method performed by a source device is provided. The method includes: classifying a plurality of messages for transmission to a receiving device, the plurality of messages including transportation-related information; identifying selected messages among the plurality of messages to be aggregated based on the classification; and aggregating the selected messages into a single transmission from the source device to the receiving device.

[0006] According to another aspect of this disclosure, a receiving device is provided. The receiving device includes: a communication interface for communicating over a network; and at least one processor configured to: receive aggregated data from a source device via the communication interface, the aggregated data including multiple messages aggregated by the source device into a single transmission, the multiple messages including vehicle-related information; determine the priority of the multiple messages in header information of the aggregated data; and transmit the multiple messages according to the determined priority.

[0007] According to another aspect of this disclosure, a non-transient machine-readable storage medium is provided, comprising instructions. Upon execution, the instructions instruct a source device to: classify a plurality of messages intended for transmission to a receiving device, the plurality of messages including vehicle-related information; identify selected messages among the plurality of messages to be aggregated based on the classification; and aggregate the selected messages into a single transmission from the source device to the receiving device. Attached Figure Description

[0008] Some implementations of this disclosure are described with reference to the following figures.

[0009] Figure 1A This is a block diagram of an example communication arrangement based on some implementations of this disclosure;

[0010] Figure 1B This is a flowchart of a process executed by a source device according to some implementations of this disclosure;

[0011] Figure 2 The following examples illustrate various message groups containing information related to transportation.

[0012] Figure 3 This is a block diagram of components in a vehicle for performing message classification and aggregation according to some implementations of this disclosure;

[0013] Figure 4 This is a schematic diagram based on some examples for aggregating Media Access Control (MAC) Protocol Data Units (MPDUs) into an aggregated MPDU (A-MPDU);

[0014] Figure 5 and Figure 6 This is a flowchart of an example process for aggregating messages based on some implementations of this disclosure; and

[0015] Figure 7 This is a block diagram of a device based on some examples of this disclosure.

[0016] In all the accompanying drawings, the same reference numerals denote similar but not necessarily identical elements. The drawings are not necessarily drawn to scale, and some parts may be enlarged to more clearly illustrate the examples shown. Furthermore, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. Detailed Implementation

[0017] In this disclosure, unless the context clearly indicates otherwise, the use of the terms “a,” “an,” or “the” is also intended to include the plural form. Similarly, when used in this disclosure, the terms “comprising,” “including,” “containing,” “having,” “having,” or “comprising” specify the presence of the said element, but do not exclude the presence or addition of other elements.

[0018] Table 1 below lists the descriptions of acronyms or abbreviations used in this specification.

[0019] Table 1

[0020]

[0021]

[0022] Vehicles may be equipped with communication components to allow them to communicate with each other, with networks or other service infrastructure, or with other devices. Examples of information that can be transmitted or received by a vehicle may include data collected by sensors, traffic information, status information, etc.

[0023] Examples of vehicles include motorized vehicles (e.g., cars, automobiles, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aerial vehicle systems, drones, helicopters, etc.), spacecraft (e.g., space shuttles, spacecraft, space stations, satellites, etc.), ships (e.g., vessels, ships, hovercraft, submarines, etc.), rail vehicles (e.g., trains and trams, etc.), pedestrians and bicycles, and other types of vehicles including any combination of any of the above (whether currently existing or emerging in the future).

[0024] Vehicle-to-Everything (V2X) is a feature that provides information communication from a vehicle to other entities that may affect the vehicle and / or other entities (and / or vice versa). V2X includes one or more features in a subset of features, including communication to / from vehicles in any combination or some combination of the following: other vehicles (vehicle-to-vehicle communication or V2V communication); infrastructure, such as roadside units (RSUs) (vehicle-to-infrastructure or V2I communication); pedestrians (vehicle-to-pedestrian or V2P communication); networks (vehicle-to-network or V2N communication); devices, such as electronic devices within a vehicle (vehicle-to-device or V2D communication), power grids (vehicle-to-grid or V2G communication); and so on.

[0025] V2X communication can also include transmissions from the RSU to other entities, including vehicles or other entities. An RSU can refer to any device, including a roadside radio (or other wireless interface) placed to receive messages and transmit them to vehicles. In the United States, RSU specifications may include the Dedicated Short Range Communication (DSRC) Roadside Unit (RSU) Specification Document Version 4.1 (or other versions). In other examples, the RSU may operate according to other standards or using proprietary specifications.

[0026] More generally, V2X communication can include any communication of vehicle-related information from a source device to one or more receiving devices. “Vehicle-related information” can refer to information including data relating to the vehicle or the infrastructure supporting the vehicle (e.g., RSU, traffic lights, traffic signs, etc.); control information affecting the operation of the vehicle or the infrastructure supporting the vehicle; navigation data; and any other information directly or indirectly associated with the vehicle.

[0027] Networks supporting V2X communication can include cellular networks or another type of wireless network. Example cellular networks can operate according to the Long Term Evolution (LTE) standard provided by the 3rd Generation Partnership Project (3GPP). The LTE standard is also known as the Evolved Universal Terrestrial Radio Access (E-UTRA) standard. In other examples, other types of cellular networks can be used, such as second-generation (2G) or third-generation (3G) cellular networks, for example, Global System for Mobile Systems (GSM) cellular networks, Enhanced GSM Data Rate Evolution (EDGE) cellular networks, Universal Terrestrial Radio Access Network (UTRAN), Code Division Multiple Access (CDMA) 2000 cellular networks, etc. In other examples, the cellular network can be a fifth-generation (5G) or higher version of cellular network.

[0028] Other types of wireless networks may include wireless local area networks (WLANs) that operate according to IEEE 802.11 standards (e.g., Dedicated Short Range Communications (DSRC)), IEEE 802.11a, IEEE 802.11p, IEEE 802.11bd (e.g., an enhancement to next-generation V2X), Integrated Digital Enhanced Network (iDEN), and the like.

[0029] In some examples, the RSU can have two main operating modes. In the first operating mode, the RSU can communicate with vehicles via, for example, a single-hop networking technology defined in the IEEE 1609.3 standard (called the WAVE short message protocol (WSMP)). In the second operating mode, the RSU can act as a network access node that routes packets such as Internet Protocol (IP) packets (e.g., IPv6 packets) to the backhaul network.

[0030] The following discussion involves some examples of the first operating mode of the RSU.

[0031] In other examples, the techniques or mechanisms according to this disclosure can be used with RSUs operating in other modes or with any other type of equipment that transmits vehicle-related information, such as in V2X communications.

[0032] The RSU can receive vehicle-related information from multiple sources for transmission over a network (wireless or wired) to one or more vehicles or other receiving devices. The RSU can be part of a larger device, such as a roadside electronic cabinet. Sources can include internal sources within the device containing the RSU (or sources within the RSU). Alternatively, sources can include external sources outside the device containing the RSU (or outside the RSU). Internal sources can include applications, hardware components, etc. External sources can include a Traffic Management Center (TMC) connected to the RSU via a backhaul network. The TMC can send messages to the RSU for transmission over the wireless network. Other examples of external sources that can provide messages to the RSU.

[0033] In addition to the RSU, the vehicle may also receive vehicle-related information from multiple sources for transmission to another entity, which may include internal sources (e.g., electronic control units (ECUs) and / or external sources (e.g., user equipment from passengers and / or the vehicle driver).

[0034] Generally, a device that can transmit messages from one or more sources (whether internal or external) can be referred to as a "source device".

[0035] question

[0036] When a message is received in the transmission queue of a source device, the source device may be inefficient in transmitting locally or remotely generated messages at once. For example, transmitting multiple messages at once may not efficiently utilize communication resources, such as radio resources or other network resources. For instance, a message transmitted over a network may not fully occupy the data frame carrying the message, wasting the communication resources used by that data frame. As another example, delay-intolerant messages may be delayed, or delay-tolerant messages may be transmitted before delay-intolerant messages. Furthermore, if the source device waits for the next message to aggregate messages into a data frame before sending the currently queued message, there may be time intervals between messages, which could lead to unacceptable delays in the transmission of the currently queued message.

[0037] A source device can enqueue messages from multiple sources for transmission over the network. The term "enqueueing" refers to the action of receiving messages for further transmission. Messages can be enqueued into a single queue or multiple queues.

[0038] Message enqueueing may be inconsistent because the source device may not correctly identify the message type or the type of the source that generated the message. As a result, the transmission of messages that have already been enqueued may be inefficient.

[0039] Based on the examples implemented in this disclosure

[0040] According to some implementations of this disclosure, the source device can classify the messages to be transmitted and arrange the classified messages so that the transmission of messages utilizes communication resources more efficiently. In some examples, mixed-category messages can be aggregated into a single transmission, so that mixed-category messages can be transmitted together. As used herein, "single transmission" can refer to an "aggregated data frame" or a single transmission opportunity (TXOP). An "aggregated data frame" is a data frame in which multiple messages are combined, so that a data frame carrying multiple messages can be transmitted over the network. A "data frame" can refer to any data unit that can be transmitted and identified individually and can be carried by the communication resources of the network. A TXOP refers to a time interval or any other communication resource that can be allocated to the source device for transmitting information; the source device may not be able to transmit information outside of a TXOP.

[0041] In some examples according to this disclosure, a receiving device may receive aggregated messages and unpack (de-aggregate) the aggregated messages into individual messages for forwarding to one or more recipients. A “recipient” can refer to a program, machine, user, or any other entity, whether inside or outside the receiving device.

[0042] Figure 1A This is a block diagram of the communication arrangement including roadside electronic cabinet 102, TMC 104, and vehicle 106. Note that in other examples, there may be multiple roadside electronic cabinets and / or multiple vehicles and / or multiple TMCs.

[0043] In some examples, the roadside electronic cabinet 102 includes an RSU 108 with a communication interface 110 that allows the RSU 108 to communicate with vehicles 106 (or more vehicles) via a wireless network (also known as OTA or over-the-air). The wireless network may include a cellular network, WLAN, or any other type of wireless network.

[0044] A “communication interface” can refer to a collection of components that allow a device to communicate over a network. For example, a communication interface may include a radio transceiver (or other type of wireless transceiver) for transmitting and receiving signals over a network. Additionally, a communication interface may include a protocol layer, which is part of a protocol stack that allows the device to transmit information over a network according to one or more protocols, such as any protocols discussed in this specification.

[0045] For example, the communication interface 110 can communicate according to any of the following: DSRC, 5GHz Smart Enabled System (ITS-G5); LTE-V2X via PC5 Mode 4; etc.

[0046] Although only one communication interface 110 is shown as Figure 1A It is part of RSU 108, but it should be noted that RSU 108 may include multiple external interfaces, including a local interface with components (e.g., 114) in the roadside electronic cabinet 102; a backhaul interface with TMC 104 (or other devices or systems); and a communication interface 108.

[0047] RSU 108 includes an aggregation engine 112 for aggregating messages. As used herein, "message" can refer to any unit of data that can be generated by the source.

[0048] As used herein, "engine" can refer to hardware processing circuitry, which may include any combination or some combination of the following: microprocessor, core of a multi-core microprocessor, microcontroller, programmable integrated circuit, programmable gate array, digital signal processor, or other hardware processing circuitry. Alternatively, "engine" can refer to a combination of hardware processing circuitry and machine-readable instructions (software and / or firmware) executable on the hardware processing circuitry.

[0049] RSU 108 can receive messages from various sources. For example, one source is signal controller 114, which is part of roadside electronic cabinet 102. Signal controller 114 can be used to control traffic lights, such as at intersections of multiple roads.

[0050] Another source that can provide messages to RSU 108 is TMC 104, which transmits messages to curbside electronic cabinet 102 via backhaul network 116 (e.g., cellular network, WLAN, fiber optic network, etc.).

[0051] Other sources may also exist, typically referred to as source 118. For example, another source may include a device for generating mapping data, such as for navigation purposes. Although not shown, sources may also exist within RSU 108, such as programs executed by RSU 108.

[0052] RSU 108 includes one or more queues 120 for enqueuing messages received from various sources, including, for example, signal controller 114, TMC 104, and source 118. A “queue” can refer to any storage device that can be implemented using one or more volatile memory devices and / or one or more non-volatile memory devices.

[0053] Vehicle 106 includes a communication interface 122 for communicating with RSU 108 via a network. Additionally, vehicle 106 includes a de-aggregation engine 124 for de-aggregating aggregated messages (sent by RSU 108) at vehicle 106 after receiving aggregated messages from RSU 108. An "aggregated message" can refer to multiple aggregated messages aggregated into a single transmission, such as a single aggregated data frame or a single TXOP.

[0054] Despite Figure 1A The vehicle 106 may also include a aggregation engine similar to aggregation engine 112, and the RSU 108 may include a deaggregation engine similar to deaggregation engine 124.

[0055] Figure 1B It is a flowchart of a process that can be performed by a source device such as RSU 108, vehicle 106 or any other type of source device.

[0056] The source device categorizes multiple messages (in 150) for transmission to the receiving device, where multiple messages include transportation-related information.

[0057] Based on classification, the source device identifier (in 152) is the selected message to be aggregated from multiple messages.

[0058] The source device may aggregate selected messages (in 154) into a single transmission (e.g., a single aggregated data frame or a single TXOP) from the source device to the receiving device via the aggregation engine 112.

[0059] In some examples, the classification of multiple messages includes identifying delay-allowed messages and delay-non-allowed messages, and the process can delay the transmission of the delay-allowed message to allow the delay-allowed message to be aggregated with other messages (delay-allowed messages or delay-non-allowed messages).

[0060] In some examples, the classification of multiple messages includes identifying periodic and non-periodic messages. Aggregating selected messages into a single transmission may include aggregating at least one periodic message with at least one non-periodic message or another periodic message.

[0061] In some examples, the process can determine the scheduling time for the transmission of the first periodic message, and the scheduling time can be used to select the first periodic message for aggregation into a single transmission with another message.

[0062] In some examples, aggregating messages into aggregated data frames can include one of the following types of frame aggregation as defined by the IEEE 802.11-2016 standard: aggregated MAC Service Data Unit (A-MSDU) aggregation or aggregated MAC Protocol Data Unit (A-MPDU) aggregation. Both types of frame aggregation group several data frames into a larger frame. Because each frame specifies management information only once, the payload data to total data ratio is higher, thus allowing for higher communication throughput when frame aggregation is performed.

[0063] Packing multiple frames into a single transmission results in a longer transmission (as opposed to a transmission that includes only a single data frame), but reduces inter-frame time gaps and other overhead.

[0064] MSDU aggregation collects Ethernet frames destined for a single destination or group-addressed destination and encapsulates the Ethernet frames within a single IEEE 802.11 frame. This is efficient because the Ethernet header is much shorter than the IEEE 802.11 header. An A-MSDU contains only MSDUs whose destination address (DA) and transmitter address (SA) parameter values ​​are mapped to the same receiver address (RA) and transmitter address (TA) values; that is, all MSDUs are intended to be received by a single receiver and all MSDUs are transmitted by the same transmitter.

[0065] Note that within the same A-MSDU subframe header, there may be different DA and SA parameter values, as long as they all map to the same address 1 and address 2 parameter values.

[0066] MPDU aggregation (A-MPDU) also collects Ethernet frames to be transmitted to a single destination, but each frame still contains its own IEEE 802.11 MAC header within the encapsulated A-MPDU. Typically, this is less efficient than MSDU aggregation, but it is actually more efficient in environments with high error rates due to a mechanism called "selective block acknowledgment." Selective block acknowledgment allows each aggregated data frame to be individually acknowledged or retransmitted if affected by errors.

[0067] Classified and aggregated messages

[0068] Messages can be categorized into the following example categories, including those based on transmission cadence and those based on latency tolerance. While specific categories are mentioned in the described examples, note that other message categories may be used in other examples.

[0069] Transmission rhythm categories include periodic and random categories. Periodic messages (messages that conform to the periodic category) have a predictable rhythm because they are sent periodically or intermittently at each specified or planned interval.

[0070] Examples of periodic category messages include: “Storage and Repetition” in the USDOT specification for DSRC roadside units; “SPS Stream” in 3GPP TS 36.321 Release 14, where “SPS” stands for “Semi-Persistent Scheduling”; “BSM Part I” in SAE J2945 / 1, where “BSM” stands for “Basic Safety Information”; and so on.

[0071] Messages that fall under the random category include messages generated at an unpredictable pace or one-off messages. Examples of messages that fall under the random category include "Immediate Transmission" in the USDOT Dedicated Short Range Communication Roadside Unit Specification; "Single Transmission" in 3GPP TS36.321; and "BSM Part II" in SAE J2945 / 1.

[0072] Delay-tolerant categories include delay-intolerant and delay-tolerant categories. Messages that fall under the delay-intolerant category will be transmitted immediately or at a specific time (e.g., periodic messages).

[0073] Delay-tolerant messages are messages that can be delayed (including random or periodic messages) or messages that can be skipped (such as periodic messages).

[0074] Figure 2 This example illustrates how messages can be grouped into one of groups A, B, C, and D based on a combination of transmission rhythm categories (periodic and random) and delay tolerance categories (delay-tolerant and delay-intolerant).

[0075] Periodic and delay-tolerant messages are part of group A, delay-tolerant and random messages are part of group B, periodic and delay-intolerant messages are part of group C, and random and delay-intolerant messages are part of group D.

[0076] In some examples, the aggregation engine (e.g., 112) can identify periodic messages and bundle (aggregate) them into an aggregated data frame. In other examples, the aggregation engine can also bundle random messages with queued periodic messages. In still other examples, the aggregation engine can bundle multiple random messages.

[0077] In some examples, the source generating the message passes additional information to RSU 108 about the message the source is requesting RSU 108 to send. This additional information (metadata) can take the form of an RSU Management Information Base (MIB) extension, which will be discussed further below. In other examples, the additional information (metadata) may include a Provider Service Identifier (PSID) (an identifier in a message from an application or other message source) or a PSID / Service Specific Permission (SSP) combination of a WSMP packet, or an Intelligent Transportation System Application Identifier (ITS-AID), or Ethernet type or other information.

[0078] SSP includes a set of security support procedures that provide more granular control than PSID. PSID or a combination of PSID / SSP can be used as an indicator of one or both of the transmission cadence type and delay tolerance category.

[0079] ITS-AID uniquely identifies a service or application.

[0080] The Ethernet type is used to indicate which protocol is encapsulated in the frame's payload.

[0081] In some examples, the source device maintains a list of known PSIDs and their associated categories, including, for example, the categories described above. Alternatively, the source device may map a list of PSID / SSP combinations to associated categories, or a list of ITS-AIDs to associated categories.

[0082] Additional information associated with a message provided by the source can be used by the aggregation engine to determine the relative priority of messages to be aggregated. For example, the additional information may include header information from which priority can be determined. This header information can be a part of a WSMP header or a data frame header.

[0083] In some examples, the order in which messages are aggregated into the aggregated data frame can be based on the relative priority of the messages. For example, higher-priority messages (e.g., delay-intolerant messages) can be placed before lower-priority messages (e.g., delay-tolerant messages).

[0084] Figure 3 This is a block diagram of components in vehicle 102, according to some implementations of this disclosure, used for performing message classification and aggregation. Typically, Figure 3 An example of an onboard unit (OBU) architecture for a vehicle is shown.

[0085] Vehicle 102 includes various information sources, including basic safety application 302 (implementing various safety features of vehicle 102), platooning or cooperative adaptive cruise control (CACC) application 304 (for performing cruise control on vehicle 102), and safety perception application 306 (for assisting the driver in ensuring safe driving, such as based on the detection of vehicles in blind spots, the detection of objects behind or in front of the vehicle, etc.). Although in Figure 3 An example message source is shown, but note that vehicle 102 may include alternative or additional message sources.

[0086] The message sources in vehicle 102 may be on the same or different central processing units (CPUs) or electronic control units (ECUs), may be on the same or different virtual machines (VMs), or may be different applications.

[0087] Messages from sources 302, 304, and 306 can be enqueued in queue 308 (or multiple queues).

[0088] According to some implementations of this disclosure, the aggregation engine 310 categorizes messages from the source and aggregates selected messages into a single transport based on the categorization.

[0089] In some examples, queue 308 and aggregation engine 310 are part of the V2X radio stack.

[0090] Then, by using the communication interface 122 of the vehicle 102, the aggregated message can be transmitted to another entity, such as Figure 1A RSU 108 or different entities.

[0091] Although not shown, vehicle 102 may also include a deaggregation engine for decompressing (deaggregating) aggregated messages (e.g., a single aggregated data frame or a single TXOP) received in a single transmission.

[0092] Frame aggregation

[0093] As noted above, in some examples, frame aggregation may include A-MSDU aggregation or A-MPDU aggregation. Further details regarding frame aggregation are discussed in U.S. Application No. 16 / 676,835 (Attorney General’s Volume No. 50781-US-PAT), filed November 7, 2019, entitled “Aggregation of Data Frames,” which is incorporated herein by reference.

[0094] In some examples, the techniques discussed in U.S. Application No. 16 / 676,835 can be applied and extended to perform frame aggregation based on application attributes (or more generally, attributes of the source or message category).

[0095] Figure 4 An example of aggregating multiple MPDUs 402, 404, and 406 into an aggregated MPDU 408 is shown. MPDU 402 includes an MSDU, which in turn includes WSMP packets containing Traveler Information Message (TIM) data. MPDU 404 includes an MSDU, which in turn includes WSMP packets containing mapping data. MPDU 406 includes an MSDU, which in turn includes WSMP packets containing Signal Phase and Timing (SPaT) data. Each MPDU 402, 404, and 406 has a channel address and other overhead information.

[0096] Although MPDUs 402, 404, and 406 are shown as carrying specific types of messages, note that in other examples, MPDUs can carry another type of message.

[0097] Once MPDUs 402, 404, and 406 are aggregated into an aggregated MPDU (A-MPDU) 408, the aggregated MPDU includes only one channel access delay and other overhead information, instead of multiple channel access delay and overhead information for MPDUs 402, 404, and 406. This can result in a reduction in the amount of data transmitted over the network (e.g., OTA), which improves the efficiency of communication resource utilization.

[0098] When to aggregate messages

[0099] In some examples, time-sensitive or latency-sensitive messages are transmitted immediately (i.e., without a specified delay), while latency-tolerant or predictable messages are allowed to be queued and subject to additional delays. Latency-tolerant messages can be bundled together or bundled with latency-untolerant messages.

[0100] The message source can use the additional information (metadata) discussed further above to notify the RSU 108 of the message's latency tolerance. This additional information (metadata) can be provided on a per-frame or per-source basis.

[0101] In another example, RSU 108 can also segment messages (e.g., delay-tolerant messages) to allow for more efficient aggregation, such as by packing or padding the aggregated data frame to its maximum frame size. Segmenting a message can mean dividing the message into multiple message fragments, such that one or more message fragments are aggregated together with another message into an aggregated data frame.

[0102] Note that the WSMP currently used in J2735-based applications is not segmentable, but in the future, other segmentable payloads (e.g., Internet Protocol-based or IP-based payloads) may be used.

[0103] Figure 5 An example process for aggregating aperiodic and periodic messages is shown. Figure 5 During the process, RSU control engine 502 (which may be part of RSU 108) sends (in 506) a message A (e.g., in the queue / aggregation engine 504) to queue / aggregation engine 504. Figure 5 The example belongs to the periodic category) and the instructions are used for queuing.

[0104] RSU 108 can determine whether message A belongs to the periodic category based on RSU MIB, PSID, PSID / SSP combination, etc.

[0105] RSU control engine 502 performs control functionality for RSU 108. Queue / aggregation engine 504 includes, for example... Figure 1A The queues and aggregation engines shown.

[0106] Message A is received from a source, such as any source shown in Figure 1.

[0107] The queue / aggregation engine at 504 enqueues message A along with information indicating the periodicity of message A (at 508). The periodicity of message A can be determined based on reading the RSU MIB, inspecting the message body, or based on the PSID or PSID / SSP according to a known fixed period, etc.

[0108] Later, in response to receiving message B from a source (which may be the same as or different from the source of message A), the RSU control engine 502 sends (at 510) a request for information on message B to the queue / aggregation engine 504. Figure 5 In the example, the instruction to queue (for items belonging to the random category) is given.

[0109] RSU 108 can determine whether message B belongs to the random category based on RSU MIB, PSID, PSID / SSP combination, etc.

[0110] The queue / aggregation engine 504 determines (in 512) whether message B is delay-intolerant based on similar additional information as listed above.

[0111] If message B is latency-insensitive, then queue / aggregation engine 504 will cause message B to be transmitted without adding additional latency (in 514).

[0112] If message B is not a delay-intolerant type, the queue / aggregation engine delays message B with a 504 error and enqueues message B (at 516).

[0113] The queue / aggregation engine aggregates (at 518) messages A and B (which have already been queued) in a single transmission (at 520) at the next scheduled time for message A.

[0114] Note that tasks 506 and 508 are executed after the periodic message to be transmitted is received. The repetition of periodic message A can continue indefinitely or for a specified amount of time (e.g., indicated in the message delivery stop time field). During any consecutive message A transmission cycle, tasks 510 through 520 follow the reception of message B. If there is no consecutive message A transmission, delay-tolerant message B can be transmitted immediately.

[0115] In other examples, periodic messages can be aggregated together into a single transmission. The aggregation of periodic messages can take into account both the periodicity of the messages and the maximum size of the data frame that can fit into a single transmission.

[0116] For example, periodic messages with different periodicities can be aggregated together. Furthermore, multiple periodic messages (with the same or different periodicities) can be aggregated with random messages.

[0117] Figure 6 Another example process for processing message aggregation is shown. For example, Figure 6 The process can be performed by the source device. The process receives (at 602) message A. The process determines (at 604) whether message A is periodic. If so, the process enqueues message A and its periodicity information (i.e., the time when message A is periodically transmitted) (at 606).

[0118] If message A is not periodic, the process determines (at 608) whether message A is delay-intolerant. If message A is delay-intolerant, the process transmits message A without adding an additional delay (at 612). Transmitting the message without adding an additional delay can mean transmitting the message immediately or transmitting the message without adding a specified delay.

[0119] As determined in 608, if message A is not delay-intolerant, the process determines (in 610) whether there exists another message that can be used for aggregation. For example, another message that can be used for aggregation may include an upcoming periodic message scheduled to be transmitted at a future time. As another example, another message that can be used for aggregation may refer to a random message or another periodic message that was received when message A was already queued.

[0120] If another message is not available for aggregation, the process transmits message A (in 612) without adding any additional delay.

[0121] If another message is available for aggregation, the process calculates (in 614) the size of the aggregated message (i.e., the total size of message A and the other message or multiple other messages available for aggregation, minus any savings that can be achieved by removing overhead information).

[0122] This process determines (in 616) whether the aggregated message can fit into the data frame based on the calculated size of the aggregated message. If not, the process transmits message A at the scheduled time (in 618). For example, if the calculated size of the aggregated message exceeds the maximum size of the data frame, the aggregated message will not fit into the data frame.

[0123] However, if the aggregated message can be fitted into a data frame, the message is aggregated into the aggregated data frame, and the process transmits the aggregated data frame at a scheduled time (e.g., the scheduled time of message A or the scheduled time of another message that can be aggregated with message A) (at 620).

[0124] Additional Notes

[0125] Message aggregation can be employed in the IEEE 1609.4 multichannel operation context. According to IEEE 1609.4, data frames can be transmitted on multiple channels of a wireless network. If messages will be transmitted on the same channel, they can be aggregated based on their classification.

[0126] In some examples, RSU 108 may use WAVE service advertisement (WSA) to organize sources of messages being transmitted on the same channel, such that messages from such sources being transmitted on the same channel may be aggregated using techniques or mechanisms implemented according to some of the present disclosure.

[0127] While framing in 3GPP PC5-based cellular V2X (C-V2X) is less flexible than IEEE 802.11, it does offer opportunities to aggregate multiple upper-layer packets into a single lower-layer frame. The techniques or mechanisms discussed in this paper can be applied to C-V2X communications, while also considering future semi-persistent scheduling (SPS) transmissions. The fixed resource block size of LTE or NR can be used as a basis for efficiently packaging various messages into radio transmission frames.

[0128] The classification and aggregation techniques and mechanisms described for RSUs can also be applied to vehicle OBUs that transmit multiple messages from multiple sources. Inter-process protocols and transport application programming interfaces (APIs) can be used as sources to indicate to lower layers whether delays are permissible or not, or whether the transmission is periodic (in addition to the techniques described for RSUs).

[0129] Aggregation based on explicit attributes of source / message

[0130] As mentioned above, messages can be aggregated based on the attributes of the message's source. Additional information (metadata) associated with a message can indicate the attributes of the message's source or the message itself.

[0131] For example, additional information (metadata) may include RSU MIB.

[0132] The aggregation engine receives additional information about the attributes attached to the message to be sent. When the aggregation engine enqueues a message to be sent, it uses these attributes to determine whether to perform aggregation, including whether and when to delay messages to be aggregated.

[0133] When data frames are passed from the upper layer to the lower layer, the local source has the opportunity to notify the radio. This interface is described further below.

[0134] Aggregate frames based on implicit attributes of the source / message

[0135] In alternative examples, instead of using explicit information to indicate the attributes of the source or message, the attributes of the source or message can be implicitly indicated using existing information such as PSID, ITS-AID.

[0136] For example, the aggregation engine can determine whether to aggregate messages, including making decisions about delaying message transmission to aggregate multiple messages based on Ethertype, PSID, ITS-AID, SSP, or other information already encoded in the frame. Since Ethertype is in the IEEE 802.11 header, PSID is in the WSMP header, and SSP is in the SAE J2735 payload, this involves looking at the message layer above.

[0137] De-aggregate frames at the receiving device

[0138] Once the aggregated message is received at the vehicle or other receiving device, a de-aggregation process can be performed to extract the original individual messages from the aggregated message. The receiving device can then verify the security and integrity of each individual message. Each verified individual message can then be forwarded to the appropriate recipient associated with the receiving device.

[0139] The receiving device can receive aggregated data frames and process each WSMP header within them. Note that each individual message in the aggregated data frame is subject to line-independent security processing (unlike IEEE 802.11 security processing). The de-aggregation engine in the receiving device processing the aggregated data frame (e.g., 124 in Figure 1) can choose to pass individual messages (once extracted) sequentially to the upper layer or pass them to external nodes in priority order according to a FIFO. This priority order in which messages are passed to one or more receivers by the de-aggregation engine can be based on the same factors used by the source device to determine the aggregated frame.

[0140] The receiving device may be able to signal to the source device (e.g., the RSU) when an aggregated data frame has been discarded, allowing the source device to retransmit another aggregated data frame. In some cases, because duplicate information may be stale, the RSU may decide not to retransmit periodic messages (e.g., SPaT messages) that were part of a discarded aggregated data frame. Therefore, the retransmitted aggregated data frame may differ from the original (discarded) aggregated data frame.

[0141] At the receiving device, it can be determined that the aggregated data frame has been discarded by monitoring the Media Access Control (MAC) layer sequence number or the application layer sequence number and looking for missing numbers (e.g., 1, 2, 4, with 3 missing in this case).

[0142] The source device can respond to an indication that an aggregated data frame has been discarded by retransmitting only the lost single frame instead of aggregating multiple future frames for transmission.

[0143] RSU MIB Extension

[0144] In some examples, additional attributes are transferred from the source to the aggregation engine in the source device (e.g., RSU) using any one or more of the following MIB parameters. In some cases, MIB parameters can be used together, but typically MIB parameters are independent. This extends the RSU MIB described in Section B.4 of the "USDOT Specifications for DSRC Roadside Unit v4.1 r5".

[0145] rsuSRMDelaySensitive (TRUE / FALSE)

[0146] For messages that cannot be delayed, the delay sensitivity parameter is set to TRUE. For SPaT messages (where the message timing is specific), the delay sensitivity parameter can be set to TRUE. For messages without specific timing requirements (such as MAP messages), the delay sensitivity parameter can be set to FALSE.

[0147] rsuSRMTxJitter (integer 32 1..2147483647)

[0148] The allowed jitter parameter is the amount of time a source device can delay message transmission from a specified periodic TxInterval. For example, if rsuSRMTxInterval is 1000 milliseconds (ms), the message is transmitted once per second. If rsuSRMTxJitter is set to 200 ms, the source device can choose an optimal transmission time between 800 and 1200 ms. A value of 0 for rsuSRMTxJitter indicates that the message is latency-sensitive and should be transmitted exactly within the TxInterval period that would normally be used for CSMA transmission.

[0149] rsuSRMTxAllowedMaxDelay (integer 32 1..2147483647)

[0150] The maximum allowed delay parameter is the amount of time the source device can delay transmitting from the specified TxInterval.

[0151] rsuSRMAggregationPermitted (TRUE / FALSE / DON'T CARE)

[0152] If the message sender allows the source device to aggregate frames, the aggregation permission flag is set to TRUE. If the source device is not allowed to aggregate frames, the aggregation permission flag is set to FALSE. The aggregation permission flag can also be set to the DON'TCARE state. For example, this flag can appear in the following entries:

[0153] RsuSRMStatusEntry

[0154] RsuIFMStatusEntry

[0155] RsuDsrcForwardEntry

[0156] RsuWsaServiceEntry

[0157] MLME-X Extension

[0158] Additional attributes can be transmitted from the upper layer to the lower layer of the DSRC radio using a MAC sublayer management entity (MLME) with the following parameters. This extends the MLME / MLME-X described in Section 7.5 of IEEE 1609.3-2016. The underlined parameters in Table 2 below indicate the newly proposed parameters. Existing parameters are not shown in Table 2.

[0159] Table 2

[0160]

[0161] Determine the allowable delay

[0162] A PSID-based table can be stored on the source device (e.g., RSU, vehicle, etc.). The PSID-based table contains the following attributes.

[0163] -Allow aggregation (yes / no);

[0164] - Delay-tolerant (Yes / No);

[0165] - Periodicity (Yes / No);

[0166] - Period (time in milliseconds).

[0167] Table 3 below provides a non-exhaustive example table:

[0168] Table 3

[0169]

[0170] Since PSID is universal, and BSM (0x20) is used for many different messages transmitted by OBU, and TIM (0x83) is used for many different messages transmitted by RSU, a combination of PSID and SSP can be used instead of PSID alone.

[0171] Equipment Architecture

[0172] Figure 7 This is a block diagram of device 700 based on some examples. Device 700 can be an RSU, a vehicle, or any other source or receiver device.

[0173] Device 700 includes one or more hardware processors 702. The hardware processor may include a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or another hardware processing circuit.

[0174] The device 700 includes a communication interface 704 for communicating over a network.

[0175] The device 700 includes a non-transient machine-readable or computer-readable storage medium 706 containing machine-readable instructions that are executable on one or more hardware processors 702 to perform corresponding tasks.

[0176] Machine-readable instructions include message aggregation instructions 708 for aggregating messages according to some implementation of this disclosure.

[0177] The machine-readable instructions may also include a message de-aggregation instruction 710 for de-aggregating aggregated messages into individual messages. The message de-aggregation instruction 710 can receive aggregated data from a source device via a communication interface 704. This aggregated data includes multiple messages aggregated from the source device into a single transmission, and these multiple messages include vehicle-related information. The message de-aggregation instruction 710 can determine the priority of the multiple messages in the header information of the aggregated data. The message de-aggregation instruction 710 can then deliver the multiple messages to one or more receivers based on the determined priority.

[0178] The header information from which priority can be determined can be part of the WSMP header or the data frame header.

[0179] Storage medium 706 may include any or a combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed, floppy, and removable disks; another magnetic medium, including magnetic tape; optical media, such as optical discs (CDs) or digital video discs (DVDs); or another type of storage device. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture can refer to any single or multiple manufactured components. One or more storage media may be located in a machine that executes the machine-readable instructions or at a remote site from which machine-readable instructions can be downloaded via a network for execution.

[0180] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations can be practiced without some of these details. Other implementations may include modifications and variations to the details discussed above. Such modifications and variations are intended to be covered by the appended claims.

Claims

1. A method executed by a source device, comprising: The multiple messages used for transmission to a receiving device are classified, the multiple messages including vehicle-related information, wherein the classification of the multiple messages includes identifying delay-tolerant messages and delay-untolerant messages; The transmission of the delay-allowed message is delayed to allow the aggregation of the delay-allowed message with other messages; Based on the classification, a selected message to be aggregated from the plurality of messages is identified, wherein the selected message includes a first delay-tolerant message; At the source device, the first delay-tolerant message is segmented into multiple message fragments; as well as At the source device, message segments from the plurality of message segments are aggregated with at least one other message from the selected message into a single transmission from the source device to the receiving device. The message fragments and the at least one other message are aggregated into a single data frame in the single transmission, and the number of message fragments selected from the plurality of message fragments to be aggregated into the single data frame with the at least one other message is the maximum frame size of the single data frame.

2. The method of claim 1, wherein the single transmission includes a single transmission opportunity (TXOP) of the source device.

3. The method of claim 1, wherein aggregating the message fragment and the at least one other message into the single transmission includes aggregating the message fragment with at least one other delay-tolerant message.

4. The method of claim 1, wherein aggregating the message fragment and the at least one other message into the single transmission includes aggregating the message fragment with at least one of the delay-unacceptable messages.

5. The method of claim 1, wherein classifying the plurality of messages includes identifying periodic messages and non-periodic messages, and the method further comprises: Determine the scheduling time for the transmission of the first periodic message in the periodic messages; as well as The scheduling time is used to select the first periodic message for aggregation with another message into a single transmission from the source device to the receiving device.

6. The method of claim 1, wherein the source device comprises one of: a roadside unit, a vehicle, or a traffic management center.

7. The method of claim 1, wherein the classification of the plurality of messages is based on message type indication information associated with a corresponding message among the plurality of messages.

8. The method of claim 7, wherein the message type indication information includes a Message Information Base (MIB) extension associated with a first message of the plurality of messages.

9. The method of claim 7, wherein the message type indication information includes a provider service identifier (PSID).

10. The method of claim 7, wherein the message type indication information includes service-specific permission (SSP) information.

11. The method of claim 7, wherein the message type indication information includes Intelligent Transportation System Application Identifier (ITS-AID) or Ether type information.

12. The method according to claim 1, further comprising: Messages are received from an internal source within the source device or from an external source communicating with the source device via a network.

13. A source device, comprising: A communication interface used for communication over a network; as well as At least one processor is configured as follows: The multiple messages for transmission to a receiving device via the communication interface are classified, the multiple messages including vehicle-related information, wherein the classification of the multiple messages includes identifying delay-tolerant messages and delay-untolerant messages, and is based on message type indication information associated with a corresponding message among the multiple messages, and wherein the message type indication information includes a Message Information Base (MIB) extension associated with a first message among the multiple messages; The transmission of the delay-allowed message is delayed to allow the aggregation of the delay-allowed message with other messages; Based on the classification, a selected message to be aggregated from the plurality of messages is identified, wherein the selected message includes a first delay-tolerant message; The first delay-tolerant message is segmented into multiple message fragments; as well as The message segments from the plurality of message segments are aggregated with at least one other message from the selected message into a single transmission from the source device to the receiving device. The message fragments and the at least one other message are aggregated into a single data frame in the single transmission, and the number of message fragments selected from the plurality of message fragments to be aggregated into the single data frame with the at least one other message is the maximum frame size of the single data frame.

14. The source device of claim 13, wherein the aggregation of the selected message to the single transmission includes aggregating the at least one delay-tolerant message among the delay-tolerant messages with at least one other delay-tolerant message.

15. The source device of claim 13, wherein the aggregation of the selected message to the single transmission includes aggregating at least one delay-tolerant message among the delay-tolerant messages and at least one delay-intolerant message among the delay-intolerant messages.

16. The source device of claim 13, wherein the classification of the plurality of messages includes identifying periodic messages and non-periodic messages, and the at least one processor is configured to: Determine the scheduling time for the transmission of the first periodic message in the periodic messages; and The scheduling time is used to select the first periodic message for aggregation with another message into a single transmission from the source device to the receiving device.

17. The source device of claim 13, wherein the source device comprises one of: a roadside unit, a vehicle, or a traffic management center.

18. A non-transient machine-readable storage medium, comprising instructions that, when executed, cause a source device to: The multiple messages used for transmission to the receiving device are classified, the multiple messages including transportation-related information, wherein the classification of the multiple messages includes identifying delay-tolerant messages, delay-untolerant messages, periodic messages, and aperiodic messages; The transmission of the delay-allowed message is delayed to allow the aggregation of the delay-allowed message with other messages; Based on the classification, a selected message to be aggregated from the plurality of messages is identified, wherein the selected message includes a first delay-tolerant message; The first delay-tolerant message is segmented into multiple message fragments; The message segments from the plurality of message segments are aggregated with at least one other message from the selected message into a single transmission from the source device to the receiving device; Determine the scheduling time for the transmission of the first periodic message in the periodic messages; as well as The scheduling time is used to select the first periodic message for aggregation with another message into a single transmission from the source device to the receiving device. The message fragments and the at least one other message are aggregated into a single data frame in the single transmission, and the number of message fragments selected from the plurality of message fragments to be aggregated into the single data frame with the at least one other message is the maximum frame size of the single data frame.

Images