Patent Description:
<CIT> discloses an automatic wireless connection system and method that securely share wireless network settings and connection credentials via a wired medium without user intervention.

A vehicle can refer to any type of transport structure to carry cargo and/or people between different physical locations. Examples of vehicles include any or some combination of the following: a car, a truck, a watercraft (e.g., a boat, a yacht, a ship, etc.), an aircraft, a spacecraft, a railed vehicle (e.g., a train), a cargo transportation unit (e.g., a container, a trailer, a platform, etc.), and so forth.

Examples of electronic control units (ECUs) that can be included in a vehicle include any or some combination of the following: an engine control module (ECM) for controlling the vehicle's engine, a powertrain control module (PCM) to control the vehicle's powertrain, a transmission control module (TCM) to control the vehicle's transmission, a brake control module (BCM or EBCM) to control the vehicle's brake subsystem, a central control module (CCM) to control specified functionalities of the vehicle, a central timing module (CTM) to control timings of subsystems in the vehicle, a general electronic module (GEM) to control the vehicle's electrical subsystem, a body control module (BCM) to control the vehicle's stabilization subsystem, a suspension control module (SCM) to control the vehicle's suspension subsystem, a door control unit to control the vehicle's doors, a power steering control unit to control the vehicle's power steering subsystem, a seat control unit to control the vehicle's power seats, a speed control unit to control the vehicle's speed, a battery management system to manage batteries in the vehicle, a human-machine interface (HMI) to provide an interface through which a human can interact with the vehicle, and so forth.

In some examples, field buses are used to interconnect the ECUs. Examples of field buses include a Local Interconnect Network (LIN) bus, a Controller Area Network (CAN) bus, a FlexRay bus, a Time-Triggered Protocol (TTP) bus, a ZigBee bus, or others.

A network in a vehicle has to have certain characteristics for reliable performance of the vehicle, including low latency (or bounded latency) and high reliability of data delivery in a timely manner. Certain ECUs of a vehicle are safety related, such as ECUs that control the brake subsystem, engine, power steering, transmission, and other critical subsystems of the vehicle. If data is not timely communicated over the vehicle's network to ECUs that control safety-related subsystems, then loss of control of the vehicle may occur leading to accidents.

In addition to low latency and high reliability, the network of a vehicle should also provide security (to reduce the likelihood of a hacker attacking the subsystems of the vehicle), redundancy to protect against failures of a portion of the network, a reduced communication range to prevent being compromised by a hacker, and other features (discussed further below).

<FIG> is a block diagram of a vehicle <NUM> that includes a vehicle wireless local area network (WLAN) <NUM> to which various ECUs <NUM>, <NUM>, and <NUM> are wirelessly coupled. Although three ECUs are depicted in <FIG>, it is noted that the vehicle <NUM> can include less than or more than three ECUs in other examples.

The vehicle WLAN <NUM> can be a WI-FI WLAN (or more simply, a "WI-FI network") that includes wireless access points (APs) <NUM> to which the ECUs <NUM>, <NUM>, and <NUM> are able to wirelessly connect. An AP refers to a networking device with which a wireless device can associate to perform data communications over a wireless link between the wireless device and the AP. Communications in a WI-FI network can be according to the Institute of Electrical and Electronic Engineers (IEEE) <NUM> standards.

In some examples, the WI-FI network can be a high frequency, high throughput network, such as according to the IEEE <NUM>. 11ay (Next Generation <NUM>) standard, the IEEE <NUM>. 11ad standard (Microwave WI-FI/WiGig), the IEEE <NUM>. 11aj (Very High Throughput to Support Chinese Millimeter Wave Frequency Bands (<NUM> and <NUM>)) standard, and so forth. As used here, a "high frequency" WI-FI network is able to operate using a carrier at a frequency that is greater than or equal to <NUM> Gigahertz (GHz), in some examples. A "high throughput" WI-FI network is able to transmit data at greater than a specified data rate, for example <NUM> megabits per second (Mbps).

Alternatively, a WI-FI network can also operate using light signals to communicate data wirelessly as a high frequency, high throughput network. The IEEE <NUM>. 11bb (Light Communication) group of IEEE <NUM> is developing a proposal for light communications in WI-FI networks.

The use of the IEEE <NUM>. 11ay, <NUM>. 11aj, and <NUM>. 11bb technologies can provide wireless connections with low levels of interference (and therefore congestion). In the case of light communications, the light can be fairly directional, and interference can be mitigated by any opaque object, i.e., light does not usually pass through walls to interfere with another network. In the case of IEEE <NUM>. 11ay and IEEE <NUM>. 11aj (<NUM>), signals are sent at low power and with directional antennas. As a result of directional transmissions and propagation characteristics of the <NUM> carrier frequency, interference from nearby networks can be reduced.

The high throughput capabilities, together with other new features, of the foregoing technologies for implementing the WI-FI network <NUM> enable low latency and deterministic behavior to be provided for vehicle applications. This is a departure from traditional <NUM> WLAN, where latency and non-deterministic behavior have prevented <NUM> WLAN from being used for time sensitive applications.

In some examples, the APs <NUM> of the WI-FI network <NUM> are connected to network nodes <NUM> of the vehicle LAN <NUM>. The network nodes <NUM> can include switches, routers, bridges, gateways, and so forth. The network nodes <NUM> are used to transport data between APs <NUM>, and also between an AP and another destination, which can be off the vehicle <NUM>. In other examples, the network nodes <NUM> can be omitted, and the APs <NUM> can be connected to one another.

Each ECU <NUM>, <NUM>, or <NUM> includes or is connected to a corresponding network controller. For example, the ECU <NUM> is associated with a network controller <NUM>, the ECU <NUM> is associated with a network controller <NUM>, and the ECU <NUM> is associated with a network controller <NUM>. A "network controller" can refer to a device (e.g., an integrated circuit chip, an electronic device, etc.) that can be used for performing communications over the WI-FI network <NUM>. The network controller can be implemented using a hardware processing circuit, which can include any or some combination of the following: a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit device, a programmable gate array, or any other hardware processing circuit. Alternatively, the network controller can be implemented as a combination of a hardware processing circuit and machine-readable instructions (software and/or firmware) executable on the hardware processing circuit.

In the ensuing discussion, it is assumed that the network controller <NUM> is included in the ECU <NUM>, the network controller <NUM> is included in the ECU <NUM>, and the network controller <NUM> is included in the ECU <NUM>. In alternative examples, the network controller <NUM>, <NUM>, and/or <NUM> can be separate from, but connected to, the corresponding ECU <NUM>, <NUM>, and/or <NUM>.

The example ECU <NUM> is used to control a brake subsystem <NUM> of the vehicle <NUM>. The example ECU <NUM> is used to control a camera <NUM> of the vehicle <NUM>. The example ECU <NUM> is used to control another subsystem (not shown).

Use of the WI-FI network <NUM> (even over short distances in the vehicle <NUM>) can provide cost savings in vehicle manufacturing, installation, and maintenance, for example due to the elimination of a conventional wiring loom and the labor costs associated with its installation. For example, by using the WI-FI network <NUM>, cables that interconnect (some) ECUs can be omitted.

For longer communication paths in a vehicle, the path can be designed using prisms, lenses, mirrors, and various forms of reflectors. Light beams used for data communications can be narrow or wide, depending on the optical transducers used and the specified levels of physical isolation. Correspondingly millimetric beams used for data communications can also be narrow or wide depending on the transducers and isolation of the system.

In some examples, each ECU can act as an IEEE <NUM> station (e.g., each ECU has an IEEE <NUM> communications chip, in the form of a respective network controller within it) and connects to an IEEE <NUM> AP, which in turn is connected to the network through a bridge or switch.

It is noted that the wireless connections form an automobile WLAN and are not operating as individual point-to-point links in a star and hub configuration. Therefore, traffic from the camera <NUM> can flow directly to another ECU (e.g., <NUM>), through the WI-FI network <NUM>.

In some examples, an automobile regulatory requirement may specify that a rear-view camera has to turn on and be streaming video to a display screen within <NUM> seconds (or other time duration) of power on. This can be achieved using either of the following techniques, in some examples.

In addition, other devices can also be connected to the ECU <NUM>, so that a link can include several combined data feeds from one area of the vehicle <NUM> to another area of the vehicle <NUM>.

A link can be established between network controllers through the WI-FI network <NUM>. A "link" refers to a logical connection through the WI-FI network <NUM> between network controllers. In accordance with some implementations of the present disclosure, the link between network controllers is a synchronized link. A synchronized link is a link that couples multiple devices having clocks (discussed further below) that are synchronized with respect to one another. Note that a first network controller can maintain a synchronized link with multiple other network controllers.

As further shown in <FIG>, the network controller <NUM> includes a wireless transceiver <NUM>, the network controller <NUM> includes a transceiver <NUM>, and the network controller <NUM> includes a transceiver <NUM>. A transceiver includes a transmitter and a receiver to transmit and receive, respectively, signals. In examples according to <FIG>, the transceivers <NUM>, <NUM>, and <NUM> are wireless transceivers that are able to communicate wireless signals.

In addition, the network controllers <NUM>, <NUM>, and <NUM> include respective clocks <NUM>, <NUM>, and <NUM>. A "clock" refers to a device that produces an oscillating signal that controls the timing of circuitry. Network controllers are synchronized to one another if their respective clocks are synchronized, i.e., transition edges of the clocks are aligned in time (to within some specified tolerance) with respect to one another.

In some examples, the WI-FI network <NUM> can include a master clock <NUM>. The other clocks (e.g., <NUM>, <NUM>, and <NUM>) in the vehicle <NUM> can be synchronized to the master clock <NUM>. The master clock <NUM> can be included in a network node, such as in a switch or other type of network node. Alternatively, the master clock <NUM> can be included in an ECU that is designated a central ECU (e.g., the ECU <NUM>) or an ECU that is designated as a master clock ECU.

The master clock <NUM> can be internally generated in the vehicle <NUM>, such as based on an oscillator in the vehicle <NUM>. Alternatively, the master clock <NUM> can be generated based on information from an external source, such as from GNSS (Global Navigation Satellite System) satellites, an atomic clock, and so forth.

In some examples, synchronization of the timings of the clocks in the vehicle <NUM> can be according to the IEEE <NUM>. 1AS standard (also referred to as "Generalized Precision Time Protocol").

In other examples, synchronization of the timings of the clocks in the vehicle <NUM> can employ different techniques.

Synchronizing the clocks of the network controllers allows for operations of the ECUs to be time-aligned with one another, such as to provide consistent transmission delays among the ECUs.

In accordance with some implementations of the present disclosure, a real-time access class (or multiple real-time access classes) can be defined for communicating data over the WI-FI network <NUM> of the vehicle <NUM>.

IEEE <NUM> allows for the definition of access classes to distinguish different types of traffic to be communicated over a WI-FI network. An access class can also define medium access rules for transmission. A real-time access class (referred to as AC_RT) according to some implementations of the present disclosure can be associated with time-sensitive data to be communicated over the WI-FI network <NUM>. The real-time access class is associated with a real-time WLAN bearer used to carry traffic of the real-time access class.

It is noted that traffic can dynamically switch among different access classes, which can be set during the provisioning of the WI-FI network <NUM>.

<FIG> shows an example network controller <NUM>, which can be any of the network controllers <NUM>, <NUM>, and <NUM> of <FIG>. The network controller <NUM> includes a clock <NUM> and a transceiver <NUM>, similar to those discussed in connection with <FIG>.

In addition, the network controller <NUM> can include an AC_RT queue <NUM> to buffer data according to the real-time access class. Different queues (not shown) can be provided for other access classes in the network controller <NUM>. The buffered data in the AC_RT queue <NUM> can be communicated over a synchronized link <NUM> through the WI-FI network <NUM> between network controllers.

In some examples, the synchronized link <NUM> over which data of the AC_RT queue <NUM> is communicated, may be independent of or separate from other logical links used to carry data of other access classes. This is to prevent synchronous traffic (according to the real-time access class) from being mixed with asynchronous traffic (e.g., according to the legacy access classes, AC_VI, AC_VO, etc.) on the same logical link.

In other examples, if the bandwidth and timing capabilities of the WI-FI network <NUM> that uses high frequency, high throughput technologies are sufficient, then the AC_RT traffic and legacy AC traffic may share the same link, but the WI-FI network <NUM> that uses high frequency, high throughput technologies would have to be carefully managed to ensure that the AC_RT traffic maintains its target operational envelope (e.g., if interference becomes an issue, non-AC_RT traffic may have to be discarded or buffered).

In further examples with multiple real-time access classes, the network controller <NUM> can include multiple respective AC_RT queues <NUM>.

In examples where multiple real-time access classes are defined, IEEE <NUM> Qbv provides a time-aware scheduler <NUM> so that traffic of different real-time access classes may be carried over one logical link. For example, different real-time access classes (e.g., AC_RT0, AC_RT1) may be mapped to respective different priorities, such as the priorities of the IEEE <NUM> Time Sensitive Networking (TSN) technology. The different priorities allows the scheduler <NUM> to select buffered data from multiple AC_RT queues <NUM> for transmission over the synchronized link.

More generally, the network controller <NUM> can be configured with media access parameters to allow the network controller <NUM> to transmit data according to a real-time access class over the synchronized link <NUM>.

The network controller <NUM> further includes a segmentation logic <NUM> and a reassembly logic <NUM>. The segmentation logic <NUM> divides data in the AC_RT queue <NUM> into packets (also referred to as protocol data units or PDUs) of a specified size (segmentation size). The divided data can be transmitted by the network controller <NUM> in respective packets having the segmentation size. Data in received packets (as received by the network controller <NUM>) can be reassembled by the reassembly logic <NUM>.

If lower latency is desired, the segmentation size can be reduced. On the other hand, if higher latency can be tolerated, then the segmentation size can be increased.

In some examples, segmentation and reassembly performed by the segmentation logic <NUM> and the reassembly logic <NUM> can be according to IEEE <NUM>. 11ay, <NUM>. 11aj or <NUM>. In other examples, other segmentation and reassembly techniques can be employed.

In some examples, an IEEE <NUM> security scheme (e.g., WI-FI Protected Access II or WPA2 or any IEEE <NUM> protocol configured to use Robust Security Network (RSN)) can be implemented using a security logic <NUM> in the network controller <NUM>, where the security scheme can provide a higher level of security over a link than that of many wired technologies.

Each ECU (or other device) that connects to the WI-FI network <NUM> employs a security protocol and credentials (e.g., a password, a key, etc.) to connect to that WI-FI network <NUM>. The security protocol can either be standards based or proprietary.

It is possible that a single WI-FI network <NUM> utilizes several security protocols at the same time, again with the assumption that an authentication server can also support the multiple security protocols.

A device (any of network nodes <NUM>, for example) on the WI-FI network <NUM> can act as an authentication server (possibly co-located with one of the primary ECUs), so that ECUs and devices connecting to and disconnecting from the WI-FI network <NUM> can be managed. The authentication server can also authenticate the network controllers in the ECUs. In further examples, mechanisms such WI-FI Alliance Device Provisioning Protocol (DPP) Network Introduction, or a Fast Initial Link Setup (FILS) Public Key (defined in IEEE <NUM>. 11ai) can be used to allow ECUs to authenticate over a WLAN. Devices can be provisioned with a public key/private key pair signed by a Certificate Authority (CA) trusted by the vehicle to perform authentication. In further examples, devices can also be provisioned with a passphrase that can allow them to authenticate.

A new ECU (or other device, such as a network controller) placed in the vehicle <NUM> can be provisioned by a provisioning server (e.g., any of network nodes <NUM>) with requirements or parameters to operate over the WI-FI network <NUM>. Provisioning can be achieved in many ways, using protocols such as DPP. This can be achieved at the time of assembly of the device or ECU, or when a device or ECU is added to the vehicle <NUM>. Alternatively, a device or ECU can be provisioned remotely, such as over a cellular or other wireless link.

Each ECU (or other device) that joins the vehicle's WI-FI network <NUM> can be associated with a profile that is provisioned and configured for the WI-FI network <NUM>. In some examples, a profile can include information relating to transmission power, network bandwidth use, support for a Medium Access Control (MAC) protocol, and so forth. The profile can also include information relating to an operation of the ECU or other device. For example, for a camera, the profile can specify an image resolution.

An out-of-band technique (such as DPP) can be used to provision the profile with the ECU (or other device). After the ECU (or other device) is provisioned with the profile, the ECU (or other device) after starting (e.g., powering up, resetting, etc.) is correctly configured to connect to the WI-FI network <NUM>. Once an ECU (or device) is provisioned, it can set up a secure connection to the WI-FI network <NUM>.

There are also other ways of provisioning ECUs (or other devices), for example, using a manual technique or connecting an ECU (or other device) to an external network (e.g., in a garage or manufacturing plant).

Power savings can be implemented in the ECUs (or other devices) on the WI-FI network <NUM>. Since a wireless technology is used, the ECUs (or other devices) can be battery powered (or powered by other alternative power sources). IEEE <NUM> power saving schemes can be used in some examples.

In other examples, the vehicle <NUM> itself can provide environmental inputs. For example, when the vehicle <NUM> is stationary, signals from on-board sensor(s) <NUM> can indicate to ECUs (or other devices, such as network controllers) that they can remain in a low power state until the vehicle <NUM> starts to move again. Such power save information can be transmitted through a power network/bus, using a scheme such as the wake-up radio defined by IEEE <NUM>. 11ba or by another method.

A network controller within a first ECU can be powered off when the vehicle <NUM> is powered off, and a network controller within a second ECU can be powered on when the vehicle <NUM> is powered off.

When an ECU (or device) is either added or removed from the vehicle's WI-FI network <NUM>, a discovery process may be performed. The discovery process can be performed in response to any of the following: <NUM>) when all the ECUs are powered up (e.g., the vehicle <NUM> is powered up), <NUM>) once the vehicle <NUM> is already powered up (and possibly moving), or <NUM>) a system reset (or re-configuration).

The discovery process can operate according to high frequency, high throughput technology used by the WI-FI network <NUM>, such as by using IEEE <NUM>. 11bb, in which light communication devices can find and discover other devices within their vicinity. Alternatively, the discovery process can be performed at a higher layer (e.g. using the IEEE <NUM> MAC layer to find/discovery devices that are physically connected to the WLAN, but require synchronization and packet level discovery).

A device in a vehicle can search for a service by a network identifier (e.g., SSID), or the device can search via a Service identifier or hash as specified in IEEE <NUM>.

When a device is installed in a vehicle, there are several possible techniques for discovery and provisioning. First, at the time the device is installed in the vehicle, the device is provisioned with network information and credentials for the vehicle. Second, the vehicle is updated out of band with the device identity and credentials, which allow the device to connect to the vehicle when the device is installed. The device has its credentials installed at the factory. Third, the vehicle is provisioned with credentials using a root CA at manufacturing. The vehicle is provisioned with the root CA information. The vehicle validates the device credentials when the device tries to connect the first time. There may be some user interaction with the vehicle to confirm that the device is being added.

Vehicle manufacturers can decide whether the associations (i.e., WLAN sessions) are maintained between powering the vehicle <NUM> up and down. WLAN sessions (e.g., that include security keys and network addresses such as Internet Protocol (IP) or MAC addresses) can be maintained by regularly updating a cache in an ECU (or several ECUs), so that when the vehicle <NUM> is powered down, a saved state of the vehicle's configuration is stored for future use. At the time of power up, the saved state enables all wireless ECUs (or more specifically the network controllers in the ECUs) to quickly re-establish their WLAN sessions and possibly perform a quick integrity check (e.g., by sending ping or keep-alive packets over each link) before any data is transmitted.

The security association of each ECU (or other device) can be considered in two contexts. The first begins when the ECU (or other device) is added at the assembly plant, or added by a mechanic, and ends when the part is removed from the vehicle. The second is a session that exists when the ignition key is turned on and ends when the car is turned off.

Note though that some of the components may continue to run even when the vehicle <NUM> is off, and thus a certain portion of the WI-FI network <NUM> may have to remain powered continually. The continually powered components can include a central computing device that stores ECU/device profiles and credentials for the system. For example, an electric vehicle has a remote prestart function for the climate control feature, and some antitheft systems specify that various electronics/communications links to stay running continually.

All or most of the ECUs (or other devices) can be powered down. Similarly, a portion of the vehicle's WI-FI network <NUM> can be powered down (e.g., the APs, bridges, and switches).

The WI-FI network <NUM> may also support a cellular backhaul communications link for remote locking/unlocking of the vehicle <NUM>, for supporting a find-my-car feature, for remotely starting or shutting off the vehicle <NUM>, and so forth.

In addition to the WI-FI network <NUM>, the vehicle <NUM> can also include legacy field buses. <FIG> shows an example that includes field buses <NUM> and <NUM> connected to respective legacy devices <NUM> and <NUM>. Data on a field bus <NUM> or <NUM> can be transported by the WI-FI network <NUM> that includes an AP <NUM> as shown in <FIG>.

Alternatively, the AP <NUM> can be omitted, so that a direct link can be established between network controllers <NUM> and <NUM> through the WI-FI network <NUM>.

A data frame structure used on a field bus <NUM> or <NUM> can be carried in IEEE <NUM> data frames over the WI-FI network <NUM>.

In some examples, a gateway <NUM> or <NUM> can be used to encapsulate data, according to a field bus data format, into a frame according to an IEEE <NUM> data format. Each gateway <NUM> or <NUM> can include or be coupled to an IEEE <NUM> network controller <NUM> or <NUM>, respectively, to communicate over the WI-FI network <NUM>. In some examples, each gateway <NUM> or <NUM> can include or be coupled to a switch that connects into the respective field bus <NUM> or <NUM> using a suitable field bus connector.

Timing information (e.g. clock signals) may be copied from the field bus packets to serve as metadata or to assist with clock synchronization in the IEEE <NUM> backbone network.

The field bus packets are encapsulated into IEEE <NUM> frames by the gateway <NUM> or <NUM>, using copies of the field bus addressing as metadata in the IEEE <NUM> backbone network. The IEEE <NUM> frames are then sent to their destinations, which can involve going through another gateway back to a field bus. In other examples, the IEEE <NUM> frames can be sent to a destination on the WI-FI network <NUM>, so that the frames do not have to traverse through another gateway.

Each gateway <NUM> or <NUM> also allows a mix of legacy field bus devices and fieldbus-over-<NUM> devices to be connected to the WI-FI network <NUM>. The WI-FI network <NUM> is completely transparent to the legacy field bus devices.

Instead of using a gateway <NUM> or <NUM>, a dongle <NUM> or <NUM> can be used instead to communicate data of the legacy field bus device <NUM> or <NUM> over the WI-FI network <NUM>. A dongle allows an IEEE <NUM> station (the network controller <NUM> or <NUM>) to be directly connected to a single legacy field bus device and can connect into the existing field bus connector on that device. As a result, the legacy field bus device does not have to be connected to the field bus.

The dongle <NUM> or <NUM> performs conversion between field bus frames and IEEE <NUM> frames in similar manner as a gateway <NUM> or <NUM>.

The dongle <NUM> or <NUM> can be separate from a respective field bus device, or alternatively, can be embedded into the field bus device. The embedded dongle can communicate over the WI-FI network <NUM>, but not over a field bus.

A benefit of using an embedded dongle is that the field bus device <NUM> or <NUM> would no longer have to be provided with a physical field bus interface, thereby simplifying the field bus device <NUM> or <NUM>.

Alternatively, a field bus device (<NUM> or <NUM>) can include a field bus interface as well as an embedded dongle.

As noted above, a field bus device <NUM> or <NUM> connected to a respective field bus <NUM> or <NUM> does not know that its data is traversing anything other than the field bus. The IEEE <NUM> bridge (gateway or dongle) is transparent to the endpoints, including the field bus devices <NUM> and <NUM>.

A field bus <NUM> or <NUM> can be an actual bus with multiple field bus devices, or implemented as a dongle (separate or embedded) for a single field bus device.

Assuming that the bandwidth and timing requirements of the WI-FI network <NUM> are sufficient to support field bus traffic, it is also possible that the same WI-FI network <NUM> can carry normal IEEE <NUM> traffic at the same time, subject to the legacy field bus traffic using different access classes.

<FIG> shows various components, including the scheduler <NUM>, segmentation logic <NUM>, reassembly logic <NUM>, and security logic <NUM>. These components can be implemented as hardware processing circuits, or as machine-readable instructions executable on a processor to perform tasks. A processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit. Machine-readable instructions executable on a processor can refer to the instructions executable on a single processor or the instructions executable on multiple processors.

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

Claim 1:
A system comprising:
a plurality of network controllers (<NUM>, <NUM>, <NUM>) comprising a first network controller (<NUM>, <NUM>, <NUM>) and a second network controller (<NUM>, <NUM>, <NUM>), wherein the first network controller (<NUM>, <NUM>, <NUM>) comprises a first clock (<NUM>, <NUM>, <NUM>) to produce a first oscillating signal, and the second network controller (<NUM>, <NUM>, <NUM>) comprises a second clock (<NUM>, <NUM>, <NUM>) to produce a second oscillating signal;
a vehicle wireless local area network, WLAN, (<NUM>) over which at least the first network controller (<NUM>, <NUM>, <NUM>) and the second network controller (<NUM>, <NUM>, <NUM>) are to communicate,
wherein a link between the first network controller (<NUM>, <NUM>, <NUM>) and the second network controller (<NUM>, <NUM>, <NUM>) through the vehicle WLAN (<NUM>) is a synchronized link based on transition edges of the first oscillating signal being aligned in time with transition edges of the second oscillating signal;
wherein each of the first network controller (<NUM>, <NUM>, <NUM>) and the second network controller (<NUM>, <NUM>, <NUM>) comprises:
a respective first queue to store data according to a real-time access class that is to be communicated between the first network controller (<NUM>, <NUM>, <NUM>) and the second network controller (<NUM>, <NUM>, <NUM>) over the synchronized link, and
a respective second queue to store non-real-time access class data that is to be communicated between the first network controller (<NUM>, <NUM>, <NUM>) and the second network controller (<NUM>, <NUM>, <NUM>) over a further link separate from the synchronized link.