Patent Description:
An electronic device can transmit data from multiple sources, whether internal and/or external of the electronic device. <CIT> relates to an Intelligent Transport System. <CIT> relates to a method for receiving a multimedia content message by a vehicle to everything communication apparatus. <CIT> relates to MAC layer that receives data and aggregates the data by destination address and traffic identifier.

Accordingly there is provided a method, a device, and a computer readable medium as detailed in the claims that follow.

The scope of invention is defined by the appended claims.

The examples of <FIG> and <FIG> and their associated text are part of the invention and covered by the claims. All other examples disclosed below are merely explanatory, and are not part of the invention.

Table <NUM> below sets forth descriptions of acronyms or abbreviations used in the present description.

Vehicles can be provided with communication components to allow the vehicles to communicate with each other, with a network or other service infrastructure, or with another device. Examples of information that can be transmitted or received by vehicles can include data collected by sensors, traffic information, status information, and so forth.

Examples of vehicles include motor vehicles (e.g., automobiles, cars, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones, helicopters, etc.), spacecraft (e.g., space planes, space shuttles, space capsules, space stations, satellites, etc.), watercraft (e.g., ships, boats, hovercraft, submarines, etc.), railed vehicles (e.g., trains and trams, etc.), pedestrians and bicycles and other types of vehicles including any combinations of any of the foregoing, whether currently existing or after arising.

Vehicle-to-everything (loosely termed "V2X") is a feature that provides for communication of information from a vehicle to other entities (and possibly also/alternatively vice versa) that may affect the vehicle and/or the other entities. V2X includes one or more of a subset of features, including communication of a vehicle to/from any or some combination of the following: other vehicles (vehicle-to-vehicle or V2V communication); an infrastructure, e.g., road side units (RSUs) (vehicle-to-infrastructure or V2l communication); a pedestrian (vehicle-to-pedestrian or V2P communication); a network (vehicle-to-network or V2N communication); a device, e.g., an electronic device within the vehicle (vehicle-to-device or V2D communication), an electricity grid (vehicle-to-grid or V2G communication); and so forth.

V2X communications can also include transmissions from an RSU to other entities, including vehicles or other entities. An RSU can refer to any device that includes a radio (or other wireless interface) placed at a roadside that receives and transmits messages to vehicles. In the United States of America, the specification for RSUs can include the Dedicated Short Range Communication (DSRC) Roadside Unit (RSU) Specifications Document version <NUM> (or another version). In other examples, RSUs can operate according to other standards or using proprietary specifications.

More generally, V2X communications can include any communication of vehicle-related information from a source device to one or more recipient devices. A "vehicle-related information" can refer to information that includes data pertaining to a vehicle or an infrastructure that supports vehicles (e.g., RSUs, traffic lights, traffic signs, etc.); control information that affects operations of a vehicle or an infrastructure that supports vehicles; navigation data; and any other information that is directly or indirectly associated with vehicles.

Networks that support V2X communication can include a cellular network or another type of wireless network. An example cellular network can operate according to the Long-Term Evolution (LTE) standards as provided by the Third Generation Partnership Project (3GPP). The LTE standards are also referred to as the Evolved Universal Terrestrial Radio Access (E-UTRA) standards. In other examples, other types of cellular networks can be employed, such as second generation (<NUM>) or third generation (<NUM>) cellular networks, e.g., a Global System for Mobile (GSM) cellular network, an Enhanced Data rates for GSM Evolution (EDGE) cellular network, a Universal Terrestrial Radio Access Network (UTRAN), a Code Division Multiple Access (CDMA) <NUM> cellular network, and so forth. In further examples, cellular networks can be fifth generation (<NUM>) or beyond cellular networks.

Other types of wireless networks can include a wireless local area network (WLAN) that operates according to the Institute of Electrical and Electronics Engineers (IEEE) <NUM> standards (e.g. Dedicated Short Range Communication (DSRC)), IEEE <NUM>. 11a standards, IEEE <NUM>. 11p standards, IEEE <NUM>. 11bd standards (e.g. Enhancements for Next Generation V2X), an Integrated Digital Enhanced Network (iDEN), and so forth.

In some examples, an RSU can have two main modes of operation. In a first mode of operation, the RSU can communicate with vehicles over a single-hop networking technology called WAVE Short Message Protocol (WSMP), as defined in the IEEE <NUM> standard (for example). In a second mode of operation, the RSU can act as a network access node routing packets, such as Internet Protocol (IP) packets (e.g., IPv6 packets), to a backhaul network.

The following discussion refers to some examples involving the first mode of operation of an RSU.

In other examples, techniques or mechanisms according to the present disclosure can be used with RSUs operating in other modes, or with any other type of device that communicates vehicle-related information (such as in V2X communications).

An RSU can receive vehicle-related information from multiple sources for transmission over a network (wireless network or wired network) to one or more vehicles or other recipient devices. The RSU can be part of a larger device, such as a road side electronic cabinet. A source can include an internal source that is within the device containing the RSU (or a source within the RSU). Alternatively, a source can include an external source that is external of the device containing the RSU (or external of the RSU). An internal source can include an application program, a hardware component, and so forth. An external source can include a traffic management center (TMC) which is connected to the RSU over a backhaul network. The TMC can send messages to RSUs for transmission over wireless networks. Other examples of external sources can provide messages to RSUs.

In addition to RSUs, a vehicle can also receive vehicle-related information from multiple sources for transmission to another entity, where the sources can include internal sources (e.g., electronic control units (ECUs), etc.) and/or external sources (e.g., from user devices of passengers and/or drivers of vehicles, etc.).

Generally, a device (such as an RSU, a vehicle, or any other type of device) that can transmit messages from one or more sources (whether internal and/or external of the device) can be referred to as a "source device.

A source device transmitting messages generated locally or remotely one at a time, as the messages are received in a transmit queue of the source device, can be inefficient. As an example, transmitting multiple messages one at a time may not efficiently utilize communication resources, such as radio resources, or other resources of networks. For example, a message transmitted over a network may not fully occupy a data frame that carries that message, which is wasteful of the communication resource utilized by the data frame. As another example, delay-intolerant messages may be delayed, or delay-tolerant messages may be transmitted ahead of delay-intolerant messages. Moreover, if the source device were to wait for a next message before sending a currently queued message, to aggregate the messages together into a data frame, there may be a time gap between the messages, which can result in an unacceptable delay of the currently queued message to be transmitted.

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

The enqueuing of messages may be uncoordinated since the source device may not properly identify types of messages or types of sources that produced the messages. As a result, the transmission of the messages that have been enqueued may not be efficient.

In accordance with some implementations of the present disclosure, a source device can categorize messages that are to be transmitted, and arrange the categorized messages so that the transmission of the messages utilize communication resources in a more efficient manner. In some examples, messages of mixed categories can be aggregated into a single transmission such that the messages of the mixed categories can be transmitted together. As used here, a "single transmission" can refer to an "aggregated data frame" or a single transmission opportunity (TXOP). An "aggregated data frame" refers to a data frame into which multiple messages are combined, such that the data frame carrying the multiple messages can be transmitted over a network. A "data frame" can refer to any unit of data that can be separately communicated and identified and that can can be carried by communication resource of a network. A TXOP refers to a time interval or any other communication resource that can be allocated to the source device for use in transmitting information; the source device may be unable to transmit information outside of a TXOP.

In some examples according to the present disclosure, a recipient device can 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, a machine, a user, or any other entity, whether internal or external of the recipient device.

<FIG> is a block diagram of a communication arrangement that includes a road side electronic cabinet <NUM>, a TMC <NUM>, and a vehicle <NUM>. It is noted that there may be multiple road side electronic cabinets, and/or multiple vehicles, and/or multiple TMCs in other examples.

The road side electronic cabinet <NUM> includes an RSU <NUM> that has a communication interface <NUM> that allows the RSU <NUM> to communicate with the vehicle <NUM> (or multiple vehicles) over a wireless network (also referred to as OTA or over the air) in some examples. The wireless network can include a cellular network, a WLAN, or any other type of wireless network.

A "communication interface" can refer to a collection of components that allows a device to communicate over a network. For example, the communication interface can include a radio transceiver (or other type of wireless transceiver) to transmit and receive signals over the network. In addition, the communication interface can include protocol layers that are part of a protocol stack that allows the device to communicate information over a network according to one or more protocols, such as any of the protocols discussed in the present description.

For example, the communication interface <NUM> can communicate according to any of the following: DSRC, Intelligent Transportation Systems in <NUM> (ITS-G5); LTE-V2X via PC5 mode <NUM>; and so forth.

Although just one communication interface <NUM> is shown as part of the RSU <NUM> of <FIG>, it is noted that the RSU <NUM> can include multiple external interfaces, including a local interface to a component (e.g., <NUM>) in the road side electronic cabinet <NUM>; a backhaul interface to the TMC <NUM> (or other device or system); and the communication interface <NUM>.

The RSU <NUM> includes an aggregation engine <NUM> for aggregating messages. As used here, a "message" can refer to any unit of data that can be produced by a source.

As used here, an "engine" can refer to a hardware processing circuit, which can include any or some combination of a microprocessor, a 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. Alternatively, an "engine" can refer to a combination of a hardware processing circuit and machine-readable instructions (software and/or firmware) executable on the hardware processing circuit.

The RSU <NUM> can receive messages from various sources. For example, one of the sources is a signal controller <NUM> that is part of the road side electronic cabinet <NUM>. The signal controller <NUM> can be used to control a traffic light, such as at an intersection of multiple roads.

Another source that can provide messages to the RSU <NUM> is the TMC <NUM>, which transmits messages over a backhaul network <NUM> (e.g., a cellular network, a WLAN, a fiber optic network, etc.) to the road side electronic cabinet <NUM>.

There can be also other sources, represented generically as source <NUM>. For example, another type of source can include a device for producing map data, such as for navigational purposes. Although not shown, there can also be a source within the RSU <NUM>, such as a program executed by the RSU <NUM>.

The RSU <NUM> includes one or more queues <NUM> to enqueue messages received from the various sources, including the signal controller <NUM>, the TMC <NUM>, and the source <NUM>, as examples. A "queue" can refer to any storage, which can be implemented using one or more volatile memory devices and/or one or more nonvolatile memory devices.

The vehicle <NUM> includes a communication interface <NUM> to communicate with the RSU <NUM> over a network. In addition, the vehicle <NUM> includes a de-aggregation engine <NUM> to de-aggregate aggregated messages (sent by the RSU <NUM>) at the vehicle <NUM> upon receiving the aggregated messages from the RSU <NUM>. "Aggregated messages" can refer to multiple messages aggregated into a single transmission, such as a single aggregated data frame or a single TXOP.

Although not shown in <FIG>, the vehicle <NUM> can also include an aggregation engine similar to the aggregation engine <NUM>, and the RSU <NUM> can include a de-aggregation engine similar to the de-aggregation engine <NUM>.

<FIG> is a flow diagram of a process that can be performed by a source device, such as the RSU <NUM>, the vehicle <NUM>, or any other type of source device.

The source device categorizes (at <NUM>) multiple messages for transmission to a recipient device, where the multiple messages include vehicle-related information.

Based on the categorizing, the source device identifies (at <NUM>) selected messages of the multiple messages to be aggregated.

The source device aggregates (at <NUM>), such as by the aggregation engine <NUM>, the selected messages into a single transmission (e.g., a single aggregated data frame or a single TXOP) from the source device to the recipient device.

Categorizing of the multiple messages includes identifying delay tolerant messages and delay intolerant messages, and the process delays transmission of the delay tolerant messages to allow aggregation of the delay tolerant messages with other messages (delay tolerant or delay intolerant messages).

Categorizing of the multiple messages includes identifying periodic messages and non-periodic messages. The aggregating of the selected messages into the single transmission can include aggregating at least one of the periodic messages with at least one of the non-periodic messages or another periodic message.

In some examples, the process can determine a scheduled time of transmission for a first periodic message, and can use the scheduled time to select the first periodic message for aggregation with another message into the single transmission.

In some examples, aggregating messages into an aggregated data frame can include either of the following types of frame aggregation defined by the IEEE <NUM>-<NUM> standard: Aggregated MAC Service Data Unit (A-MSDU) aggregation, or Aggregated MAC Protocol Data Unit (A-MPDU) aggregation. Both types of the foregoing frame aggregation group several data frames into one larger frame. Because management information is specified only once per frame, the ratio of payload data to the total volume of data is higher, allowing higher communication throughput when frame aggregation is performed.

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

MSDU aggregation collects Ethernet frames to be transmitted to one destination or group-addressed destinations and wraps the Ethernet frames in a single IEEE <NUM> frame. This is efficient because Ethernet headers are much shorter than IEEE <NUM> headers. An A-MSDU contains only MSDUs whose destination address (DA) and sender address (SA) parameter values map to the same receiver address (RA) and transmitter address (TA) values, i.e., all the MSDUs are intended to be received by a single receiver, and all the MSDUs are transmitted by the same transmitter.

Note that it is possible to have different DA and SA parameter values in A-MSDU subframe headers of the same A-MSDU as long as they all map to the same Address <NUM> and Address <NUM> parameter values.

MPDU aggregation (A-MPDU) also collects Ethernet frames to be transmitted to a single destination, but each frame still contains its own IEEE <NUM> MAC header within the wrapped-up A-MPDU. Normally this is less efficient than MSDU aggregation, but is actually more efficient in environments with high error rates, because of a mechanism called Selective Block acknowledgement. The Selective Block acknowledgement mechanism allows each of the aggregated data frames to be individually acknowledged or retransmitted if affected by an error.

Messages can be categorized into the following example categories, including categories based on transmission cadence, and categories based on delay tolerance. Although specific categories are mentioned in the described examples, it is noted that other categories for messages can be employed in other examples.

The transmission cadence categories include a periodic category and a random category. Periodic messages (messages according to the periodic category) have a predictable cadence, since the periodic messages are sent periodically or intermittently every specified or scheduled interval.

Examples of messages of the periodic category including the following: "Store and repeat" in the USDOT Specifications for DSRC Roadside Unit; the "SPS flow" in 3GPP TS <NUM>, Release <NUM>, where "SPS" stands for "semi-persistent scheduling"; "BSM Part I" in Society of Automotive Engineers (SAE) J2945/<NUM>, where "BSM" stands for "Basic Safety Message"; and so forth.

Messages according to the random category include messages generated with unpredictable cadence or one-off messages. Examples of messages according to the random category include "Transmit immediately" in "USDOT Dedicated Short-Range Communications Roadside Unit Specifications"; "One Shot" in 3GPP TS <NUM>; and "BSM Part II" in SAE J2945/<NUM>.

The delay tolerance categories include a delay intolerant category, and a delay tolerant category. A message according to the delay intolerant category is to be transmitted immediately, or is to be transmitted at a specific time (such as a periodic message).

A delay tolerant message is a message that can be delayed (including a random message or a periodic message), or a message that may be skipped (such as a periodic message).

<FIG> shows an example of how a message can be grouped into one of groups A, B, C, and D based on a combination of the transmission cadence categories (periodic category and random category) and the delay tolerance categories (delay tolerant category and delay intolerant category).

A message that is periodic and delay tolerant is part of group A, a message that is delay tolerant and random is part of group B, a message that is periodic and delay intolerant is part of group C, and a message that is random and delay intolerant is part of group D.

In some examples, an aggregation engine (e.g., <NUM>) can identify and bundle (aggregate) periodic messages into aggregated data frames. In other examples, the aggregation engine can also bundle a random message with an enqueued periodic message. In further examples, the aggregation engine can bundle multiple random messages.

In some examples, a source generating a message passes additional information to the RSU <NUM> about the message the source is asking the RSU <NUM> to send. The additional information (metadata) can be in the form of an RSU Management Information Base (MIB) extension discussed further below. In other examples, the additional information (metadata) can include a Provider Service Identifier (PSID) (identifier in a message of an application or other source of the message), or a PSID/Service Specific Permissions (SSP) combination of a WSMP packet, or an Intelligent Transportation System Application Identifier (ITS-AID), or an Ethertype, or other information.

The SSP includes a set of security enablers offering finer grained control than the PSID. The PSID or PSID/SSP combination can be used as an indicator of one or both transmission cadence type and delay tolerance category.

An ITS-AID uniquely identifies a service or an application.

An Ethertype is used to indicate which protocol is encapsulated in the payload of a frame.

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

The additional information provided by sources in association with messages can be used by an aggregation engine to determine relative priorities of messages that are to be aggregated. For example, the additional information can include header information from which the priorities can be determined. The header information can be part of a WSMP header or a data frame header.

In some examples, the order in which messages are aggregated into an aggregated data frame can be based on the relative priorities of the messages. For example, a higher priority message (e.g., a delay intolerant message) may be placed ahead of a lower priority message (e.g., a delay tolerant message).

<FIG> is a block diagram of components in the vehicle <NUM> for performing categorization and aggregation of messages according to some implementations of the present disclosure. Generally, <FIG> shows an example of an onboard unit (OBU) architecture of a vehicle.

The vehicle <NUM> includes various sources of messages, including a basic safety application <NUM> (that implements various safety features of the vehicle <NUM>), a platooning or cooperative adaptive cruise control (CACC) application <NUM> (for performing cruise control for the vehicle <NUM>), and a safety awareness application <NUM> (to assist a driver in ensuring safe driving, such as based on detection of vehicles in a blind spot, detection of an object behind or in front of the vehicle, and so forth). Although example sources of messages are shown in <FIG>, it is noted that the vehicle <NUM> can include alternative or additional sources of messages.

The sources of messages in the vehicle <NUM> can be on the same or different central processing unit (CPU) or electronic control unit (ECU), can be in the same or different virtual machines (VMs), or can be different applications.

The messages from the sources <NUM>, <NUM>, and <NUM> can be enqueued in a queue <NUM> (or multiple queues).

An aggregation engine <NUM> categorizes the messages from the sources and aggregates selected messages, based on the categorization, into a single transmission based on the categorizing, in accordance with some implementations of the present disclosure.

In some examples, the queue <NUM> and aggregation engine <NUM> are part of a V2X radio stack.

The aggregated messages can then be transmitted to another entity, such as the RSU <NUM> of <FIG> or a different entity, by using the communication interface <NUM> of the vehicle <NUM>.

Although not shown, the vehicle <NUM> can also include a de-aggregation engine to unpack (de-aggregate) aggregated messages received in a single transmission (e.g., a single aggregated data frame or a single TXOP).

As noted above, in some examples, frame aggregation can include A-MSDU) aggregation or A-MPDU aggregation. Further details regarding frame aggregation is discussed further in <CIT> (having attorney docket no. <NUM>-US-PAT).

In some examples, techniques as discussed in <CIT> can be applied, and extended to perform aggregation of frames based on application properties (or more generally, properties of sources or categories of messages).

<FIG> shows an example of aggregating multiple MPDUs <NUM>, <NUM> and <NUM> into an aggregated MPDU <NUM>. The MPDU <NUM> includes an MSDU, which in turn includes a WSMP packet that contains Traveler Information Message (TIM) data. The MPDU <NUM> includes an MSDU, which in turn includes a WSMP packet, which contains map data. The MPDU <NUM> includes an MSDU, which in turn includes a WSMP packet that contains Signal Phase and Timing (SPaT) data. Each MPDU <NUM>, <NUM>, and <NUM> has a channel address and other overhead information.

Although the MPDUs <NUM>, <NUM>, and <NUM> are shown as carrying specific types of messages, it is noted that in other examples, an MPDU can carry another type of message.

Once the MPDUs <NUM>, <NUM>, and <NUM> are aggregated into the aggregated MPDU (A-MPDU) <NUM>, just one channel access delay and other overhead information is included in the aggregated MPDU, rather than the multiple channel access delays and overhead information of the MPDUs <NUM>, <NUM>, and <NUM>. This can result in a reduced amount of data transmitted over the network (e.g., OTA), which improves efficiency in usage of communication resources.

Messages that are time sensitive or latency sensitive are transmitted immediately (i.e., without adding a specified delay), while allowing messages that are delay tolerant or predictable to be queued and subject to further delay. Delay tolerant messages can be bundled together, or with delay intolerant messages.

A source of a message can inform the RSU <NUM> about the delay tolerance of the message, using the additional information (metadata) discussed further above. The provision of the additional information (metadata) can be on a per frame basis, or per source basis.

The RSU <NUM> also fragments a message (a message that is delay tolerant) to allow more efficient aggregation, by packing or stuffing an aggregated data frame to its maximum frame size. Fragmenting a message refers to dividing the message into multiple message fragments, such that one or more of the message fragments can be aggregated with another message into an aggregated data frame.

Note that WSMP as used currently for J2735 based applications are not fragmentable, but in the future other payloads (e.g., Internet Protocol or IP-based payloads) that are fragmentable can be used.

<FIG> shows an example process for aggregating non-periodic messages with periodic messages. In the process of <FIG>, an RSU control engine <NUM> (which can be part of the RSU <NUM>) sends (at <NUM>), to the queue/aggregation engine <NUM>, an indication (e.g., a command or other information) to queue message A, which in the example of <FIG> is of the periodic category.

The RSU <NUM> can determine that message A is of the periodic category based on an RSU MIB, a PSID, PSID/SSP combination, and so forth.

The RSU control engine <NUM> performs control functionality for the RSU <NUM>. The queue/aggregation engine <NUM> includes a queue and an aggregation engine, such as those shown in <FIG>.

Message A is received from a source, such as any of the sources shown in <FIG>.

The queue/aggregation engine <NUM> enqueues (at <NUM>) message A, along with information indicating the periodicity of message A. The periodicity of message A can be determined based on reading the RSU MIB, inspecting message body, based on a known fixed period according to a PSID or PSID/SSP, and so forth.

Later, in response to receipt of message B from a source (which can be the same as or different from the source of message A), the RSU control engine <NUM> sends (at <NUM>), to the queue/aggregation engine <NUM>, an indication to queue message B, which in the example of <FIG> is of the random category.

The RSU <NUM> can determine that message B is of the random category based on an RSU MIB, a PSID, PSID/SSP combination, and so forth.

The queue/aggregation engine <NUM> determines (at <NUM>) whether message B is delay intolerant, based on similar additional information as listed above.

If message B is delay intolerant, the queue/aggregation engine <NUM> causes transmission (at <NUM>) of message B without adding a further delay.

If message B is not delay intolerant, the queue/aggregation engine <NUM> delays and enqueues (at <NUM>) message B.

The queue/aggregation engine <NUM> aggregates (at <NUM>) message A and message B (which have been enqueued), and transmits (at <NUM>) the aggregated messages in a single transmission at the next scheduled time for message A.

Note that tasks <NUM> and <NUM> are performed upon reception of a periodic message to transmit. The repetition of periodic message A can continue indefinitely or for a set amount of time (for example, indicated in the Message Delivery Stop Time field). Tasks <NUM> to <NUM> follow the reception of message B during any successive message A transmission period. A delay tolerant message B may be transmitted immediately if there is no successive message A transmission.

In other examples, periodic messages can be aggregated together into a single transmission. The aggregation of periodic messages can consider the periodicity of the messages and the maximum size of a data frame that can fit into a single transmission.

For example, periodic messages of different periodicities can be aggregated together. Moreover, multiple periodic messages (of the same or different periodicities) can also be aggregated with a random message.

<FIG> illustrates another example process for handling aggregation of messages. The process of <FIG> can be performed by a source device, for example. The process receives (at <NUM>) message A. The process determines (at <NUM>) whether message A is periodic. If so, the process enqueues (at <NUM>) message A and its periodicity information (i.e., the time at which message A is to be periodically transmitted).

If message A is not periodic, the process determines (at <NUM>) whether message A is delay intolerant. If message A is delay intolerant, the process transmits (at <NUM>) message A without adding further delay. Transmitting a message without adding further delay can refer to transmitting the message immediately or otherwise transmitting the message without adding a specified delay.

If message A is not delay intolerant, as determined at <NUM>, the process determines (at <NUM>) whether there is another message available for aggregation. For example, another message available for aggregation can include an upcoming periodic message that is scheduled for transmission at a future time. As a further example, another message available for aggregation can refer to a random message or another periodic message that has been received while message A has been enqueued.

If another message is not available for aggregation, the process transmits (at <NUM>) message A without adding further delay.

If another message is available for aggregation, the process calculates (at <NUM>) the size of the aggregated messages (i.e., the total size of message A and the other message or other multiple messages that are available for aggregation, less any savings that can be achieved by removing overhead information).

The process determines (at <NUM>) whether the aggregated messages can fit into a data frame, based on the calculated size of the aggregated messages. If not, the process transmits (at <NUM>) message A at the scheduled time. The aggregated messages will not be able to fit into a data frame if the calculated size of the aggregated messages exceeds the maximum size of the data frame, for example.

However, if the aggregated messages can fit into a data frame, the messages are aggregated into an aggregated data frame, and the process transmits (at <NUM>) the aggregated data frame at the scheduled time (e.g., the scheduled time of message A or the scheduled time of another message that is available for aggregation with message A).

Aggregation of messages can be employed in the IEEE <NUM> multichannel operation context. According to IEEE <NUM>, data frames can be transmitted over multiple channels of a wireless network. Messages can be aggregated based on their categorization if the messages are to be transmitted on the same channel.

In some examples, the RSU <NUM> can use WAVE Service Announcements (WSAs) to organize sources that transmit messages on the same channel, such that messages from such sources that transmit on the same channel can be aggregated using techniques or mechanisms according to some implementations of the present disclosure.

3GPP PC5-based Cellular V2X (C-V2X) has less flexible framing than IEEE <NUM>, but also provides opportunity to aggregate multiple upper layer packets into a single lower layer frame. The techniques or mechanisms disused herein may be applied to C-V2X communications while additionally taking into account future semi-persistent scheduled (SPS) transmissions. The fixed Resource Block size of LTE or NR can be used as the basis for packing various messages efficiently into radio transmitted frames.

The categorization and aggregation techniques and mechanisms described for RSUs can also apply to vehicle OBUs transmitting multiple messages from multiple sources. Inter-process protocols and transmit application programming interfaces (APls) can be used for sources to indicate to a lower layer the delay tolerance or intolerance or the periodicity of a frame being transmitted (in addition to the techniques described for RSUs).

As noted above, messages can be aggregated based on properties of sources of the messages. Additional information (metadata) associated with a message can indicate a property of the source of the message or a property of the message.

For example, the additional information (metadata) can include an RSU MIB.

An aggregation engine receives the additional information of the properties alongside the message to send. As the aggregation engine enqueues the message to send, the aggregation engine uses the properties to decide to aggregate or not, including if and when to delay a message that is to be aggregated.

A local source has an opportunity to inform the radio as the data frames are passed from the upper layers to the lower layers. This interface is described further below.

In alternative examples, instead of using explicit information to indicate properties of sources or messages, properties of sources or messages can be implicitly indicated using existing information, such as a PSID, an ITS-AID.

For example, an aggregation engine can make a determination to aggregate messages or not, including decisions to delay transmission of a message in order to aggregate multiple messages based on the Ethertype, PSID, ITS-AID, SSP, or other information already encoded in the frame. This involves looking into the message upper layers as Ethertype is in the IEEE <NUM> header, PSID is in the WSMP header, and SSP is in the SAE J2735 payload.

Once the combined message is received at the vehicle or other recipient device, a de-aggregation process can be performed to extract the original individual messages from the aggregated messages. The recipient device can validate the security and integrity of each individual message. Each of the validated individual messages is then forwarded to a respective recipient associated with the recipient device.

The recipient device can receive an aggregated data frame and process each of the WSMP headers in the aggregated data frame. Note that each individual frame in the aggregated data frame is subjected to independent security processing (that is different from IEEE <NUM> security processing). The de-aggregation engine (e.g., <NUM> in <FIG>) in the recipient device that processes the aggregated data frame can choose to pass the individual messages (once extracted) serially to the upper layers, or to external nodes in priority order as opposed to FIFO. This priority order according to which the messages are delivered to one or more recipients by the de-aggregation engine can be based on the same factors the source device used to decide to aggregate frames.

The recipient device may be able to signal the source device (e.g., the RSU) when an aggregated data frame has been dropped, so that the source device can re-send another aggregated data frame. In some cases, the RSU may decide to not re-transmit periodic messages (e.g., a SPaT message) that is part of the dropped aggregated data frame, as the repeated information may be stale. Therefore, the retransmitted aggregated data frame may differ from that of the original (dropped) aggregated data frame.

At the recipient device, a determination that an aggregated data frame has been dropped can be done by monitoring Medium Access Control (MAC) layer sequence numbers or application layer sequence numbers and finding missing numbers (<NUM>, <NUM>, <NUM>, for example, in which case <NUM> is missing).

The source device may respond to the indication that an aggregated data frame has been dropped by just re-transmitting an individual frame that was lost, instead of aggregating multiple future frames for transmission.

In some examples, additional properties are communicated from a source to an aggregation engine in a source device (e.g., an RSU) by using any one or more of the MIB parameters below. In some cases, the MIB parameters can be used together, but in general the MIB parameters are independent. This extends the RSU MIB described in section B. <NUM> of "USDOT Specifications for DSRC Roadside Unit v4.

The delay sensitive parameter is set to TRUE for messages that cannot be delayed. This delay sensitive parameter can be set to TRUE for an SPaT message where the timing of the message is specific. This delay sensitive parameter can be set to FALSE for messages that have no specific timing requirement such as MAP messages.

The allowable jitter parameter is the amount the source device can delay the transmission of a message from the periodic Txlnterval specified. For example, if the rsuSRMTxInterval is <NUM> milliseconds (ms), the message is transmitted once every second. If the rsuSRMTxJitter is set to <NUM>, then the source device may choose an optimal transmission time between <NUM> and <NUM>. A rsuSRMTxJitter value of <NUM> indicates that the message is sensitive to delay and should be transmitted at exactly the Txlnterval period pending the usual CSMA rules for transmission.

The allowed maximum delay parameter is the amount the source device can delay the transmission from the Txlnterval specified.

The Aggregation Permitted flag is set to TRUE if the sender of the message allows the source device to aggregate the frame. The Aggregation Permitted flag is set to FALSE if the source device is disallowed to aggregate the frame. The Aggregation Permitted flag can also be set to a DON'T CARE state. This flag can be present in the following entries for example:.

Additional properties can be communicated from the upper layers to the lower layers of the DSRC radio using the MAC Sublayer Management Entity (MLME) with the parameters below. This extends the MLME/MLME-X described in section <NUM> of IEEE <NUM>-<NUM>. The new proposed parameters are shown in underline in Table <NUM> below. The existing parameters are not underlined in Table <NUM>.

A PSID based table can be stored in a source device (e.g., an RSU, a vehicle, etc.). This PSID based table contains the following properties.

A non-exhaustive example table is provided below in Table <NUM>:.

Since PSIDs are general and the BSM (0x20) is used for many different messages transmitted by an OBU and the TIM (0x83) is used for many different messages transmitted by an RSU, the combination of PSID and SSP may be used instead of just the PSID.

<FIG> is a block diagram of a device <NUM> according to some examples. The device <NUM> can be an RSU, a vehicle, or any other source device or recipient device.

The device <NUM> includes one or more hardware processors <NUM>. A hardware processor can include a microprocessor, a 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.

The device <NUM> includes a communication interface <NUM> to communicate over a network.

The device <NUM> includes a non-transitory machine-readable or computer-readable storage medium <NUM> that stores machine-readable instructions executable on the one or more hardware processors <NUM> to perform respective tasks.

The machine-readable instructions include message aggregation instructions <NUM> to aggregate messages according to some implementations of the present disclosure.

The machine-readable instructions can also include message de-aggregation instructions <NUM> to de-aggregate aggregated messages into individual messages. The message de-aggregation instructions <NUM> can receive, from a source device through the communication interface <NUM>, aggregated data that includes a plurality of messages aggregated into a single transmission by the source device, the plurality of messages including vehicle-related information. The message de-aggregation instructions <NUM> can determine, in header information of the aggregated data, priorities of the plurality of messages. The message de-aggregation instructions <NUM> can deliver the plurality of messages to one or more recipients according to the determined priorities.

The header information from which the priorities can be determined can be part of a WSMP header or a data frame header.

The storage medium <NUM> can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and programmable read-only memory (EEPROM) and flash memory; a magnetic disk such as a fixed, floppy and removable disk; another magnetic medium including tape; an optical medium such as a compact disc (CD) or a digital video disc (DVD); or another type of storage device. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

Claim 1:
A method performed by a source device (<NUM>), comprising:
categorizing (<NUM>) a plurality of messages for transmission to a recipient device, the plurality of messages comprising vehicle-related information, wherein the categorizing of the plurality of messages comprises identifying delay tolerant messages and delay intolerant messages;
delaying transmission of the delay tolerant messages to allow aggregation of at least one of the delay tolerant messages with one or more of the delay tolerant messages other than the at least one of the delay tolerant messages or with one or more of the delay intolerant messages;
based on the categorizing, identifying (<NUM>) selected messages of the plurality of messages to be aggregated, wherein the selected messages comprise a first delay tolerant message amongst the delay tolerant messages;
fragmenting, at the source device, the first delay tolerant message into a plurality of message fragments: and
aggregating (<NUM>), at the source device, a message fragment of the plurality of message fragments with at least one other message of the selected messages into a single transmission from the source device to the recipient device; wherein the at least one other message of the selected messages comprises at least one message from the selected messages other than the first delay tolerant message;
wherein the message fragment and the at least one other message are aggregated into a single data frame of the single transmission, and wherein a quantity of message fragments of the plurality of message fragments selected by the source device to be aggregated with the at least one other message into the single data frame allows packing the single data frame to a maximum frame size that can be carried by a communication resource of a network.