EP4324165A1

EP4324165A1 - In-vehicle network for context aware real-time traffic specific network configuration

Info

Publication number: EP4324165A1
Application number: EP21721501.1A
Authority: EP
Inventors: Sujan Pandey
Original assignee: Huawei Technologies Co Ltd
Current assignee: Shenzhen Yinwang Intelligenttechnologies Co Ltd
Priority date: 2021-04-26
Filing date: 2021-04-26
Publication date: 2024-02-21
Also published as: CN117242746A; WO2022228643A1

Abstract

Provided is a sensor (100, 202) for use in an in-vehicle network (104, 200, 300), for communicating with at least one other unit in the in-vehicle network by means of packets through a switch (102, 204, 400). The sensor is being arranged to create sensor-specific traffic information indicating at least one configuration parameter to be used for transmitting packets to or from the sensor, and communicate the sensor-specific traffic information to the switch. The traffic information is being based on the type of sensor and on context data indicative of a current traffic situation.

Description

IN-VEHICLE NETWORK FOR CONTEXT AWARE REAL-TIME TRAFFIC SPECIFIC NETWORK CONFIGURATION

TECHNICAL FIELD

The disclosure relates generally to an in-vehicle network, and more particularly, the disclosure relates to a sensor for use in an in-vehicle network, for communicating with at least one other unit in the in-vehicle network by means of packets through a switch. Moreover, the disclosure also relates to a method for an in-vehicle network.

BACKGROUND

In-vehicle network is the back-bone of the fail-proof electronic systems that communicate with several sensors & mechanical parts within a vehicle. Depending on weather, environmental, location, situation, etc., it is obvious that there may be many contexts in terms of sensing and reacting in the in-vehicle network. Further, depending on a context, data traffic from a same type of sensors may not demand a fix network resources all the time. For example, sometimes, some contexts may need more data, than other context. The different contexts depend on different types of sensors. Architecting the in-vehicle network with a fixed network configuration for autonomous driving is not realistic because of its battery or power supply. Configuring the in-vehicle network is not new for the enterprise and consumer, but has more constraints in vehicles, as it is more critical, and should not be hacked. In-vehicle network security is very important to maintain secure and reliable communication in a vehicle, thus it is not easy to adopt an exact solution in an automotive industry. Thus, there is a need to find a solution to balance among complexity and security to enable the in-vehicle network configuration.

In known solutions, sensor data from the sensors is periodically transported through the switches to an electronic control unit (ECU), where data processing takes place. Sensor data hops over many physical layers (PHYs) and switches before it reaches the ECU. A link between the switches and a link between the switch and the ECU act as backbones, which carry many different traffics (e.g. the sensor data) with different requirements. Further, these links may handle video and control data. Sensor (e.g. a camera, a radar, a powertrain) data is crucial for latency. The control data is crucial for bit-error-rate (BER). The BER is very important for powertrain data. The powertrain is a mechanism that transmits the drive from an engine of the vehicle to its axle. Few errors in pixels of the sensor data do not matter much when compared to the importance of latency. However, for control data, there may be no errors. Under these circumstances, the links may find a compromise to satisfy a different set of traffics and may need to configure network parameters in real-time. Sometimes, depending on circumstances/contexts, there is a need to allocate bandwidth for specific traffic. In bad visibility, crowed/busy or faulty situations, sensor (e.g. a camera) parameters (e.g. a frame rate, a resolution, a data flow path, etc.) may need to change, and there is a need to allocate bandwidth in real-time.

In known solutions, for example, in enterprise’s internet protocol (IP) based communication, it is possible to demand/configure a network depending on the requirement by a client. Typically, the sensors in the in-vehicle network are equipped with no intelligence. Further, the intermediate switches are not equipped with a powerful processor to understand the context and to choose the correct network configuration. However, it is possible to realize the context and to choose the right network configuration for the vehicle, but it is not realistic due to its security, cost, and complexity issues. Currently, in known solutions, the bandwidth allocation and priority handling are performed based on traffic policing techniques, which are mostly based on IEEE 802.1 standard specification. The IEEE 802.1 based technique is not real-time solution, rather fixed for each stream and traffic class for the automotive industry.

Therefore, there arises a need to address the aforementioned technical drawbacks and problems in configuring a secure network in the in-vehicle. SUMMARY

It is an object of the disclosure to provide a sensor for use in an in-vehicle network, for communicating with at least one other unit in the in-vehicle network by means of packets through a switch, the in-vehicle network, and a method for the in-vehicle network while avoiding one or more disadvantages of prior art approaches. This object is achieved by the features of the independent claims. Further, implementation forms are apparent from the dependent claims, the description, and the figures. The disclosure provides a sensor for use in an in-vehicle network, for communicating with at least one other unit in the in-vehicle network by means of packets through a switch, the in-vehicle network, and a method for the in-vehicle network.

According to a first aspect, there is provided a sensor for use in an in-vehicle network, for communicating with at least one other unit in the in-vehicle network by means of packets through a switch. The sensor is being arranged to create sensor-specific traffic information indicating at least one configuration parameter to be used for transmitting packets to or from the sensor, and communicate the sensor-specific traffic information to the switch. The traffic information is being based on the type of sensor and on context data indicative of a current traffic situation.

The sensor ensures that the packets are transmitted to the at least one other unit in the in- vehicle network without any errors. The sensor enables secure and reliable communication in the in-vehicle network. The sensor enables the configuration of the at least one configuration parameter in real-time. The sensor reduces complexity in configuring the in-vehicle network and improves the security to enable the configuration of the in-vehicle network. The sensor ensures that the transmitting packets are protected through an error correction scheme. As the sensor is a hardware, there is no security issue in the in-vehicle network as long as the sensor is secured. Further, the transmitting of the packets to or from the sensor is performed at any block in the in-vehicle network, which is secured and has computational power/bandwidth.

Optionally, the sensor is further arranged to obtain the context data and assess the context data and determine the at least one configuration parameter based on the assessment. Optionally, the sensor is further arranged to receive an assessment of the context data from another device and determine the at least one configuration parameter based on the assessment. The sensor may be arranged to generate the sensor-specific traffic information in the form of one or more Operational, Administration, and Management (OAM) packets.

The configuration parameter may include an interleaving depth, such as a forward error correction (FEC) interleaving depth. Optionally, the sensor is further arranged to communicate the context data to at least one other sensor in the in-vehicle network. According to a second aspect, there is provided an in-vehicle network. The in-vehicle network includes at least one sensor as described above, at least one switch, and a control unit. The at least one switch includes at least a first switch port and a second switch port, connected to the at least one sensor through the first switch port. The control unit is arranged to communicate with the at least one sensor through the at least one switch. The at least one switch is arranged to set device-specific parameters on at least one of the first switch port and second switch port in dependence of the at least one configuration parameter and to control the communication of data to or from the at least one sensor based on the at least one configuration parameter.

The in-vehicle network can be used efficiently for different traffic streams without compromising different traffic requirements in a network. The at least one sensor ensures that the packets are transmitted to the at least one other unit in the in-vehicle network without any errors. The at least one sensor enables the secure and reliable communication in the in-vehicle network. The at least one sensor enables the configuration of the at least one configuration parameter in real-time. The at least one sensor reduces complexity in configuring the in-vehicle network and improves the security to enable the configuration of the in-vehicle network. As the at least one sensor is a hardware, no security issue in the in-vehicle network as long as the at least one sensor is secured.

Optionally, the at least one switch is further arranged to forward information about the at least one configuration parameter to at least one other device in the in-vehicle network. The at least one other device may include another sensor, a control unit and/or another switch. The at least one sensor may include a camera, a powertrain module and/or a radar unit.

According to a third aspect, there is provided a method for an in-vehicle network. The in- vehicle network includes at least a first sensor as described above, at least one switch having at least two switch ports, and a control unit arranged to communicate with the at least first and second sensors through the at least one switch. The method includes generating, for the first sensor, sensor-specific traffic information indicating at least one configuration parameter to be used for packets to or from the first sensor. The traffic information is being based on the type of sensor and on context data indicative of a current traffic situation. The method includes communicating the sensor-specific traffic information to the switch. The method includes controlling communication to or from the first sensor in dependence of the configuration parameter.

Optionally, the context data is obtained and assessed by the first sensor and the at least one configuration parameter is determined by the sensor based on the assessment. Optionally, the context data is obtained and assessed by another device than the first sensor and communicated to the first sensor, and the at least one configuration parameter is determined by the sensor based on the assessment.

The sensor-specific traffic information may be generated in the form of one or more OAM packets. Optionally, the at least one configuration parameter is related to one or more of bit error rate, latency, bandwidth, priority, and duplex bandwidth. The configuration parameter may include an interleaving depth, such as a forward error correction interleaving depth.

A technical problem in the prior art is resolved, where the technical problem is that configuring an in-vehicle network without any traffic.

Therefore, in contradistinction to the prior art, according to a sensor for use in an in- vehicle network, for communicating with at least one other unit in the in-vehicle network by means of packets through a switch, the in-vehicle network and a method for the in- vehicle network, the packets are transmitted to the at least one other unit in the in-vehicle network without any errors, (i.e. the packets are protected through an error correction scheme). The sensor enables secure and reliable communication in the in-vehicle network. The sensor enables the configuration of the at least one configuration parameter in real-time. The sensor reduces complexity in configuring the in-vehicle network and improves the security to enable the in-vehicle network configuration.

These and other aspects of the disclosure will be apparent from and the implementation(s) described below.

BRIEF DESCRIPTION OF DRAWINGS

Implementations of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which: FIG. 1 is a block diagram of a sensor for use in an in-vehicle network, for communicating with at least one other unit in the in-vehicle network by means of packets through a switch in accordance with an implementation of the disclosure; FIG. 2 is a block diagram of an in-vehicle network in accordance with an implementation of the disclosure;

FIG. 3 illustrates an exemplary view of an in-vehicle network in accordance with an implementation of the disclosure;

FIG. 4 is a block diagram of a switch of an in-vehicle network in accordance with an implementation of the disclosure; and

FIG. 5 is a flow diagram that illustrates a method for an in-vehicle network in accordance with an implementation of the disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS Implementations of the disclosure provide a sensor for use in an in-vehicle network, for communicating with at least one other unit in the in-vehicle network by means of packets through a switch. The disclosure also provides an in-vehicle network and a method for the in-vehicle network.

To make solutions of the disclosure more comprehensible for a person skilled in the art, the following implementations of the disclosure are described with reference to the accompanying drawings.

Terms such as "a first", "a second", "a third", and "a fourth" (if any) in the summary, claims, and foregoing accompanying drawings of the disclosure are used to distinguish between similar objects and are not necessarily used to describe a specific sequence or order. It should be understood that the terms so used are interchangeable under appropriate circumstances, so that the implementations of the disclosure described herein are, for example, capable of being implemented in sequences other than the sequences illustrated or described herein. Furthermore, the terms "include" and "have" and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, a method, a system, a product, or a device that includes a series of steps or units, is not necessarily limited to expressly listed steps or units but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

FIG. 1 is a block diagram of a sensor 100 for use in an in-vehicle network 104, for communicating with at least one other unit in the in-vehicle network 104 by means of packets through a switch 102 in accordance with an implementation of the disclosure. The sensor 100 is being arranged to create sensor-specific traffic information indicating at least one configuration parameter to be used for transmitting packets to or from the sensor 100, and communicate the sensor-specific traffic information to the switch 102. The traffic information is being based on the type of sensor 100 and on context data indicative of a current traffic situation.

The sensor 100 ensures that the packets are transmitted to the at least one other unit in the in-vehicle network without any errors. The sensor 100 enables secure and reliable communication in the in-vehicle network 104. The sensor 100 enables the configuration of the at least one configuration parameter in real-time. The sensor 100 reduces complexity in configuring the in-vehicle network 104 and improves the security to enable the configuration of the in-vehicle network 104. The sensor 100 ensures that the transmitting packets are protected through an error correction scheme. As the sensor 100 is a hardware, there are no security issues in the in-vehicle network 104 as long as the sensor 100 is secured.

Optionally, the transmitting of the packets to or from the sensor 100 is performed at any block in the in-vehicle network 104, which is secured and has computational power/bandwidth. Optionally, the transmitting of the packets to or from the sensor 100 may be performed in a cloud. The sensor 100 to be used for transmitting the packets that can be easily detected by analyzing the network performance for different use cases and scenarios. The sensor 100 may include a camera, a powertrain module and/or a radar. Optionally, the sensor 100 has different settings for different directions, for example, the camera has largely one-way communication, and the powertrain may need two-way security.

Optionally, the sensor 100 is further arranged to obtain the context data and assess the context data and determine the at least one configuration parameter based on the assessment. Optionally, the sensor 100 has a computing power to assess the context data and the sensor 100 has intelligence and bandwidth to assess the context data. Optionally, the sensor 100 is further arranged to receive an assessment of the context data from another device and determine the at least one configuration parameter based on the assessment. Optionally, the data format of the assessment of the context data is a format of the sensor-specific traffic information. Optionally, the sensor 100 receives the context data from another device within a specified time. The context data may be a type of road, a city center or a highway, a traffic situation, a speed, a visibility, a weather condition, etc. For example, context data may include more accurate camera data needed for a higher frame-rate in a crowded area (i.e. in city centers) than on highways.

The configuration parameter may include an interleaving depth, such as a forward error correction (FEC) interleaving depth. Optionally, the at least one configuration parameter is related to one or more of bit error rate, latency, bandwidth, priority, and duplex bandwidth. The sensor 100 may be arranged to generate the sensor-specific traffic information in the form of one or more Operational, Administration, and Management (OAM) packets. Optionally, the sensor 100 further transmits the sensor-specific traffic information to the another device/sensor as per must or need-to-know basis. The sensor 100 may transmit the sensor-specific traffic information to a control unit, an electronic control unit (ECU), or any processing unit. Optionally, the sensor-specific traffic information transmitted among the sensors and the processing units/ECU may be in the form of one or more OAM packets. Optionally, IEEE 802.3 Physical layer (PHY) supports the exchange of the one or more OAM packets between PHYs. This technique may be used as part of the standard in IEEE 802.3cy. If bits are defined accordingly then it is a part of the standard in the IEEE 802.3cy.

Optionally, the sensor 100 is further arranged to communicate the context data to at least one other sensor in the in-vehicle network 104. The communication of the context data to at least one other sensor may be done at any block in the in-vehicle network 104, which is secured and has computational power/bandwidth.

Optionally, the one or more OAM packets are communicated to at least one other device. The at least one other device may include an another sensor, a control unit and/or an another switch connected to the in-vehicle network 104 through a link. Optionally, the one or more OAM packets are propagated until it reaches to the at least one other unit connected to the in-vehicle network 104. Each link in the in-vehicle network 104 may be configured accordingly based on the OAM packet information (i.e. the sensor-specific traffic information). Optionally, the configuration of each link is performed for each sensor-specific traffic information and each sensor 100 connected to the in-vehicle network 104.

FIG. 2 is a block diagram of an in-vehicle network 200 in accordance with an implementation of the disclosure. The in-vehicle network 200 includes at least one sensor 202, at least one switch 204, and a control unit 208. The at least one switch 204 includes at least a first switch port 206A and a second switch port 206B, connected to the at least one sensor 202 through the first switch port 206A. The control unit 208 is arranged to communicate with the at least one sensor 202 through the at least one switch 204. The at least one switch 204 is arranged to set device-specific parameters on at least one of the first switch port 206A and the second switch port 206B in dependence of the at least one configuration parameter and to control the communication of data to or from the at least one sensor 202 based on the at least one configuration parameter.

The in-vehicle network 200 can be used efficiently for different traffic streams without compromising different traffic requirements in a network. The at least one sensor 202 ensures that the packets are transmitted to the at least one other unit in the in-vehicle network 200 without any errors. The at least one sensor 202 enables the secure and reliable communication in the in-vehicle network 200. The at least one sensor 202 enables the configuration of the at least one configuration parameter in real-time. The at least one sensor 202 reduces complexity in configuring the in-vehicle network 200 and improves the security to enable the configuration of the in-vehicle network 200. As the at least one sensor 202 is a hardware, no security issue in the in-vehicle network 200 as long as the at least one sensor 202 is secured.

Optionally, the at least one switch 204 is further arranged to forward information about the at least one configuration parameter to at least one other device in the in-vehicle network 200. The at least one other device may include another sensor, a control unit and/or another switch. The at least one sensor 202 may include a camera, a powertrain module and/or a radar unit.

FIG. 3 illustrates an exemplary view of an in-vehicle network 300 in accordance with an implementation of the disclosure. The in-vehicle network 300 includes at least one sensor, at least one switch, and a control unit 308. The at least one switch includes at least a first switch port (PI) and a second switch port (P2), connected to the at least one sensor through the first switch port. The control unit 308 is arranged to communicate with the at least one sensor through the at least one switch. The at least one switch is arranged to set device-specific parameters on at least one of the first switch port and the second switch port in dependence of the at least one configuration parameter and to control the communication of data to or from the at least one sensor based on the at least one configuration parameter. The at least one sensor may be a camera 302A, a powertrain module 302B and/or a radar 302C. Optionally, the least one switch may be a first switch 304A (SW1), and a second switch 304B (SW2).

Optionally, the sensor-specific traffic information originated from the camera 302A (i.e. a sensor) may have different network setting compared to the sensor-specific traffic information received from the powertrain module 302B, while passing through a Link A and a Link B. Optionally, the sensor has different settings for different directions, for example, the camera 302A has largely one-way communication, and the powertrain module 302B may need two-way security. Optionally, in the sensor, the first switch 304A (SW1), the second switch 304B (SW2) or other devices (e.g. an electronic control unit, a switch, actuators 310, etc.) of the in-vehicle network 300 each has a physical layer (PHY). The PHY is an electronic circuit, usually implemented as an integrated circuit, required to implement physical layer functions of the Open Systems Interconnection (OSI) model in a network interface controller. The PHY connects a link device (e.g. a sensor, a device, or a control unit) to a physical medium such as an optical fiber or a copper cable.

Optionally, the PHYs in the link A include a physical layer in a port P3 of the first switch 304A and a physical layer in a port PI of the second switch 304B. The port P3 of the first switch 304A (i.e. SW1.P3) and the port PI of the second switch 304B (i.e. SW2.P1) may provide no error correction for the OAM packet received from the camera 302A and full error protection for the OAM packet received from the powertrain module 302B. Optionally, the first switch 304A (SW1), and the second switch 304B (SW2) enable a minimum error protection for the OAM packet of the camera 302A and full error protection for the OAM packet of the powertrain module 302B by selecting at least one configuration parameter (e.g. selecting different interleaving depth of forward error correction, FEC) based on the type of sensor and on context data indicative of a current traffic situation of the sensor. Optionally, the sensor has the sensor-specific traffic information or the sensor receives the sensor-specific traffic information from an another device. Optionally, the sensor is the camera 302A. The camera 302A may initiate its OAM packet and fills in the at least one configuration parameter on the right address. Optionally, the OAM packet is present in the PHY 306 of the camera 302A. Bits on the OAM packet of the camera 302A may be written or read through a Management Data Input/Output (MDIO) interface. The OAM packet of the camera 302A may be sent to a port PI of the first switch 304A (i.e. SW1.PI). Optionally, the first switch (SW1) 304A knows a source address and a destination address. The first switch (SW1) 304A may forward the OAM packet of the camera 302A to the port P3 of the first switch 304A (i.e. SW1.P3) and a port PI of the second switch 304B (i.e. SW2.P1) based on a local table in the SW1 304A. Optionally, the switches (SW1 and SW2) 304A-B are arranged to set FEC interleaving depth values at SW1.P3 and SW2.P1 only for the camera 302A based on the OAM packet. Optionally, the switches (SW 1 and SW2) 304A-B do not change the FEC interleaving depth setting for the sensor-specific traffic information from the powertrain module 302B. When the first swich, SW1, 304A, and the second switch, SW2, 304B recognize that there is a traffic information from the camera 302A, and the media access control (MAC) address fields in the SW1 304A and the SW2 304A are parsed. A media access control (MAC) address is a unique identifier assigned to a network interface controller for use as a network address in communications within a network. Optionally, the first switch, SW1 304A provides an alert to SW1.P3 that a new OAM packet (e.g. an Ethernet packet) from the camera 302A is received. The SW1.P3 may recognize the new OAM packet from the camera 302A. When the SW1.P3 may recognize a start of a new frame, the FEC interleaving depth may be used for camera 302A as it is set in a register. The register may include an OAM information forwarding table and an OAM packet forwarding table.

Optionally, synchronization indicates the start of decoding of the OAM packet using the FEC interleaving depth. The synchronization may be performed in many ways in the SW2.P1. Optionally, before sending a stream (i.e. a packet) of the camera 302A, the OAM packet of the camera 302A is sent to the SW2.P1 and informs the SW2.P1 that a next incoming packet is from the camera 302A. Optionally, when the SW2.P1 receives and recognizes the packet from the camera 302 A, the SW2.P1 may decode the received packet accordingly with a value of the FEC interleaving depth. Optionally, the OAM packet of the camera 302A may be encoded in the camera stream by the SW 1 P3. Optionally, the SW2.P1 detects the camera stream and decodes the camera stream with the FEC interleaving depth.

FIG. 4 is a block diagram of a switch 400 of an in-vehicle network in accordance with an implementation of the disclosure. Optionally, the switch 400 is further arranged to forward information about at least one configuration parameter to at least one other device in the in-vehicle network. The switch 400 includes an OAM information forwarding table 402 and an OAM packet forwarding table 404 to control the communication of data to or from at least one sensor based on the at least one configuration parameter. The OAM information forwarding table 402 includes the information about one or more OAM packets of the at least one sensor. The OAM packet forwarding table 404 includes the forwarding/transmitting information of the one or more OAM packets of the at least one sensor. Based on the OAM information forwarding table 402 and the packet forwarding table 404, the switch 400 read/writes the OAM information to/from a PHY 406 of the switch 400.

FIG. 5 is a flow diagram that illustrates a method for an in-vehicle network in accordance with an implementation of the disclosure. The in-vehicle network includes (i) at least a first sensor, (ii) at least one switch having at least two switch ports, and (iii) a control unit arranged to communicate with the at least first and second sensors through the at least one switch. At a step 502, sensor-specific traffic information for the first sensor is generated. The sensor-specific traffic information indicates at least one configuration parameter to be used for packets to or from the first sensor. The traffic information is being based on the type of sensor and on context data indicative of a current traffic situation. At a step 504, the sensor-specific traffic information is communicated to the switch. At a step 506, communication to or from the first sensor is controlled in dependence of the at least one configuration parameter.

The method ensures that the packets are transmitted to the at least one other unit in the in-vehicle network without any errors. The method enables secure and reliable communication in the in-vehicle network. The method enables the configuration of the at least one configuration parameter in real-time. The method reduces complexity in configuring the in-vehicle network and improves the security to enable the configuration of the in-vehicle network. The method ensures that the transmitting packets are protected through an error correction scheme. Optionally, the context data is obtained and assessed by the first sensor, and the at least one configuration parameter is determined by the sensor based on the assessment. Optionally, the context data is obtained and assessed by another device than the first sensor and communicated to the first sensor, and the at least one configuration parameter is determined by the sensor based on the assessment.

It should be understood that the arrangement of components illustrated in the figures described are exemplary and that other arrangement may be possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and means) may be realized, in whole or in part, by at least some of the components illustrated in the arrangements illustrated in the described figures.

In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.

Although the disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.

Claims

1. A sensor (100, 202) for use in an in-vehicle network (104, 200, 300), for communicating with at least one other unit in the in-vehicle network (104, 200, 300) by means of packets through a switch (102, 204, 400), said sensor (100, 202) being arranged to create sensor-specific traffic information indicating at least one configuration parameter to be used for transmitting packets to or from the sensor (100, 202), and communicate the sensor-specific traffic information to the switch (102, 204, 400), the traffic information being based on the type of sensor (100, 202) and on context data indicative of a current traffic situation.

2. The sensor (100, 202) according to claim 1, further arranged to obtain the context data and assess the context data and determine the at least one configuration parameter based on the assessment.

3. The sensor (100, 202) according to claim 1, further arranged to receive an assessment of the context data from another device and determine the at least one configuration parameter based on the assessment.

4. The sensor (100, 202) according to any one of the preceding claims, arranged to generate the sensor-specific traffic information in the form of one or more Operational, Administration, and Management (OAM) packets.

5. The sensor (100, 202) according to any one of the preceding claims, wherein the configuration parameter includes an interleaving depth, such as a forward error correction (FEC) interleaving depth.

6. The sensor (100, 202) according to any one of the preceding claims, further arranged to communicate the context data to at least one other sensor in the in-vehicle network.

7. An in-vehicle network (104, 200, 300) comprising at least one sensor (100, 202) according to any one of the preceding claims, at least one switch (102, 204, 400) having at least a first switch port (206 A) and a second switch port (206B), connected to the at least one sensor (100,

202) through the first switch port (206A), a control unit (208, 308) arranged to communicate with the at least one sensor (100, 202) through the at least one switch (102, 204, 400), wherein the at least one switch (102, 204, 400) is arranged to set device-specific parameters on at least one of the first switch port (206A) and second switch port (206B) in dependence of the at least one configuration parameter and to control the communication of data to or from the at least one sensor (100, 202) based on the at least one configuration parameter.

8. The in-vehicle network (104, 200, 300) according to claim 7, wherein the at least one switch (102, 204, 400) is further arranged to forward information about the at least one configuration parameter to at least one other device in the in-vehicle network (104, 200, 300).

9. The in-vehicle network (104, 200, 300) according to claim 7 or 8, wherein the at least one other device includes another sensor, a control unit and/or another switch.

10. The in-vehicle network (104, 200, 300) according to any one of the claims 7 - 9, wherein the at least one sensor (100, 202) includes a camera, a powertrain module and/or a radar unit.

11. A method for an in-vehicle network (104, 200, 300) comprising at least a first sensor (100, 202) according to any one of the preceding claims, at least one switch (102, 204, 400) having at least two switch ports (206 A-B), a control unit (208, 308) arranged to communicate with the at least first and second sensors through the at least one switch (102, 204, 400), the method comprising generating, for the first sensor (100, 202), sensor-specific traffic information indicating at least one configuration parameter to be used for packets to or from the first sensor (100, 202), the traffic information being based on the type of sensor (100, 202) and on context data indicative of a current traffic situation, - communicating the sensor-specific traffic information to the switch (102, 204,

400), and controlling communication to or from the first sensor (100, 202) in dependence of the at least one configuration parameter.

12. The method according to claim 11, wherein the context data is obtained and assessed by the first sensor (100, 202) and the at least one configuration parameter is determined by the sensor (100, 202) based on the assessment.

13. The method according to any one of the claims 11 - 12, wherein the context data is obtained and assessed by another device than the first sensor (100, 202) and communicated to the first sensor (100, 202), and the at least one configuration parameter is determined by the sensor (100, 202) based on the assessment.

14. The method according to any one of the claims 11 - 13, wherein the sensor- specific traffic information is generated in the form of one or more OAM packets.

15. The method according to any one of the claims 11 - 14, wherein the at least one configuration parameter is related to one or more of bit error rate, latency, bandwidth, priority, and duplex bandwidth.

16. The method according to any one of the claims 11 - 15, wherein the configuration parameter includes an interleaving depth, such as a forward error correction interleaving depth.