Patent Description:
In-vehicle network (IVN) buses, such as CAN (Controller Area Network), CAN FD (CAN with Flexible Data-Rate), LIN (Local Interconnect Network), FlexRay, Ethernet based network buses, and other types, can be used for communications within vehicles. For example, controller area network (CAN) bus is a message-based communications bus protocol that is often used within automobiles. It will be appreciated that CAN networks also have application outside of the field of automobiles. A CAN bus network may include multiple bus devices, so called nodes or electronic control units (ECUs), such as an engine control module (ECM), a power train control module (PCM), airbags, antilock brakes, cruise control, electric power steering, audio systems, windows, doors, mirror adjustment, battery and recharging systems for hybrid/electric cars, and many more. The CAN bus protocol is used to enable communications between the various bus devices. The data link layer of the CAN protocol is standardized as International Standards Organization (ISO) <NUM>-<NUM>:<NUM>. CAN Flexible Data-Rate or "CAN FD," which is an extension of the standardized CAN data link layer protocol and is meanwhile integrated into the ISO11898-<NUM>:<NUM> standard, can provide higher data rates. The standardized CAN data link layer protocol is being further extended to provide even higher data rates. A further extension, referred to as CAN XL, with a new level scheme allowing even higher data rates is in the definition phase discussed under CiA610 (CAN in Automation) and is moving towards standardization in the form of either a further update of the existing ISO11898 standards or a new standard.

In some examples, there may be more than one type of network provided connectivity for a system, such as an automobile. For example, it is known to provide a network that comprises a first component network configured to operate based on a first protocol, such as the Ethernet protocol, and a second component network configured to operate based on a second protocol, such as the CAN protocol or FlexRay or LIN, wherein the first and second component networks are coupled together. An apparatus, which is sometimes termed a gateway, may provide an interface between the first and second component networks. The apparatus or gateway may allow for one or more messages from a node coupled to the first network part to reach a node coupled to the second network part and vice versa.

<CIT> discloses a method of operating a network entity of a network comprising a gateway, wherein the method comprises dynamically changing a GPRS tunnelling Protocol (GTP) termination point in the gateway.

According to a first aspect of the present disclosure there is provided an apparatus for providing an interface between a first network configured to operate based on a first protocol and at least a second network configured to operate based on a second protocol, different to the first protocol, the apparatus comprising:.

In one or more examples, the set of plural messages that form a flow are intended for the same node coupled to the second network. In one or more examples, the flow comprises a set of plural second messages that collectively comprise information that is divided over the set of extracted second messages. In one or more examples, the flow comprises a set of messages that are processed by a transport layer protocol to divide the information over the set of second messages.

In one or more examples, the apparatus may be configured to await receipt of a message from the second network which is sent in response to at least a first of the second messages transmitted on the second network before sending a subsequent extracted second messages on the second network.

In one or more embodiments, said apparatus includes a timer configured to define said predetermined minimum time spacing and wherein the apparatus only allows for said transmission of a subsequent one of said extracted second messages after said timer determines that said predetermined minimum time spacing has expired following transmission of a preceding message of said extracted second messages.

In one or more embodiments, said flow identifying information comprises at least one of:.

In one or more embodiments, said predetermined minimum time spacing is defined based on information contained in a flow control message received from said node coupled to the second network, said flow control message received following transmission of a first of said extracted second messages that belong to the same flow and defining one or more parameters for controlling the sending of messages to said node.

In one or more embodiments, said first protocol comprises one of Ethernet, Token Ring protocol, Synchronous optical networking protocol, frame relay protocol, Asynchronous Transfer Mode protocol.

In one or more embodiments, said second protocol comprises one of a Controller Area Network protocol, a FlexRay protocol, and LIN protocol.

In one or more embodiments, the predetermined minimum time spacing used by the apparatus in the transmission of the extracted second messages is dependent on the flow to which the second message belong.

Thus, different predetermined minimum time spacings may be used for different flows.

According to a second aspect of the disclosure, we provide a system comprising the apparatus of any preceding claim in combination with a transport apparatus remote from the apparatus, wherein said transport apparatus is configured to:.

In one or more examples, said transport apparatus is configured to add a sequence number to each of the second messages, the sequence number configured to designate an order of the plurality of second messages for use in reassembling, by the node coupled to the second network, the information divided over the plurality of second messages.

In one or more embodiments, the transport apparatus is configured to receive said information from the first network and is configured to determine, based on an identifier associated with the information, that the information is for the node coupled to the second network. In other examples, the transport apparatus may be configured to generate the information.

In one or more embodiments, the transport layer protocol comprises the CAN-TP Protocol.

In one or more embodiments, if said information can be sent in a single protocol data unit, generate said second message containing the information without use of said transport layer protocol.

In one or more embodiments, said apparatus is configured to receive a flow control message from said node coupled to the second network, wherein said flow control message defines one or more parameters for controlling the sending of messages to said node and wherein said apparatus is configured to forward said flow control message to the transport apparatus via the first network by encapsulating said flow control message within a message according to the first protocol and transmitting the message via the first network.

In one or more embodiments, said transport apparatus is configured to, upon receipt of the message that encapsulates the flow control message, extract said flow control message and, based on a block size parameter specified in the flow control message, encapsulate said second messages in said one or more first messages such that the number of second messages encapsulated in any one first message is no greater than the block size parameter.

According to a third aspect of the disclosure, we provide a method of operating an apparatus that provides an interface between a first network configured to operate based on a first protocol and at least a second network configured to operate based on a second protocol, different to the first protocol, the method comprising:.

In one or more embodiments, the method includes generating, by a transport apparatus coupled to the apparatus by the first network, the plurality of second messages according to a transport layer protocol and generating the one or more first messages by encapsulation of the second messages, wherein the first messages are generated in accordance with the first protocol for transmission on the first network to the apparatus.

It should be understood, however, that other embodiments, beyond the particular embodiments described, are possible as well. All modifications, equivalents, and alternative embodiments falling within the spirit and scope of the appended claims are covered as well.

The above discussion is not intended to represent every example embodiment or every implementation within the scope of the current or future Claim sets. The figures and Detailed Description that follow also exemplify various example embodiments. Various example embodiments may be more completely understood in consideration of the following Detailed Description in connection with the accompanying Drawings.

A network protocol that defines the operation of a network may define a size limit on a message that may be sent over the network. Such a message may be known as a protocol data unit (PDU), that is a single unit of information that is for transmission on a network. In a CAN network, the protocol data unit is known as a frame and in other network protocols it may be known as a packet or by some other name. In CAN, the size limit for information sent in a single protocol data unit may be eight bytes. Thus, the transfer of a large amount of information (greater than the size limit of a single protocol unit) over such networks requires the information to be divided into smaller parts and sent piece by piece in a flow of a plurality of messages or protocol data units. The rules for sending such flows is defined by a transport layer protocol.

Network protocols may therefore use traffic shaping, which is a technique used in networking to make sure that traffic egressing from a certain node adheres to a predefined shape, e.g. limited bursts or spacing between PDUs. It is used to avoid overloading of networking or receiver resources. In some cases, it can also be used as a security measure, as it prevents flooding of a communication bus during a denial of service attack. Examples of traffic shapers are leaky bucket and credit based shaper.

While the disclosure has broader scope, we disclose that, in a CAN network, there is the CAN transport layer protocol, known as CAN-TP, defined in ISO <NUM>-<NUM> which defines how each CAN frame is structured and how the flow of messages are sent over the network. The rules may define, among other parameters, timing requirements regarding when messages are to be sent on the network or when replies are to be received. Networks other than CAN may also have transport layer protocols that define one or more similar rules.

In some network architectures, such as for upcoming in-vehicle network architectures, the tunnelling of CAN protocol PDUs over Ethernet is gaining traction. Tunnelling is a way of sending a "first" message of a first network protocol over a network that is configured to operate based on a second network protocol. In general terms, it is achieved by placing the first message or PDU (in a format according to the first protocol of the first network) within a second PDU, such as in a data field of the second PDU, wherein the second PDU is in a format according to the second protocol of the second network. Thus, one or more CAN frames (first PDU) may be sent over an Ethernet network by treating the CAN frame as the data of a Ethernet frame or User Datagram Protocol datagram (second PDU). When the second PDU reaches the edge of the CAN network, the first message or PDU may be unpacked from it by a gateway device and sent on the CAN network. The placement of one or more first PDUs in one or more second PDUs for the purpose of tunnelling is known as encapsulation.

In one or more examples, it has been found that challenges exist when transport layer protocols are used with tunnelling, where there is encapsulation of PDUs that are part of a flow of PDUs intended for delivery on a network operating according to a different protocol.

In general and in one or more examples, we disclose an apparatus <NUM> for providing an interface between a first network <NUM> configured to operate based on a first protocol and at least one second network <NUM> configured to operate based on a second protocol, different to the first protocol. In one or more examples, the apparatus <NUM> may be provided in combination with a transport apparatus <NUM>. The transport apparatus <NUM>, in one or more examples, may be considered part of the first network <NUM> (i.e. a node of the first network configured to send and receive data onto the first network according to the first protocol). The transport apparatus <NUM> may be configured to implement a transport layer protocol to generate for a plurality of PDUs to be sent over the second network <NUM> to a destination node <NUM> coupled to the second network <NUM>. The transport apparatus <NUM> may be configured to tunnel the plurality of PDUs configured in accordance with the transport layer protocol to the apparatus <NUM>. Thus, the transport apparatus <NUM> may be configured to implement a subset of the rules of the transport layer protocol. However, in some examples, it may not be possible for the transport apparatus <NUM> to implement all of the rules of the transport layer protocol if it is required to tunnel a flow of PDUs to said apparatus <NUM>. Accordingly, the apparatus <NUM> may be configured to implement a different subset of one or more rules of the transport layer protocol. The apparatus <NUM> has a direct connection to the second network <NUM> unlike the transport apparatus <NUM> and therefore is able to transmit the flow of PDUs that are in a format according to the protocol of the second network <NUM> to the destination node <NUM> in accordance with the second subset of transport layer protocol rules.

This arrangement of a transport apparatus <NUM> forming a flow of PDUs according to a transport layer protocol and then, rather than transmitting them on the second network <NUM> directly, tunnelling them to the apparatus <NUM> at the edge of the second network <NUM> is an advantageous arrangement. In particular, when the transport apparatus <NUM> is the source of the information it may be efficient in some examples for the transport apparatus <NUM> to be responsible for forming the flow, which can reduce the overall use of computing resources.

In the examples herein, the first network <NUM> is a Ethernet network operating according to the Ethernet protocol, although other types of first network <NUM> are within the scope of this disclosure. In the examples described herein, the second network <NUM> is a Controller Area Network operating based on the CAN protocol (or extensions to the classical CAN protocol such as CAN-FD), although other types of second network <NUM> are within the scope of this disclosure.

In the examples that follow, the apparatus <NUM> and the transport apparatus <NUM> are configured, in combination, to implement the transport layer protocol, CAN-TP for sending a flow of CAN frames on the second, CAN network <NUM>. In particular, the transport apparatus <NUM> divides the information into a plurality of messages and tunnels them to the apparatus <NUM>. The apparatus <NUM> in combination with the node with which it is communication may be configured to implement the one or more "traffic shaping" rules of the transport protocol. Communication between the apparatus <NUM> and the transport apparatus <NUM> however, is based on the first protocol of the first network.

Example <FIG> shows an exchange of messages between a sender <NUM> and a receiver <NUM> that provides for transmission of a flow of messages according to the CAN-TP protocol. Thus, the information that is to be sent from the sender <NUM> to the receiver <NUM> will be segmented over the flow of messages shown in <FIG> also shows the parameters of operation of CAN-TP as described in ISO15765-<NUM>:<NUM>.

CAN-TP defines the sending of a flow of messages (CAN frames or CAN PDUs) as follows. The sender <NUM> sends a first frame message <NUM>. The first frame message <NUM> is the first message of the multi-frame message flow and may contain a designation of the length of the information to be sent over the multiple messages. The first frame <NUM> may also include an initial part of information to be sent. The receiver <NUM> should respond to a first frame message <NUM> with a flow control frame message <NUM>. The flow control frame <NUM> defines one or more parameters to control how the flow is to be sent (e.g. some of the rules of the transport layer protocol). In particular, the flow control frame <NUM> defines a Block Size parameter (BS) and a minimum time spacing between consecutive message parameter, known as STmin. The BS parameter defines the number of consecutive frames the sender <NUM> can send before the receiver will send an acknowledgment message. The flow control message <NUM> may be used by the receiver <NUM> to define how it receives the flow of messages to avoid it becoming overloaded or to be within processing limitations of the receiver <NUM>. In this examples, the BS parameter is three messages.

Following receipt of the flow control message <NUM>, the sender <NUM> sends a first consecutive frame message <NUM>, a second consecutive frame message <NUM> and a third consecutive frame message <NUM> (three messages in total to meet the BS parameter). It will be appreciated that the three consecutive frame messages contain the segmented information that is to be sent from the sender <NUM> to the receiver <NUM>. The time spacing between each of the consecutive frame messages <NUM>, <NUM>, <NUM> can be no shorter than STmin <NUM>. Thus, the time spacing between the messages <NUM>, <NUM>, <NUM> may be greater. For example a different node in the second network <NUM> may win arbitration during the transmission of the messages <NUM>, <NUM>, <NUM> and therefore the time spacing between the messages <NUM>, <NUM>, <NUM> may be much greater than STmin <NUM>. The block size parameter is shown as group <NUM> illustrating the three message limit.

After the third consecutive frame message <NUM>, the sender <NUM> waits for an acknowledgement. The receiver <NUM> should acknowledge the first block of three consecutive frame messages <NUM>, <NUM>, <NUM> with a second flow control frame <NUM>. The second flow control frame <NUM> can again define one or more parameters to control how the flow is to be sent. In particular, the second flow control frame message <NUM> defines the Block Size parameter again and the STmin parameter again. The BS and STmin parameters may change or stay the same. <FIG> shows a fourth consecutive frame message <NUM> and a fifth consecutive frame message <NUM>. In this example, this completes the sending of the flow, comprising the first frame message <NUM> and the first to fifth consecutive frame messages <NUM>-<NUM>, <NUM>, <NUM>. It will be appreciated that the block of messages <NUM> comprising the fourth and fifth consecutive frame messages <NUM>, <NUM> is less than or equal to the number of messages defined by the BS parameter in the second flow control frame message <NUM>. Likewise, the minimum time spacing between the fourth and fifth consecutive frame messages <NUM>, <NUM> is greater than or equal to the STmin parameter defined in the second flow control frame message <NUM>.

In this example of a CAN implementation of the second network <NUM>, it is the implementation of the minimum time spacing defined by parameter STmin that the apparatus <NUM> is configured to provide. It will be appreciated that other protocols may have similar parameters.

Example <FIG> shows a more detailed view of <FIG>. The transport apparatus <NUM> is shown having a terminal <NUM> coupled to the Ethernet network <NUM> to receive one or more messages containing information intended for one of the nodes <NUM> of the CAN network <NUM>. In other examples, the information for the nodes <NUM> of the CAN network <NUM> may originate at the transport apparatus <NUM>.

<FIG> also shows a protocol stack <NUM> (which may be formed of multiple stacks) provided by a processor of the transport apparatus <NUM> to illustrate the operation of the transport apparatus <NUM>.

The messages received from the first, Ethernet, network <NUM> received at terminal <NUM> are provided to the protocol stack <NUM>. The messages are received by one or more agents including (from bottom of the stack <NUM> shown in <FIG> to the top) EthIF, TCP/IP, SoAd, DoIP which will be familiar to those skilled in the art of AUTOSAR. EthIf is the Ethernet Interface used to transmit/receive Ethernet frames; TCP/IP is the stack implementing TCP, UDP, and IP etc; SoAd is a Socket Adaptor, which translates between I-PDUs and sockets of the TCP/IP stack; and DoIP is diagnostics over IP, which comprises a diagnostic protocol that works over Ethernet.

If the message(s) received by the transport apparatus <NUM> comprises information intended for the second, CAN, network <NUM>, then a protocol data unit router module <NUM> routes the message(s) to a second protocol stack <NUM> that handles CAN messages. If the information can be sent in a single CAN frame, then the transport apparatus <NUM> may be configured to forward it to the apparatus <NUM> for sending. If the information is of a size to require sending over multiple CAN frame messages (PDUs) then the information may be provided to a CAN-TP module <NUM> that provides for implementation of the CAN transport layer protocol CAN-TP.

The CAN-TP module <NUM> receives the information and generates a plurality of CAN messages (i.e. termed second messages in this example) according to the CAN-TP protocol, in order to send the information. Thus, the information is segmented over a plurality of CAN frame messages that are termed a flow of messages.

The CAN-TP module <NUM> may be configured to add a sequence number to each of the second messages of the flow. The sequence number may be configured to designate an order of the plurality of second messages for use in reassembling, by the node <NUM>, the information that is divided over the plurality of second messages generated by the module <NUM>.

The information for sending to the CAN network may be provided in response to a request coming over DoIP, e.g. a firmware update.

A CAN-IF module <NUM> is the CAN interface module used to transmit/receive CAN frames.

A CAN-to-Ethernet (known as CAN2ETH) module <NUM> provides for encapsulation of the second messages received from the CAN-TP module <NUM> in some protocol over Ethernet. In this process, it could be that one CAN message is encapsulated in one Ethernet frame, or that multiple CAN messages of the messages generated by the CAN-TP module <NUM> are encapsulated within the Ethernet frame. It will be appreciated that the CAN2ETH module <NUM> may be configured to encapsulate CAN frame messages that have not been processed by CAN-TP, perhaps because it was not necessary given the size of the information they were carrying. Thus, the protocol data unit router module <NUM> may forward messages that do not require processing by a transport protocol to the CAN2ETH module <NUM> bypassing the CAN-TP module <NUM> and the CAN-IF module <NUM>.

The CAN2ETH block <NUM> may be preconfigured to include a predetermined number of CAN frames in each Ethernet frame. The predetermined number may be equal to or less than a known Block Size parameter of the nodes <NUM> in the second network <NUM> (which may be known at the time of building of the network <NUM> and/or configuring the apparatus <NUM> and transport apparatus <NUM>). In other examples, the predetermined number may be configured based on the block size parameter BS in the flow control frame message <NUM>, <NUM> by the apparatus <NUM>, which may be forwarded to the transport apparatus <NUM> after a first message of the flow has been sent. Thus, in some examples, for a particular CAN-TP flow, the number of CAN messages that the transport apparatus provides inside one Ethernet frame generated by module <NUM> may be no greater than the block size parameter (but could be smaller). It will be appreciated that the total number of CAN messages in the Ethernet frame could be greater if there are CAN frames belonging to multiple different flows.

In other examples, the transport apparatus <NUM> may be configured to place any number of second messages of the flow in an Ethernet frame and may rely on the apparatus <NUM> to dispatch the second messages in groups according to the Block Size parameter.

The CAN2ETH block <NUM> thus generates one or more first messages, comprising Ethernet messages, each having one or more second messages, comprising the CAN frame messages, encapsulated therein. The Ethernet format, first messages are then sent on the Ethernet network, represented by block <NUM>, to the apparatus <NUM>.

The information (which be in the form of one or more CAN messages) may be encapsulated within the payload fields of an Ethernet frame or a UDP message received at terminal <NUM>. If encapsulated in a UDP datagram, each second message may be associated with an identifier from which the CAN ID of the node <NUM> to which the second message is to be addressed can be determined (or may be indicative of the sender of the second message). Such an encapsulation will be known to those skilled in the art as AUTOSAR Socket Adapter Header Mode. In a further example, the encapsulation of the CAN messages (second messages) may be provided according to the principles of IEEE <NUM> AVTP ACF. Thus, the apparatus <NUM> and, optionally, the transport apparatus <NUM> may receive messages than include encapsulated therein second messages within the ACF message payload. Typically, an ACF message is transmitted directly over Ethernet, but UDP/IP is optional. An example of this message format can be found in the IEEE <NUM>-<NUM> standard, Figure <NUM>.

The apparatus <NUM> comprises at least a receive terminal <NUM> coupled to the first network <NUM> for receiving messages from the transport apparatus <NUM>. The receive terminal <NUM>, is configured to receive the one or more first messages from the transport apparatus <NUM> of the first network encoded according to the first protocol (whichever over-Ethernet protocol was used by the CAN2ETH block <NUM>). As mentioned above, said one or more first messages encapsulate a plurality of second messages for the CAN network <NUM>. Further, it will be appreciated that at least two or more of the CAN, second messages encapsulated within the Ethernet, first messages is part of a flow generated by the CAN-TP transport layer protocol block <NUM>.

The functionality of the apparatus <NUM> will now be described with reference to <FIG>, which shows the apparatus <NUM> of <FIG> in more detail.

<FIG> shows the receive terminal <NUM> for receiving the first messages from the Ethernet network <NUM>. The apparatus <NUM> may include a message processing block <NUM> configured to extract said encapsulated second messages from said one or more first messages.

The processing block <NUM> may also determine, for each of said extracted second messages and based on flow identifying information present in each of said extracted second messages, a flow to which the extracted second message belongs. In some transport layer protocols, an identifier may be added to each message that is part of the same flow. Thus, such an identifier can be used by the receiver <NUM> to reassemble the correct messages into the original information. In one or more examples, the flow identifying information may comprise at least part of the CAN ID or other header information of each of the second messages. Thus, it may be determined that all second messages that have the same CAN ID are part of the same flow, in some examples. In other examples, the processing block <NUM> may be configured to determine, for each of said extracted second messages and based on at least part of the CAN ID in each of said extracted second messages and at least part of a data field of each of said extracted second messages, the flow to which the extracted second message belongs. In other second protocols, the flow identifying information may be a dedicated field associated with transport protocol processed messages. Thus, depending on the transport protocol or implementation, the flow identifying information can take different forms but in summary it may comprise a part of the second message that identifies the flow to which the second message belongs either directly or indirectly. The flow identifying information may be indicative of a source node address or a unique identifier or group of unique identifiers associated with a source of the second messages. The flow identifying information may comprise part of the information carried in a data field of the second message and/or a message header. The flow identifying information may comprise a value in the second message which can be cross-referenced with a lookup table to determine the flow to which the second message belongs.

In one or more examples, the second messages are then passed to a traffic shaping block <NUM> which is configured to, for said extracted second messages that belong to the same flow, provide for transmission of said extracted second messages on the second network <NUM> encoded based on the second, CAN protocol with a time spacing therebetween greater than a predetermined minimum time spacing based on STmin. Thus, the apparatus <NUM> may be configured to queue the one or more second messages for sending and then send the consecutive frame messages of the flow respecting the minimum time spacing based on STmin.

It will be appreciated that a first of the plurality of second messages, comprising the first frame message <NUM> will be sent first and the apparatus <NUM> may be configured to await the first flow control message <NUM>. The apparatus <NUM> may use the STmin information in the first flow control message <NUM> (and any subsequent flow control message <NUM>) to set the predetermined minimum time spacing.

In other examples, the predetermined minimum time spacing or STmin parameter of at least one of nodes in the network <NUM> may be known and therefore the apparatus <NUM> may have a predetermined minimum time spacing to use. The predetermined minimum time spacing may be used without reading of the STmin parameter in the first (or optionally subsequent <NUM>) flow control message <NUM>. In other examples, the apparatus <NUM> may be configured to check the predetermined minimum time spacing against the STmin value and update the predetermined minimum time spacing if required.

The subsequent second messages comprise the first block of "consecutive frame messages" and are sent with a time spacing therebetween greater than or equal to the predetermined minimum time spacing. The message exchange proceeds as described in relation to <FIG>, wherein the apparatus <NUM> is the sender <NUM> and the node <NUM> (or any other addressed node) is the receiver <NUM>.

The apparatus <NUM> may be configured to forward the first flow control message <NUM> and any subsequent flow control message <NUM> to the transport apparatus <NUM>.

The apparatus <NUM> may include a processing block or, in more specific embodiments, a CAN-to-Ethernet block <NUM> to encapsulate the flow control CAN message(s) into one or more Ethernet messages, which are then transmitted over Ethernet via a transmit terminal <NUM> which couples to the Ethernet network and thus to the transport apparatus <NUM>. The transport apparatus <NUM> will receive encapsulated second message and will be configured to unpack it and process its contents according to the transport layer protocol. In this embodiment, the transport apparatus may be configured to provide it to the CAN-TP module <NUM>. The CAN-TP module <NUM> then be configured to send the remaining or next block size (BS) worth of second messages until transmission of the information is complete. In other examples, the CAN-TP module <NUM> may be configured not to await the flow control frames before providing all the CAN messages of the flow to the apparatus <NUM>. Thus, the apparatus <NUM> may be configured to queue the CAN messages received (in encapsulated form) from the transport apparatus <NUM> and send them in blocks in accordance with a predetermined BS parameter or which was read from the flow control frame messages <NUM>, <NUM> by the apparatus <NUM>.

In the example of <FIG>, the processing block <NUM> and processing block <NUM> are shown coupled to a plurality of second networks <NUM> by first interface <NUM> and second interface <NUM>. Thus, the apparatus <NUM> may provide for the predetermined minimum time spacing for a plurality of second networks by way of traffic shaping block <NUM> and a further traffic shaping block <NUM> for each other second network <NUM>.

<FIG> shows an example of the traffic shaping module <NUM> with the functionality represented as a series of blocks. The traffic shaping module <NUM> includes a timer <NUM> configured to define said predetermined minimum time spacing. The module <NUM> includes a dispatch module <NUM> configured to only allow for said transmission of a subsequent one of the CAN messages of a flow after said predetermined minimum time spacing has expired following transmission of a preceding message in the same block <NUM>, <NUM> of the flow. In one or more examples, the apparatus <NUM> may be configured to await an acknowledgement message confirming receipt of each second message before sending the next (as well as adhering to the predetermined minimum time spacing).

The module <NUM> may be configured to receive each of the CAN messages at input <NUM>. The module <NUM> may receive the predetermined minimum time spacing at input <NUM> from the processing module <NUM>. Alternatively, it may be stored at the module <NUM>. The module <NUM> may receive flow identifying information (which may be derived from CAN ID or other information stated in the second message(s)) at input <NUM>.

Thus, the module <NUM> may receive the CAN message of the indicated flow at block <NUM>. Until the timer <NUM> has counted down, the CAN message is held in a queue. Once the predetermined time spacing has expired the module is configured to reset the timer to the predetermined time spacing value at block <NUM>. The message is then dispatched for transmission by block <NUM>, as mentioned previously.

The module <NUM> also receives the acknowledgement or flow control frame messages at block <NUM>. The predetermined minimum time spacing of the timer <NUM> may be set to run in response to the flow control message or an acknowledgement of receipt at block <NUM>.

In the examples described above the first protocol was Ethernet and the second protocol was CAN. However, in other examples, said first network may operate based on a first protocol comprising one of Ethernet, Token Ring protocol, Synchronous optical networking protocol, frame relay protocol, Asynchronous Transfer Mode protocol. In other examples, said second network may operate based on a second protocol comprising one of a Controller Area Network (CAN) protocol, a FlexRay protocol, and LIN protocol. It will be appreciated that reference to the CAN protocol here includes CAN-FD and, possibly, the proposed CAN-XL versions of the protocol.

<FIG> shows an example method of operating an apparatus <NUM> that provides an interface between a first network <NUM> configured to operate based on a first protocol and at least a second network <NUM> configured to operate based on a second protocol, different to the first protocol. The method comprising:.

The method may comprise, performed by a transport apparatus <NUM> coupled to the apparatus <NUM> by the first network, the step <NUM>. Step <NUM> comprises generating a plurality of second messages according to a transport layer protocol and generating one or more first messages by encapsulation of the second messages, wherein the first messages are generated in accordance with the first protocol for transmission on the first network to the apparatus <NUM>.

In this specification, example embodiments have been presented in terms of a selected set of details.

Claim 1:
An apparatus (<NUM>) for providing an interface between a first network (<NUM>) configured to operate based on a first protocol and at least a second network (<NUM>) configured to operate based on a second protocol, different to the first protocol, the apparatus comprising:
a receive terminal (<NUM>) configured to receive one or more first messages from the first network (<NUM>) encoded according to the first protocol wherein said one or more first messages encapsulate a plurality of second messages; and
wherein said apparatus (<NUM>) is configured to:
extract said encapsulated second messages from said one or more first messages;
determine, for each of said extracted second messages, and based on flow identifying information of each of said extracted second messages, a flow to which the extracted second message belongs, said flow comprising a plurality of the extracted second messages that form a set; and
for said extracted second messages that belong to the same flow, provide for transmission of said extracted second messages on the second network encoded based on the second protocol with a time spacing therebetween greater than or equal to a predetermined minimum time spacing (<NUM>).