Patent Description:
Nowadays, the automotive electronics industry is immersed in a deep transformation in response to the new era of mobility, in search of the future autonomous, connected, electric and shared vehicle.

Triggered by this transformation, the automotive electrics/electronics (E/E) & in-vehicle networking (IVN) architectures of vehicles are transitioning from a domain-based approach - which includes splitting the functionality of the vehicle in a logical way through functional domains - to a new approach that is driven by a zonal distribution, wherein mixed functions of whatever domain coexist in each physical zone. Thus, the wiring harness scalability wall detected in the precedent solutions may be overcome.

An immediate impact of this transition is the game changer role to be played by the gateway controller in a UE, particularly vehicle. While in the domain-based E/E architecture the gateway controller deploys the role of a central gateway, which is responsible for interconnecting the different domain controllers (e.g., advanced driver-assistance systems (ADAS), infotainment, body, cockpit, energy management, etc.) through a network backbone like automotive Ethernet, in the new zone-base architecture the complete vehicle functionality is redistributed not through domain controllers, but in one or more central computers and several zonal gateway controllers, particularly, one per each physical zone.

The role of the new zonal gateway controller consists in the power and communication management of one specific physical zone of the vehicle. Due to this new architectural approach, the zonal gateway controller is becoming more and more a key piece of the vehicle infrastructure.

Gatewaying is, by nature, a complex and high demanding processing/computational task. The gateway controller takes charge of receiving and sending frames from ingress ports to egress ports by encapsulating, aggregating and/or processing Protocol Data Units (PDUs) or data frames according to networking protocols and standards, in particular, in line with the well-known network Open Systems Interconnection (OSI) model, which is decomposed in layers.

One of the main challenges seen in the automotive gateway controller is the coexistence of heterogeneous networking technologies and protocols: on the one side, automotive legacy busses like Controller Area Network (CAN), Local Interconnect Network (LIN), FlexRay and, on the other side, new network protocols recently adopted from information and communications technology (ICT) and high-performance computing (HPC) fields, for instance, Ethernet, Mobile Industry Processor Interface (MIPI) or Peripheral Component Interconnect express (PCIe). Some examples of frame structures for different technologies and protocols - namely for LIN <NUM>, CAN <NUM>, CAN FD <NUM>, CAN XL <NUM>, FlexRay <NUM>, and Ethernet <NUM> - are depicted in <FIG>.

The engineering effort required to develop an automotive electronic gateway controller (i.e., hardware (HW) and software (SW) co-design) cannot be underestimated: a big team of several tens of HW, SW and system engineers typically works together for a long time, normally not less than one or two years, and is required to cover the full product development cycle, from concept to design and development (D&D) to verification and validation (V&V) to Start-of-Production (SOP).

Conventionally, the functional gateway implementation is mainly based on a SW implementation. This solution is typically CPU-centric, i.e., the gatewaying and processing is deployed in SW running of one or more cores of a Microcontroller Unit (MCU) or System-on-Chip (SoC) device.

It is important to note here that also the interconnection of CAN, LIN, FlexRay, or Ethernet frames is conventionally done in SW. That is, the CPU or MCU reads ingress frames from CAN reception buffers and transfer them to Ethernet (ETH) egress buffers in case of performing the tunneling or gatewaying of CAN-to-ETH. However, this approach based on SW, although de facto a solution today, is not the best choice when moving to autonomous driving (AD) solutions, particularly not in terms of latency and performance of next-gen L3-to-L5 AD vehicles.

<CIT> discloses a network gateway in a vehicle, which connects heterogeneous networks and buses within the vehicle. The gateway implements hardware acceleration to accomplish protocol translation, e.g., between CAN, LIN, Flexray, and Ethernet buses and networks. In particular, the gateway provides hardware accelerated packet filtering, header lookup, and packet aggregation features.

In view of the above, an objective of this disclosure is to provide a device and a method that enable a HW-driven gatewaying approach, in particular, in view of the coexistence of the heterogeneous networking technologies and protocols, for example, as described above.

This objective is achieved by the embodiments of this disclosure as described in the enclosed independent claims. Advantageous implementations of the embodiments are further defined in the dependent claims.

In particular, these embodiments are based on the following considerations.

The gateway controller is responsible for performing a full set of networking features, mainly the data encapsulation, forwarding/routing, tunneling and processing of PDUs among different networks of a given in-vehicle network infrastructure. This heterogeneity of network technologies and protocols increases the complexity and the computing effort demanded to the gateway controller. Consequently, unlike other networking devices - like enterprise switches or routers based only on Ethernet technology - in the particular case of an automotive gateway controller, the diversity and heterogeneity of network technologies and protocols coexisting at the same time in the same device is a feature that increases notoriously the complexity of the networking device, especially regarding the handling at real-time of ingress and egress frames of different nature. The embodiments of this disclosure thus put their focus on these problems, and are especially aimed on contributing an effective implementation solution.

The ideal gateway processing would consist in performing the adaptation of frames (particularly PDUs) from one network to another, while minimizing the effects of this transformation. For instance, minimizing the latency of such processing when moving the frames or PDUs from one or more ingress ports to one or more egress ports of the gateway controller (e.g., according to the switching/routing mechanisms in place). Many of these tasks performed by the gateway controller are time consuming tasks, for instance, the protocol conversion and data encapsulation from one network to another, as depicted in <FIG>.

In view of the above, the embodiments of this disclosure aim to enable frame normalization, which is applicable to the gatewaying of heterogeneous networks. The implementation of this concept should be provided in a very flexible way in HW. Nevertheless, the embodiments should be fully Software Defined Networking (SDN) compliant. The embodiments have the further goal of providing a scalable solution in terms of geometry (e.g., including the number of ingress and egress ports, the kind of network protocols, etc.) and features (e.g., cut-through or store-and-forward mode, integrity check based on cyclic redundancy check (CRC), checksum (CS) or parity bit (PB), etc.).

These and other goals are also achieved by the embodiments of this disclosure. All in all, the PDU normalization concept proposed here becomes a new dimension or abstraction layer not covered by the OSI model and its <NUM> abstraction layers, in the sense that it enables the handling of several heterogeneous networks at the same time instead of only a single one.

A first aspect of this disclosure provides a device for a gateway controller of a user equipment, the device comprising processing circuitry configured to: receive one or more ingress frames of bits, wherein each ingress frame has one of multiple frame formats included in a set of frame formats; and convert each ingress frame into a normalized frame of bits, wherein each normalized frame has a normalized frame format.

Accordingly, the device of the first aspect is configured to normalize frames of heterogeneous networking technologies and protocols. Thus, the gateway controller may be provided with this function by employing the device. In particular, the gateway controller may be or comprise the device of the first aspect. The UE may comprise the gateway controller, and the UE may be a vehicle. The device of the first aspect enables, in particular, a HW-driven gatewaying approach. However, the device may be SDN compliant as well. The device is scalable in terms of geometry, e.g., the number of ingress and egress ports may be increased in the future, and different kind of network protocols can be added easily. Further, the device is scalable in terms of features, e.g., various kind of functionalities may be added and embedded across its system/hardware architecture, for example, as shown in <FIG>.

In an implementation form of the first aspect, the set of frame formats comprises one or more frame formats according to the following protocols: CAN; CAN FD; CAN XL; LIN; FlexRay; Media Oriented System Transport; Ethernet; MIPI Camera Serial Interface <NUM>.

These are just examples of frame formats that the device of the first aspect may handle. Other frame formats may be possible, and new frame formats may be added in the future.

In the first aspect each normalized frame comprises a plurality of fields, wherein each field is parameterized by a field index or offset parameter and a field size parameter.

Any network frame may be considered a bitstream organized in a certain number of fields of different sizes, each field having a different and particular meaning at application level. The fields may be distributed in different positions along the data frame. From this perspective, any frame can be managed in a standardized way independently of its original nature.

In an implementation form of the first aspect, each normalized frame comprises a header, a payload, and a trailer, and the payload of each normalized frame comprises the respective ingress frame.

Thus, the ingress frame may be transported in a normalized frame. Independently of the type of ingress frame, the normalized frame may thus be handled by one or more processing stages of the gateway controller.

In an implementation form of the first aspect, each normalized frame comprises an instruction frame in a control plane and a data frame in a data plane, wherein the data frame comprises the respective ingress frame.

In an implementation form of the first aspect, the instruction frame comprises a header, a payload, and a trailer, and the payload of the instruction frame comprises an instruction that indicates how the data frame is processed in each of one or more processing stages of the processing circuitry.

The instruction frame and the data frame are thus separated, and the instruction frame may indicated - as metadata - how the data frame should be processed in one or more processing stages of the gateway controller.

In an implementation form of the first aspect, the instruction frame comprises a length of the instruction and one or more parameters of the instruction as metadata of the respective data frame.

In an implementation form of the first aspect, the header and payload of the instruction frame comprises one or more of: a port number or ID where the respective ingress frame was received; a network type or protocol related to the respective ingress frame; a frame timestamp; a frame length; a frame priority; a number of bits of the normalized frame per clock; a counter of matches; a gateway command or action to be executed on the ingress frame.

Notably, the counter of matches may be filled in later, for example, in a matching and action stage.

In an implementation form of the first aspect, the trailer of the instruction frame comprises a CRC of the instruction or a CS of the instruction, or a PB of the instruction as integrity check mechanism applied to the entire instruction frame.

Thus, an integrity check mechanism can be applied, regardless of the ingress frame format.

In an implementation form of the first aspect, the processing circuitry comprises one or more ingress ports, each ingress port being configured to receive one or more ingress frames of a particular frame format according to a particular protocol of the multiple frame formats included in the set of frame formats.

The ingress ports may be scalable, that is, further ingress ports for further frame formats may be added to the processing circuitry. Thus, the device is scalable.

In an implementation form of the first aspect the processing circuitry further comprises a set of registers, and the set of registers is configurable with a set of parameters for relating each of the one or more ingress ports to one or more networking features and/or protocols to be applied to the one or more ingress frames received at that ingress port to normalize the ingress frames.

This allows easy configuration of the device of the first aspect. The device of the first aspect thus enables a very flexible way for the gatewaying provided in HW.

In an implementation form of the first aspect the processing circuitry further comprises a First-In First-OUT (FIFO) for each of the ingress ports, and each FIFO is adapted to receive and forward the bits of the one or more ingress frame received at that ingress port.

In an implementation form of the first aspect, the processing circuitry further comprises an instruction generator configured to construct the instruction frame for each respective ingress frame, wherein the instruction frame is constructed based on the respective ingress frame and the set of parameters for the ingress port where the respective ingress frame is received.

In an implementation form of the first aspect, the processing circuitry is further configured to write or store the data frame received at the ingress port in the FIFO in the data plane and at the same time to generate the instruction frame in the control plane.

In an implementation form of the first aspect, the processing circuitry is further configured to read the data frame stored in the FIFO in the data plane from the FIFO and at the same time read the instruction frame from the control plane, so that both frames are moved forward synchronously to the next one or more processing stages of the processing circuitry.

A second aspect of this disclosure provides a method for a gateway controller of a user equipment, the method comprising: receiving one or more ingress frames of bits, wherein each ingress frame has one of multiple frame formats included in a set of frame formats; and converting each ingress frame into a normalized frame of bits, wherein each normalized frame has a normalized frame format, wherein each normalized frame (<NUM>) comprises a plurality of fields (<NUM>), wherein each field (<NUM>) is parameterized by a field index or offset parameter and a field size parameter.

In an implementation form of the second aspect, the set of frame formats comprises one or more frame formats according to the following protocols: CAN; CAN FD; CAN XL; LIN; FlexRay; Media Oriented System Transport; Ethernet; MIPI; Camera Serial Interface <NUM>.

In an implementation form of the second aspect, each normalized frame comprises a header, a payload, and a trailer, and the payload of each normalized frame comprises the respective ingress frame.

In an implementation form of the second aspect, each normalized frame comprises an instruction frame in a control plane and a data frame in a data plane, wherein the data frame comprises the respective ingress frame.

In an implementation form of the second aspect, the instruction frame comprises a header, a payload, and a trailer, and the payload of the instruction frame comprises an instruction that indicates how the data frame is processed in each of one or more processing stages of the processing circuitry.

In an implementation form of the second aspect, the instruction frame comprises a length of the instruction and one or more parameters of the instruction as metadata of the respective data frame.

In an implementation form of the second aspect, the header and payload of the instruction frame comprises one or more of: a port number or ID where the respective ingress frame was received; a network type or protocol related to the respective ingress frame; a frame timestamp; a frame length; a frame priority; a number of bits of the normalized frame per clock; a counter of matches; a gateway command or action to be executed on the ingress frame.

As described before, the counter of matches may be used in the matching and action stage.

In an implementation form of the second aspect, the trailer of the instruction frame comprises a CRC of the instruction or a CS of the instruction, or a PB of the instruction as integrity check mechanism applied to the entire instruction frame.

In an implementation form of the second aspect, the method comprises receiving, at each ingress port of one or more ingress ports, one or more ingress frames of a particular frame format according to a particular protocol of the multiple frame formats included in the set of frame formats.

In an implementation form of the second aspect, the method further comprises configuring a set of registers with a set of parameters for relating each of the one or more ingress ports to one or more networking features and/or protocols to be applied to the one or more ingress frames received at that ingress port to normalize the ingress frames.

In an implementation form of the second aspect, the method further comprises receiving and forwarding, by a FIFO for each of the ingress ports, the bits of the one or more ingress frame received at that ingress port.

In an implementation form of the second aspect, the method comprises constructing the instruction frame for each respective ingress frame, wherein the instruction frame is constructed based on the respective ingress frame and the set of parameters for the ingress port where the respective ingress frame is received.

In an implementation form of the first aspect, the method further comprises writing or storing the data frame received at the ingress port in the FIFO in the data plane and at the same time generating the instruction frame in the control plane.

In an implementation form of the first aspect, the method further comprises reading the data frame stored in the FIFO in the data plane from the FIFO and at the same time reading the instruction frame from the control plane, so that both frames are moved forward synchronously to the next one or more processing stages.

The method of the second aspect and its implementation forms achieve the same advantages described above for the device of the first aspect and its respective implementation forms.

A third aspect of this disclosure provides a computer program comprising a program code for performing the method according to the second aspect or any of its implementation forms, when executed on a processor.

A fourth aspect of this disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the second aspect or any of its implementation forms to be performed.

<FIG> shows schematically a general solution proposed by this disclosure to the above mentioned objectives and goals. In particular, <FIG> shows a device <NUM> according to an embodiment of this disclosure. The device <NUM> is usable in a gateway controller of a user equipment, e.g., of a vehicle. That is, the device <NUM> may be implemented in an automotive gateway controller. The device <NUM> may also be the automotive gateway controller. The device comprises processing circuitry <NUM>. The processing circuitry <NUM> may comprise one or more processing stages of the gateway controller. The processing circuitry <NUM> may, however, also be one processing stage of the gateway controller (responsible for frame normalization) and the gateway controller may comprise additional processing circuitry to implement further processing stages.

The processing circuitry <NUM> is configured to perform, conduct or initiate various operations of the device <NUM>, which are described in this disclosure. The processing circuitry <NUM> may comprise hardware and/or the processing circuitry <NUM> may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The device <NUM> may further comprise memory circuitry, which may store one or more instruction(s) that can be executed by the processing circuitry <NUM>, in particular, under control of software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code, which, when executed by the processing circuitry <NUM>, causes various operations of the device <NUM> to be performed. In one embodiment, the processing circuitry <NUM> comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code, which, when executed by the one or more processors, causes the device <NUM> to perform, conduct, or initiate the operations or methods described in this disclosure.

In particular, the processing circuitry <NUM> is configured to receive one or more ingress frames <NUM> of bits. Each ingress frame may comprises multiple bits that are organized into multiple fields having different meaning. An ingress frame may be a PDU. Each ingress frame <NUM> has one of multiple frame formats (illustrated schematically as A, B, C in <FIG>), wherein these multiple frame formats included in a set of frame formats. The set of frame formats may, in particular, comprise one or more frame formats according to the following protocols (see also <FIG>): CAN <NUM>; CAN FD <NUM>; CAN XL <NUM>; LIN <NUM>; FlexRay <NUM>; Media Oriented System Transport; Ethernet <NUM>; MIPI Camera Serial Interface <NUM>.

The processing circuitry <NUM> of the device <NUM> is further configured to convert each ingress frame <NUM> into a normalized frame <NUM> of bits. Each normalized frame <NUM> has a normalized frame format (illustrated schematically as N). Each normalized frame may include multiple bits - including the bits of the respective ingress frame - which are organized into fields of different size and meaning. The number of bits, number of fields, meaning of fields, size of fields etc. differs between the ingress frame format and the normalized frame format.

Accordingly, the device <NUM> - based on the processing circuitry <NUM> - is configured to function as a frame normalizer, in particular, may function as a PDU normalizer. The normalized frames <NUM> may be provided to a next processing stage of the gateway controller.

Advantageously, a gap of network & communication systems can be filled by developing a new gateway controller architecture based on the device <NUM> shown in <FIG>. The new gateway controller architecture may bring a better level of design granularity to reach a better performance in key performance indicators (KPIs), like latency, jitter, throughput, and cost-effectiveness based on the all-in-one approach, i.e., the development of a common processing unit able to manage different networking frames or protocols at the same time instead of developing a dedicated processing unit per each network frame. This may take the architecture of complex networking systems and products, which merge heterogeneous networking protocols, to the next level.

In the following, more detailed embodiments of this disclosure, and also considerations that led to the embodiments of this disclosure, are described.

The frame normalization enabled by the device <NUM> is based on the fact that every network technology/protocol manages layers <NUM> and above of the OSI model with a specific controller or logic (of course based on a different layer <NUM> or PHY technology). This is exemplarily depicted in <FIG> for a conventional gateway.

Based on this fact, an idea on which embodiments of this disclosure are based, is to somehow replace the protocol-specific network controller by a new gateway controller that is valid for any networking protocol. That is, to try to normalize or standardize the processing, in order to make it invariant to the network protocol. The idea is then to bring a new level of abstraction to the network architect, which is referred to as the "frame normalization" in this disclosure.

The frame normalization concept of this disclosure is schematically illustrated in <FIG> The concept consists in developing a new HW peripheral or coprocessor that may be embedded in a network SoC device and that takes the role of normalizing the ingress frames - coming from whatever ingress port of the automotive gateway controller - independently of their nature and/or protocol (e.g., CAN, LIN, FlexRay, Ethernet, etc., see above). The main advantage of such a new processing stage introduced in the gateway controller is the fact that this stage can be stated as a standard processing synthesized in a common way, instead of synthesizing different kinds of controllers that each depend on the nature of the ingress ports of the gateway controller.

Based on this ideas, the device <NUM> is provided. Further, on the basis of this device <NUM>, a next-generation automotive gateway controller <NUM> is proposed as a very flexible, modular, and adaptable system. Just for this reason, this concept is also named elastic gateway controller <NUM>. The architecture, or high level design, of an automotive gateway controller <NUM> aligned with embodiments of this disclosure is shown in <FIG>.

The gateway controller architecture shown in <FIG> is oriented to exploit both hardware parallelism and pipelining strategies, based on a sequential and ultra-fast ingress-to-egress data path, targeting to optimize the processing latency of every frame. As shown in <FIG>, the functional architecture of the automotive gateway controller <NUM> can be decomposed, at a first level of abstraction, into a sequence of processing stages deployed in HW by means of dedicated and reconfigurable coarse-grained functional blocks, apart from the CPU interaction, giving rise to a data path for the frames from ingress to egress ports:.

The functions embedded in the main HW blocks that compose the full data path of the gateway in <FIG> are detailed next:.

The data path and the set of functions shown in <FIG> are proposed as the right building blocks needed to compose whatever scalable automotive gateway that any OEM could demand.

In order to standardize the computation of the different internal stages of the gateway controller <NUM>, a new gateway processing protocol may be used through the definition and handling of a command or instruction in each processing stage. The format of this instruction may be based on a control frame (or instruction frame <NUM>, see <FIG> and <FIG>), which may be composed of instruction frame fields distributed through header <NUM>, payload <NUM>, and trailer <NUM>, and which are shifted from a building block to the next one in the data path. The header <NUM> may collect global information of the instruction, while the payload <NUM> may refers to specific parameters of the instruction related to every processing stage. Finally, the trailer <NUM> of the instruction frame <NUM> may provide an integrity check of the instruction frame <NUM> through, for instance, a CRC or CS computation. This approach is compliant with the SDN concept, wherein the network processing gets split in control plane and data plane.

The explanation above is the ground for the normalization strategy for the heterogeneous network frames implemented by the device <NUM>, for instance, in an automotive gateway controller. <FIG> depicts a normalized frame <NUM>. At a conceptual level, whatever network ingress frame <NUM>, can be seen as a bitstream organized in certain number of fields of different sizes, each one with a different and particular meaning at application level and distributed in different positions along the data ingress frame <NUM>. That abstraction step may provide the basis for the normalization.

Likewise, also the normalized frame <NUM> shown in <FIG> may comprise fields <NUM> that may be distributed over a header <NUM>, payload <NUM> (which may comprise the ingress frame <NUM>), and trailer <NUM>. Each field <NUM> can be parameterized by a field index or offset parameter and a field size parameter. From this new perspective of the normalized frame <NUM>, any ingress frame <NUM> can be managed by the device <NUM> and subsequently the gateway controller <NUM> in a standardized way independently of its original nature.

It is important to highlight here that this normalization may be enabler by providing the device <NUM> with a set of parameters in the way of configurable registers <NUM> (see e.g., <FIG>), which may be instantiated inside the HW peripheral to allow the system architect or developer to configure each ingress port <NUM> of the device <NUM> (and accordingly of the gateway controller <NUM>, see <FIG>). Each ingress port <NUM> may be configured to receive one or more ingress frames <NUM> of a particular frame format according to a particular protocol of the multiple frame formats included in the set of frame formats.

As shown in <FIG>, the device <NUM> may be the first processing stage of the gateway controller. A device <NUM> according to an embodiment of this disclosure is shown in <FIG>. The device <NUM> of <FIG> builds on the device <NUM> shown in <FIG>. Same elements are labelled with the same reference signs and may be implemented in an identical manner.

In particular, a possible microarchitecture of the device <NUM> is shown in <FIG>. The design of the device <NUM> may follow the SDN approach with the ingress frame <NUM> coming from the ingress port <NUM> being handled as a data frame <NUM> in the data plane <NUM> and an instruction frame <NUM>, composed by the metadata of that ingress frame <NUM>, processed in the control plane <NUM>.

As shown in <FIG>, the device <NUM> (its processing circuitry <NUM>) may comprise a set of registers <NUM>. The set of registers <NUM> is configurable with a set of parameters for relating each of the one or more ingress ports <NUM> to one or more networking features and/or protocols to be applied to the one or more ingress frames <NUM> received at that ingress port <NUM>, in particular, to normalize the ingress frames <NUM>.

Further, the device <NUM> (its processing circuitry <NUM>) may further comprise a FIFO <NUM> for each of the ingress ports <NUM>. Each FIFO <NUM> may be adapted to receive and forward the bits of the one or more ingress frames <NUM> received at that ingress port <NUM>. The device <NUM> is configured to write or store the data frame <NUM> related to the ingress frame <NUM> received at the ingress port <NUM> in the FIFO <NUM> in the data plane <NUM>, and at the same time to generate the instruction frame <NUM> in the control plane <NUM> based on the metadata of the ingress frame <NUM>.

The device <NUM> (its processing circuitry <NUM>) may also comprise an instruction generator <NUM>, which is configured to construct the instruction frame <NUM> for each respective ingress frame <NUM>. The instruction frame <NUM> may be constructed based on the respective ingress frame <NUM> and the set of parameters for the ingress port <NUM> (configured in the register(s) <NUM>), where the respective ingress frame <NUM> is received.

The device <NUM> may additionally be configured to read the data frame <NUM> stored in the FIFO <NUM> and at the same time read the instruction frame <NUM>, so that both frames <NUM>, <NUM> are moved forward synchronously to the next one or more processing stages of the device <NUM> (or the gateway controller <NUM>).

<FIG> shows an exemplary instruction frame <NUM> used by the device <NUM>. The instruction frame <NUM> comprises a header <NUM>, a payload <NUM>, and a trailer <NUM>. The payload <NUM> of the instruction frame <NUM> comprises an instruction <NUM>, which indicates how the data frame <NUM> is processed in each of one or more processing stages of the processing circuitry <NUM> or gateway controller <NUM> (se <FIG>).

The header <NUM> and payload <NUM> of the instruction frame <NUM> may comprise one or more of: a port number or ID where the respective ingress frame <NUM> was received; a network type or protocol related to the respective ingress frame <NUM>; a frame timestamp; a frame length; a frame priority; a number of bits of the normalized frame per clock; a counter of matches; a gateway command or action to be executed on the ingress frame <NUM>.

The trailer <NUM> of the instruction frame <NUM> may comprise a CRC of the instruction <NUM> or a CS of the instruction <NUM>, or a PB of the instruction <NUM>. This may provide an integrity check mechanism applied to the entire instruction frame <NUM>.

In the gateway controller <NUM>, the internal instruction frame <NUM> may be handled through a control bus that is shifted through the different modular processing stages of the gateway controller <NUM> in parallel and synchronously to every network frame in <FIG>. The instruction <NUM> may obey to a new internal gateway processing protocol defined by means of data fields detailed in <FIG>.

<FIG> shows a composition of the instruction frame <NUM> from the ingress frame <NUM>. The ingress frame <NUM> comprises header, payload, and trailer. The normalized frame <NUM> may also comprise header <NUM>, payload <NUM>, and trailer <NUM> as shown in <FIG>. The normalized frame <NUM> may be distinguished into the data frame <NUM> in the data plane <NUM>, and the instruction frame <NUM> in the control plane <NUM>. The instruction frame <NUM> may be constructed based on the respective ingress frame <NUM> and the set of parameters for the ingress port <NUM> where the respective ingress frame <NUM> is received.

<FIG>, <FIG>, and <FIG> show an example of a PDU Normalizer Engine (device <NUM>), and its set of configurable parameters.

In particular, <FIG> shows that the PDU Normalizer Engine (similar to the device <NUM> shown in <FIG> but with further level of detail), operates in control plane <NUM> (on the instruction frame <NUM>) and the data plane <NUM> (on the data frame <NUM>). The PDU Normalizer engine comprises one or more configuration registers <NUM>, wherein parameters can be set to configure each of one or more ingress ports <NUM>. To this end, the registers <NUM> may be connected to the host CPU. At each ingress port <NUM> a particular frame format may be handled. That is, ingress frames <NUM> of a specific frame format are received. The PDU Normalizer Engine also comprises the FIFO <NUM> to move the data frame <NUM> related to the ingress frame <NUM>.

<FIG> illustrates an instruction generation as part of the normalization process performed by the device <NUM>. The instruction generator <NUM> is responsible for filling in all the fields of the instruction frame <NUM> linked to each ingress frame <NUM>. Every field of the instruction <NUM>, allocated in the header <NUM>, payload <NUM>, and trailer <NUM>, may be filled in by either direct data coming from the configuration registers <NUM> set by the architect/programmer or computed at run time (on the fly) by the HW blocks of the instruction generator <NUM> based on the data frame <NUM> received through the ingress port <NUM>.

<FIG> illustrates an exemplary memory map of the PDU normalizer engine, in particular, a set of configurable registers <NUM> of the PDU normalizer engine organized in words of a specific size. Every configurable register <NUM> describes a set of parameters that configure the physical geometry (e.g. bus size, FIFO size, etc.) and behavior (e.g. padding, integrity check, etc.) of the PDU normalizer engine.

<FIG> shows a method <NUM> according to an embodiment of this disclosure. The method <NUM> may be performed by the device <NUM> or by the gateway controller <NUM>. In any case, the method <NUM> is suitable for a gateway controller <NUM> of a UE, for instance, a vehicle. The method <NUM> comprises a step <NUM> of receiving one or more ingress frames <NUM> of bits, wherein each ingress frame <NUM> has one of multiple frame formats A, B, C included in a set of frame formats. Further, the method <NUM> comprises a step <NUM> of converting <NUM> each ingress frame <NUM> into a normalized frame <NUM> of bits, wherein each normalized frame <NUM> has a normalized frame format N.

In summary, this disclosure proposes a new methodology, based on the device <NUM>, to build physical Gateway ECUs embedding the set of functionality required and specified by the user through the HW/SW co-design of such functions. Like this, part of this functionality may be implemented in SW to run on a CPU, and another part may be synthesized in HW in the way of coprocessors, peripherals or HW engines interconnect to the system-on-chip or microcontroller where the full gateway ECU application is integrated, as shown in <FIG>. For such a goal, the frame normalization performed by the device <NUM> is a novel and key stage of this process.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claim 1:
A device (<NUM>) for a gateway controller (<NUM>) of a user equipment, the device (<NUM>) comprising processing circuitry (<NUM>) configured to:
receive one or more ingress frames (<NUM>) of bits, wherein each ingress frame (<NUM>) has one of multiple frame formats (A, B, C) included in a set of frame formats; and
convert each ingress frame (<NUM>) into a normalized frame (<NUM>) of bits, wherein each normalized frame (<NUM>) has a normalized frame format (N),
wherein each normalized frame (<NUM>) comprises a header (<NUM>), a payload (<NUM>), and a trailer (<NUM>), and the payload (<NUM>) of each normalized frame (<NUM>) comprises the respective ingress frame (<NUM>).