Initialization of system devices for packet-based data transmission - Patents.com
The method addresses the challenge of achieving deterministic latency in automotive data transmission by initializing a system device for packet-based data transmission over multiple virtual routes using a single physical channel, effectively balancing latency and bandwidth requirements.
Patent Information
- Application Number
- JP2024557132
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-09-27
- Filing Date
- 2023-09-21
- Publication Date
- 2025-05-08
- Estimated Expiration
- 2043-09-21
AI Technical Summary
Existing data transmission technologies in automobiles struggle to achieve deterministic latency times while minimizing hardware and software effort, especially when multiple data paths need to be transmitted efficiently over a single physical channel.
A method for initializing a system device or data channel that allows packet-based data transmission over up to 128 virtual routes using a single physical data channel, with deterministic latency. This is achieved by reading latency and bandwidth specifications for each virtual data path and setting packet lengths accordingly, using four predetermined packet lengths to balance latency and bandwidth requirements.
The method enables efficient, deterministic data transmission with minimal overhead, allowing for multiple independent data paths to be transmitted over a single physical channel, which is particularly advantageous in weight-constrained automotive applications.
Smart Images

Figure 2025514574000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to a method for initializing a system device or a data channel, in which packet-based data transmission is optimized to have a deterministic latency time. Although an implementation of 128 lines is required, it is possible to use a single physical data line. Due to the packet-based transmission, the latency time of the data transmission can be controlled independently of the bandwidth of the transmission channel. Thus, a deterministic latency time is achieved with a single physical communication channel. This is particularly advantageous in automobiles, especially since e-mobility requires weight savings to increase the range of automobiles. The present invention is further directed to a suitably configured system device, as well as a computer program product and a computer-readable medium with control instructions for performing the method or operating the system device. [Background technology]
[0002] US Pat. No. 5,399,433 shows network adjustment according to latency specifications. US Pat. No. 5,399,633 shows a circuit for use in a multimedia server module connectable to a number of multimedia sources generating at least one multimedia signal.
[0003] Packet-based data transmissions are known in the current technology, but the underlying hardware is not weight-constrained. For example, network couplings are known that are realized by a certain number of data cables. In this case, redundant data lines or data paths are proposed in computer networks, where weight is typically of secondary importance. However, these network-based data transmissions, including their implicit topology and architecture, cannot be used in automobiles due to special requirements.
[0004] Data transmission solutions for in-vehicle use cases must have maximum efficiency (minimal overhead) in terms of bandwidth utilization and must be capable of transmitting a large number (>100) of data paths in parallel over the physical medium (optical fiber or electrical cable), and the data paths must be independent of each other.
[0005] A low latency data path must not require high bandwidth, which is not possible in pure frame-based or TDM systems (where low latency is achieved through a fixed allocation of bandwidth).
[0006] Data paths must have deterministic latency times, which is not possible in systems with possible collisions on the physical layer or flexible data routing (Ethernet).
[0007] Systems with inefficient line coding (eg, 8B / 10B=25% overhead) have too high an overhead for high bit rate data transmission. Variable (data) packet lengths require a lot of overhead to recognize them during data recovery (from a serial data stream).
[0008] It is therefore necessary to create processes in automobiles that make it possible to achieve deterministic latency times with little engineering effort, both on the hardware and software side, and that take into account the parameters of the data lines. [Prior art documents] [Patent documents]
[0009] [Patent Document 1] U.S. Pat. No. 9,043,509 [Patent Document 2] European Patent No. 1993237 Summary of the Invention
[0010] It is therefore an object of the present invention to propose a method for initializing a system device, a communication channel or a data transmission, which makes it possible to achieve a deterministic latency time with minimal effort. Furthermore, it is an object of the present invention to propose a correspondingly configured system device as well as a computer program product and a computer-readable medium with control instructions for carrying out the method or for operating the system device.
[0011] This problem is solved by the features of claim 1. Further advantageous embodiments are set forth in the dependent claims. Therefore, a method is proposed for initializing a system device for packet-based data transmission on up to 128 virtual paths via a vehicle's physical data channel with deterministic latency, comprising: reading, for all virtual data paths for the transmission of a bit string to be transmitted, a given latency time specification and / or bandwidth specification of said data channel; and setting a packet length for each of said 128 data paths taking into account four predefined packet lengths of said bit string, said packet lengths being selected such that for short latency requirements and low available bandwidth short packet lengths are used and for long latency requirements and high available bandwidth long packet lengths are used.
[0012] According to the invention, it is proposed to initialize a system device or to initialize a data channel for packet-based data transmission. Although a single physical data channel is specified, up to 128 virtual data paths are possible on this channel, connecting different data sources to a data sink. For this purpose, identifiers of the virtual paths may be used and / or corresponding addresses may be used. Initially, the data channel or data transmission is not necessarily characterized by certain properties, but rather any bandwidth is available and the latency time is non-deterministic. The method makes the data transmission deterministic with respect to latency, taking into account the given bandwidth.
[0013] In a preparation step, a given latency time specification and / or bandwidth specification of the data channel is read. The latency time specification may be application-specific. In this regard, a data memory may be used to store the expected latency time of each channel. This specification may also be influenced by the data channel itself, so that only latency times within a certain range are possible. The data channel may also specify a specific bandwidth required. The bandwidth specification may be application-specific to specify how much bandwidth is required. The latency time specification and / or bandwidth specification may also be based on the number of occupied virtual data paths, such that multiple data paths divide certain system parameters between them.
[0014] In general, the latency or bandwidth specifications need not be the same for each virtual data path. A readout of a given latency and / or bandwidth specification can be defined for each virtual data path individually, allowing these parameters to vary from virtual data path to virtual data path. The latency or bandwidth specifications can also be read out such that the physical data channel is measured and a corresponding specification is derived from the measurement. The readout can also be done continuously or at recurring intervals such that the latency or bandwidth specification can be adjusted over time.
[0015] Then, the packet length is set for each of the 128 virtual data paths by considering four predetermined packet lengths of the bit string. The length of the selected packet length is therefore set for each virtual data path. Experimentally, it has been found that exactly four predetermined packet lengths are advantageous. This allows a significant reduction in the number of packet lengths, i.e., to consider exactly four, which is still sufficient to perform a trade-off between a given latency time specification and a given bandwidth specification.
[0016] The packet length is selected such that for short latency requirements and low available bandwidth, short packet lengths are used. Similarly, for long latency requirements and high available bandwidth, long packet lengths are selected. This processing step is based on the idea that smaller or shorter packets can be transmitted faster, and in this respect, these packets are selected for short latency requirements. A short latency requirement corresponds to a numerically low latency requirement. Thus, a short latency time is required. Generally, a low latency requirement is referred to as a short latency requirement. With a low latency requirement, a short latency is required. With a higher or longer latency requirement, a higher latency is expected. According to the terminology used, a low requirement does not result in a high latency. Similarly, a high requirement does not result in a low latency.
[0017] Packet length refers, for example, to the number of bits available per packet. If more bandwidth is available, a longer packet length is selected since a larger amount of data will be transmitted (which will also require more bandwidth). The listed parameters may also be influenced by other parameters. For example, the selection of the packet length may also be influenced by the total amount of data to be transmitted. A larger bandwidth, and therefore a longer packet length, is suitable for a larger amount of data.
[0018] According to one aspect of the invention, the amount of overhead data is reduced by increasing the packet length. This has the advantage that it is possible to determine a so-called excess of data during encoding and also to influence the packet length depending on the amount of data to be transmitted. For example, if the amount of data to be transmitted increases, according to the invention a packet length longer than the one initially set can be selected. Thus, according to the invention, the packet length is increased if it is recognized that the excess is too high or can be minimized. The so-called excess data amount is a data amount that does not directly refer to user data, but describes the data required for encoding or data transmission. For example, the optimization of disparity in the transmitted data may mean that 128 bits have to be transmitted instead of a data amount of 112 bits. The packet length can also be increased, since a multiple of this can also be transmitted or there is a larger amount of data.
[0019] According to a further aspect of the invention, the data to be transmitted is 112 bits or a multiple thereof. This has the advantage that the proposed method can be applied particularly efficiently to these data segments. For example, the coding is particularly advantageous for 112-bit wide data segments transmitted with 128-bit symbols. Coding the full number of bits would exponentially increase the effort and complexity of the coding. In this case, the data to be transmitted is limited to four packet lengths, it is easy to create a coding table during coding and there is no longer the complexity of a packet transmission using a single data length. A single data length defines a very long bit sequence to be transmitted. However, the complexity of finding a coding for it grows exponentially. Partial data lengths, for example four lengths, reduce this complexity to a much smaller number of coding options. Thus, an efficient coding is achieved according to the invention. Thus, according to the invention, the coding table is significantly shorter or the number of coding rules required is significantly reduced compared to conventional coding tables.
[0020] According to a further aspect of the invention, a path identifier, a sequence number, a cell type, at least one checksum, at least one user data information and / or additional user data information are transmitted together with the transmitted bit sequence. This has the advantage that various data fields may also be transmitted, such as describing the virtual path or having a sequence number indicating the order of the packets. Also, further data fields may be transmitted, such as a checksum, indicating whether the data has been transmitted completely.
[0021] According to a further aspect of the invention, the overhead data is 25 or 37 bits. This has the advantage that a sufficient and minimal bit length has been found that allows encoding all possible data required in addition to the user data. By way of example only, reference is now made to Fig. 3, which encodes the first five data fields in 25 bits and also provides an optional check number of 12 bits. It has been found empirically that these bit lengths are optimal and that no more bits than necessary are transmitted, yet still provide all the necessary information.
[0022] According to a further aspect of the invention, a stored metric is used which indicates which of the four predefined packet lengths should be selected. This has the advantage that the metric can store which bandwidth or latency time specification results in which packet length. This means that the appropriate packet length can be determined empirically and which packet length to use can be dynamically adapted at run-time. This can be done separately for all virtual data paths up to 128.
[0023] According to a further aspect of the invention, the metric specifies the respective packet length taking into account the transmitted bandwidth and / or packet length. This has the advantage that the transmitted packet length is taken into account, so that a larger packet length is specified for larger data. The transmitted packet length is the total transmitted packet length, which according to the invention is subdivided into packet lengths of four specified classifications.
[0024] According to a further aspect of the invention, a shorter packet length is selected for a lower bandwidth, which has the advantage that a bandwidth sufficient to transmit the shorter packet length is selected, where it is typically assumed that a lower bandwidth is sufficient since the total amount of data to be transmitted is smaller when a shorter packet length is present.
[0025] According to a further aspect of the invention, a longer packet length is selected for higher bandwidth requirements. This has the advantage that when more bandwidth is required, more data is transmitted, i.e., more user data per header data. With a longer packet length and constant header data (overhead), a better data / overhead ratio is obtained. A longer packet length is advantageous when transmitting more data. Since more user data is transmitted per header data, larger user data requires relatively less header data.
[0026] According to a further aspect of the present invention, a short packet length is selected when less data is transmitted, and a long packet length is selected when more data is transmitted. This has the advantage that the ratio of constant overhead or header data to user data is reduced. Thus, not only can the packet length be selected according to bandwidth or latency requirements, but the size of the data to be transmitted can also be taken into account, which influences the selection of the packet length.
[0027] According to a further aspect of the invention, a stored metric is used that indicates which packet length to select for which range of values of latency requirement and / or available bandwidth. This has the advantage that the range of values can be subdivided by classifying the latency requirement and bandwidth. Typically, a framework is specified for high or low latency requirement or bandwidth. A classification is made within this framework on which the packet length can be selected from the four classifications. The latency requirement and bandwidth lie within a certain frame range or range of values within which the actual values are classified. Within these ranges of values, it is possible to classify the available bandwidth or latency requirement as low, low to medium, medium to high, or high. Other classifications are possible, on which basis the metric specifies which of the four classifications of packet length should currently be used.
[0028] According to a further aspect of the invention, a stored metric is used that indicates which packet length to select for which latency requirement and which bandwidth. This has the advantage of showing exactly when which packet length is used for each virtual data channel, balanced for latency requirement and bandwidth. In this way, the available bandwidth and latency requirement are mapped to a classification of four packet lengths. The corresponding packet length is then selected.
[0029] According to a further aspect of the invention, the four predefined user data lengths are 187 bits, 411 bits, 635 bits and 859 bits. This has the advantage that in addition to being able to use a constant packet segment length of 112 bits, 25 bits of header data and even a 12-bit checksum can be used. According to the invention, it has been determined that 112 bits of data can be encoded in such a way that 128 bits are generated in an advantageous manner, particularly with regard to disparity, and in this respect a bit length of 112 bits per packet segment is advantageous. According to the invention, multiples of 112 bits are transmitted depending on the magnitude of the amount of data to be transmitted. If the bit length corresponds to a multiple of 112 bits, and the multiple is equal to 2, 4, 6 or 8, the following formula is obtained for 25 bits of header data and 12 bits of checksum:
[0030] 112 bits x n-25-12 Thus, once four possible data packet lengths have been selected, designated values of 187 bits, 411 bits, 635 bits, and 859 bits are created for the user data, which produce the preferred encoding and correspond to the four proposed packet lengths.
[0031] According to a further aspect of the invention, the physical data channels are operated electrically or optically, which has the advantage that different transmission technologies are possible and up to 128 virtual data channels can be set up.
[0032] One aspect of the invention is to bundle several data streams (video, audio and data) into transport frames and transmit them serially. Different data formats not only have different bandwidth requirements, but also different latency and bit error rate requirements. In particular, the transmission of today's video data formats requires not only the transmission of pure video data and its frame information, but also the support of encryption methods such as HDCP. All this requires many different data channels with a wide variety of bandwidth, latency and bit error rate requirements. In addition to this, much more complex network architectures are desired than simple transmitter / receiver architectures provide. An architecture with multiple repeaters and branches (Y) where data paths can start and end is advantageous because it also has the possibility to reintegrate data paths into links.
[0033] According to one aspect of the invention, the technology follows the basic idea of bundling data of different services, but offers completely new possibilities in terms of network architectures and allows new approaches in the implementation of today's video interfaces, and can be used for example as Ethernet or a generic data transport layer for the transmission of camera data or any type of sensor data.
[0034] Unlike IP, where a packet may reach its destination via a different route than previous and subsequent packets, in a virtual path (in this invention), all packets / cells follow the same route, and therefore the latency on a virtual path is constant.
[0035] A virtual path based on data cells also has the advantage that it can be used as a multiplexing layer for different services (video, audio, Ethernet). A virtual path consumes bandwidth only when data is actually being transferred.
[0036] The virtual path concept also makes it possible to realize complex and extensive diagnostic and network configuration functions at run-time using separate (virtual) data channels. According to one aspect of the invention, a virtual path layer is implemented between the physical layer (serializer and framer) and the various application data interfaces.
[0037] In accordance with one aspect of the invention, this is used to multiplex various data paths and support more complex architectures with repeaters and branches, which is essentially done at the Virtual Path Layer sublayer of the Cell Layer.
[0038] According to one aspect of the invention, a further part of the virtual path layer is an application adaptation layer which performs packetization of video (stream) or e.g. Ethernet (packet) data into cell format. This application adaptation layer also includes OAM functions for network diagnostics and management.
[0039] According to one aspect of the invention, this technology can be the basis for transmitting a variety of data formats over serial connections in the car (and elsewhere), thus forming the basis for a new generation of devices.
[0040] High serial bandwidth requires defining architectures, cell formats and interfaces that allow flexible internal data bus widths to match the speed of the internal clock system with the capabilities of the chip technology.
[0041] According to one aspect of the invention, the virtual path layer is a physical layer including a transmission sublayer and a physical media sublayer, and the cell layer and application adaptation layer include a segmentation sublayer and a reassembly sublayer, as well as a function for adapting data formats to corresponding applications.
[0042] According to an aspect of the invention, another part of the virtual path layer is the physical layer. Its main task is to establish a physical connection to other physical layers. This connection is essentially bidirectional. In theory, this connection can be realized over a wide variety of media. In practice, two serial differential GBps connections are used. This layer is responsible for line coding, the insertion of null cells to separate the cell rate from the connection rate, and the assembly of the cell stream into a serial frame.
[0043] In the cell layer, the segmentation data (cell payload data) of the above segmentation and reassembly sublayer is assembled into a complete cell with a header, VP identifier and CRC, or the cell is CRC checked and the payload is passed to the segmentation and reassembly sublayer, which may also multiplex the cell streams of different application adaptation functions and distribute the cell payload to the application adaptation functions according to the VP identifier (feed-in / feed-out).
[0044] According to one aspect of the invention, the multiplexing and demultiplexing (forwarding) of cell streams in repeaters and splitters also occurs at the cell layer. According to one aspect of the invention, the task of the application adaptation function is to adapt the data of the application interface to the format of the user data field of the cell and to transmit control information to the other side or to the other side for the adaptation used (time occurrence, framing).
[0045] According to one aspect of the invention, all virtual data paths are unidirectional, i.e., they start at an initiator and terminate at one or more targets. When virtual data paths logically join together, such as HDCP for video channels, thus forming a bidirectional data path, these paths must have the same VP identifier.
[0046] A virtual data path begins at an initiator and terminates at one or more targets. This is achieved by the Cell Sublayer, which performs the following functions on the virtual path: Add / remove multiplexing ·VP conversion Perform the functions of.
[0047] The present invention allows for up to 128 virtual data paths over a common physical layer (cable / line). The data paths behave as if they were routed independently of each other over separate lines / cables. Using one cable and one connector system for 128 data paths instead of 128 cable and connector systems saves resources (cables, connectors), potential error sources (mechanical, electrical, EMC), and weight inside the vehicle.
[0048] Due to the cell-based transmission, the latency of data transmission is not linked to the bandwidth of the transmission channel as in the frame-based (TDM) case. Data paths that require little bandwidth (e.g. video encryption control HDCP) can still be transmitted with the shortest latency.
[0049] Furthermore, for cell-based transmission, data paths only "consume" / require bandwidth when they are actually transmitting data. In the frame-based (TDM) case, this is not the case since a fixed bandwidth is assigned to the data paths.
[0050] To transmit data serially over an electrical or optical medium, a serial data signal must have certain characteristics. Typically, the signal must be DC-free (equal number of 0s and 1s over a period of time) and must have transitions from 0 to 1 or vice versa at intervals so that the receiver can synchronize the individual data bits. This is achieved by line codes: the data to be transmitted is coded before transmission and decoded again after reception. The coding of data leads to overhead during transmission: many more bits must be transmitted than "pure" data bits. The goal is to always keep this overhead as low as possible.
[0051] In the present invention, according to one aspect of the invention, a 112B / 128B block code is used for this purpose. The developed block code represents a very good compromise between the effort required to generate the code and the resulting overhead.
[0052] Encoding 112 bits of data into a 128-bit symbol (line code) implies an overhead of 14.28%. By comparison, the typical 8B / 10B line code has an overhead of 25%.
[0053] Also, it remains very easy to implement line codes with digital logic. <Stream data (continuous data stream)> The Stream Data function combines crossing of the application clock system with the cell data clock system and data bit width conversion from application data to cell data. The payload of a cell is preformatted so that the footer and header of the cell fit into the first and last cell lines.
[0054] Streaming data is (usually) source synchronous. Clock domain crossings of data paths from the application clock domain to the virtual routing layer clock domain are performed here.
[0055] In the transmit direction, a data buffer is provided into which source synchronized data is written along with the source clock. The segmentation layer retrieves data from this buffer as needed to perform data format conversion into N-bit wide rows of cells. Frame data (e.g., Hsync, Vsync, DE) are encoded with payload information bits so that the frame can be reconstructed at the receiver.
[0056] In the receive direction, cell data from the reassembly sublayer is written into a data buffer (cell row bit width). Frame information is reconstructed based on the payload information bits. The source clock is regenerated, for example, using buffer fill levels and clock synthesis.
[0057] If data encryption is required (HDCP), the cell data is encrypted or decrypted by this function. Due to different types of streaming data, such as audio, encrypted video, unencrypted video, etc., there can be different implementations of this basic functionality (e.g., V-stream in / out, A-stream in / out, EncV-stream in / out).
[0058] The interface to the segmentation and reassembly sublayer is the same for all functions. <Burst data (discontinuous data stream)> The burst data function combines clock domain crossing and data bit width conversion of data from the application interface to the N bits of the cell row. The cell row payload is pre-formatted such that the self-filler and header fit into the first and last cell row.
[0059] The burst data is (usually) synchronized to an external time and has different identification signals for direction and data type (address / data / byte enable). This data is usually accompanied by control lines to implement a particular protocol.
[0060] In the transmit direction, a data buffer is provided into which burst data is written along with the interface clock, and the segmentation layer retrieves data from the buffer as needed to perform data format conversion into N-bit wide row cells.
[0061] In the receive direction, cell data from the reassembly sublayer is written into data buffers, which make the cell rows bit-wide. Interface control signals are reconstructed based on the payload information bits.
[0062] The payload information bits are used to generate control signals for the application specific interface or to synchronize protocol state machines in the application specific interface.
[0063] Due to different interfaces providing burst-like data (SPI, I2C, MII), there can be different implementations of this basic function (e.g. SPI burst, I2C burst, MII burst).
[0064] Therefore, their structure should be the same, but they will also have (slightly) different stream in / out interfaces. The problem is also solved by a system device for packet-based data transmission on up to 128 virtual data paths via a physical data channel of a motor vehicle having deterministic latency times, the system device comprising: an interface unit configured to read out for all virtual data paths for the transmission of a bit string to be transmitted a given latency time specification and / or a bandwidth specification of the data channel; and an initialization unit configured to set a packet length for each of the 128 data paths taking into account four predefined packet lengths of the bit string, the packet lengths being selected by a selection unit such that short packet lengths are used for short latency requirements and low available bandwidth and long packet lengths are used for long latency requirements and high available bandwidth.
[0065] The problem is also solved by a computer program product comprising control instructions for carrying out the proposed method or for operating the proposed apparatus. According to the invention, the proposed devices and units can advantageously be operated using the method. Furthermore, the proposed devices and units are suitable for implementing the method according to the invention. The devices thus implement structural features which are in each case suitable for carrying out the corresponding method. However, the structural features can also be designed as process steps. The proposed method also provides steps for implementing the functions of the structural features. Also, the physical components can be virtually provided or virtualized.
[0066] Further advantages, features and details of the present invention are apparent from the following description in which aspects of the invention are described in detail with reference to the drawings. The features described in the claims and the specification are each important to the present invention individually or in any combination. Similarly, the features mentioned above and further described herein may be used individually or in any combination. Functionally similar or identical parts or components may be provided with the same reference signs. The terms "left", "right", "upper" and "lower" used in the description of the embodiments refer to the normally readable figure names or the oriented figures having normally readable reference signs. The illustrated and described embodiments should not be understood as definitive, but are of an exemplary nature for describing the present invention. The detailed description is for the information of those skilled in the art, and therefore known circuits, structures and methods are not shown or described in detail in the description so as not to impede the understanding of the description. [Brief description of the drawings]
[0067] [Figure 1] FIG. 1 is a schematic flow chart of a method for initializing a system device for packet-based data transmission according to one embodiment of the present invention. [Diagram 2] FIG. 2 is a frame format used in the proposed method or system apparatus according to one embodiment of the present invention. [Diagram 3] FIG. 3 is a frame panel used in accordance with one embodiment of the present invention. [Figure 4A-4B] 4A and 4B are metrics for selecting the length of a bitstream based on latency requirements and available bandwidth, according to one embodiment of the present invention. [Diagram 5] FIG. 5 is an exemplary encoding of data segments to symbols for the case where 14 bits are encoded to 16 bits such that the disparity is optimized, according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0068] Some of the figures show parameters that are well known to those skilled in the art in English notation and can be used as parameters and cannot be converted. 1 shows a schematic flow chart of a method for initializing a system device for packet-based data transmission according to an embodiment of the present invention on up to 128 virtual data paths via a vehicle physical data channel having deterministic latency. The method includes the steps of: determining, for all virtual data paths for the transmission of a bit sequence to be transmitted, a given latency time specification of the data channel; and The method comprises reading (100) a bandwidth specification; and setting (102) a packet length for each of 128 data paths taking into account four predetermined packet lengths in a bit string, the packet lengths being selected (101) such that short packet lengths are used for short latency requirements and low available bandwidth, and long packet lengths are used for long latency requirements and high available bandwidth.
[0069] Figure 2 shows a frame format in which 112 bits are coded as 128 bits, resulting in a bit sequence optimized with respect to disparity, as shown for example in Figure 5. The uncoded data cell is 112 bits, which are coded to 128 bits in such a way that the disparity, i.e. the ratio of 0s and 1s, is optimized. Furthermore, the run length of the symbols is limited to 7. This optimizes the data transmission so that the corresponding bit sequence can be read out advantageously with respect to the clock rate.
[0070] This transmission method combines cell-oriented (packet-oriented) data transmission with a simple frame for transmitter and receiver synchronization. According to one aspect of the invention, 256 data cells are transmitted, followed by a 128-bit wide synchronization word. This synchronization word consists of two parts: a 64-bit wide self-synchronizing LFSR sequence for monitoring transmitter and receiver synchronization, and a constant 64-bit wide synchronization pattern for fast transmitter and receiver synchronization. According to one aspect of the invention, the synchronization pattern is unique in the entire data stream. This is guaranteed by the selected line encoding (described below). The synchronization overhead is 128 bits / (256×2×128) bits=0.2% in the worst case and 128 bits / (256×8×128) bits=0.05% in the best case.
[0071] According to one aspect of the invention, the transmission method implements 128 virtual data paths by placing data to be transmitted from up to 128 data sources into four different long (configurable) cells, each cell being given a 7-bit wide address that has a 1:1 correspondence with a virtual data path.
[0072] According to one aspect of the invention, a data cell includes a header field (cell header row) of a predefined fixed length carrying payload data, a payload field (cell payload row) of configurable length (0, 2x128, 4x128, 6x128), and a fixed length footer field carrying a payload checksum and payload data.
[0073] Figure 3 shows the frame fields that can be transmitted according to the proposed invention. In particular, this figure shows the bit lengths of the user data. These are divided into four categories or four predetermined bit lengths, and each virtual data channel transmits data according to this length. Overhead data, which is listed above and / or below the user data in the table, is transmitted in addition to the user data. This allows a bit length of 25 bits of overhead data above the user data and a 12-bit checksum described below the user data to be transmitted.
[0074] The role of the header fields is to allow the control of the data flow through the transmission system. For this purpose, 7-bit wide addresses, VPs (Virtual Path Identifiers), are used. With 7 bits it is possible to uniquely address 128 different data paths, which is completely sufficient for automotive applications.
[0075] A further role of the header fields is to make it possible to "mark" the data in the cells to carry frame information such as the start / end of the data stream or burst information such as the data packet number depending on the data stream or data interface, unlike for example Ethernet, which has to solve this role entirely in software, allowing hardware supported packetization / depacketization of the data stream. Hardware supported packetization / depacketization minimizes the overhead for this role, reducing it to 3 bits PI (payload information) in this case.
[0076] Another role of the header field is to efficiently encode the length of the data field, which is done with the 2-bit CT (cell type). The four different packet lengths have been chosen to allow, on the one hand, to efficiently implement different bandwidth and latency requirements, and, on the other hand, to keep the required control effort to a minimum (2 bits of cell type information per cell).
[0077] Another role of the header fields is to allow an integrity check of the data stream at the hardware level. For this purpose, a 3-bit SN (Running Serial Number) is generated for each cell. In other systems (Ethernet), this has to be done in software and is therefore much less efficient.
[0078] Due to the central role of the header field with respect to data flow and data evaluation, the header field is protected with a 10-bit CRC according to one aspect of the invention. This achieves a Hamming distance of 5 with a maximum of 21 bits. Thus, the header is much better protected than the data. This is very efficient since the header has much fewer bits than the payload field. It is different from Ethernet, where the data and the header are protected with the same (shorter) polynomial.
[0079] 4A and 4B show four basic classifications or bit length selections. The predefined packet length is shown on the far right, the latency requirement is shown in the left column, and the available bandwidth is shown in the center. For example, if the latency requirement is low and the available bandwidth is low, a predefined packet length of 187 bits may be selected. On the other hand, if the latency requirement is high and the available bandwidth is high, a packet length of 859 bits may be selected. In a mixed allocation, either the metric shown in FIG. 4A or the metric shown in FIG. 4B may be selected. For low latency requirements and high bandwidth, either 411 bits or 635 bits may be selected. Similarly, for high latency requirements and low available bandwidth, either 635 bits or 411 bits may be selected.
[0080] Figure 5 shows an example of how to code 14 bits to 16 bits so that the disparity of the resulting data stream is optimized. Since an optimized disparity is advantageous for data transmission, 112 bits are coded to 128 bits according to one aspect of the invention. Therefore, the absolute values are also empirically determined in the proposed technical teaching. In this case, cells are used as a synonym for frames. They may also be packages.
[0081] <Cell format / frame format> According to one aspect of the invention, a cell includes a header having a fixed bit length, a payload area having four selectable bit lengths, and a footer also having a fixed bit length.
[0082] The cell structure is a string of bits as follows: · A 7-bit Virtual Path Identifier (VP) that represents the unique address of the virtual path. · A 3-bit column number (SN) that numbers cells consecutively in their column. · A 2-bit wide cell type (CT) identifier that specifies the length of the user data. · Payload Information (PI), a 3-bit wide bit that contains additional information about the payload. This can also be used to synchronize the payload data with the frame data or control data. A 10-bit wide CRC polynomial (HCRC) for error protection of the header information. This polynomial has a Hamming distance of 5 to a bit string of 21 bits (P=0x2B9). The payload (PL) range has a length of 187, 411, 635 or 859 bits depending on the CT value. The shortest payload is chosen to be even larger than the maximum supported (video) streaming bus width (should simplify the mapping of streaming data into cell payloads). Finally, a 12-bit wide CRC polynomial (PCRC) for error protection of the user data. This polynomial has a Hamming distance of 4 up to a bit string of 2035 bits (P=0x8F3).
[0083] <Transmission frame format> According to one aspect of the invention, a transmission frame includes a sequence of M-bit wide words. The frame starts with an M-bit wide "comma" word from a sequence of comma words defined for frame alignment. This is followed by K cells. A cell consists of 2, 4, 6, or 8 N-bit wide words carrying a header, payload, and footer. These N-bit wide words are encoded into M-bit wide symbols (line encoding).
[0084] This format is chosen to allow the cell data to be processed at the appropriate time frequency, provided that the serializer / deserializer always processes blocks of M bits.
Claims
1. 1. A method of initializing a system device for packet-based data transmission on up to 128 virtual data paths over a vehicle physical data channel having deterministic latency, comprising: Reading (100) a given latency and / or bandwidth specification of said data channel for all virtual data paths for the transmission of a bit sequence to be transmitted; setting (102) a packet length for each of the 128 data paths taking into account four predetermined packet lengths of the bit string, the packet lengths being selected (101) such that short packet lengths are used for short latency requirements and low available bandwidth, and long packet lengths are used for long latency requirements and high available bandwidth; A method for providing the above.
2. 2. The method of claim 1, wherein the amount of overhead data is reduced by increasing the packet length.
3. 3. The method according to claim 1 or 2, characterized in that the transmitted data is nx112 bits+187.
4. 10. A method according to any one of the preceding claims, characterized in that a path identifier, a sequence number, a cell type, at least one checksum, at least one user data information item and / or an additional user data information item are transmitted together with the transmitted bit sequence.
5. 10. A method according to any one of the preceding claims, characterised in that the overhead data is 25 bits or 37 bits.
6. 10. A method according to any one of the preceding claims, characterised in that a stored metric is used which indicates which of the four predefined packet lengths to select.
7. 7. The method according to claim 6, characterized in that the metric specifies the length of each of the packets, and the bandwidth over which the packets are transmitted and / or the packet length are taken into account in the metric.
8. 10. A method according to any one of the preceding claims, characterized in that for low bandwidths a shorter packet length is selected.
9. 10. A method according to any one of the preceding claims, characterized in that for high bandwidths a longer packet length is selected.
10. 10. A method according to any one of the preceding claims, characterized in that a short packet length is selected when the amount of data to be transmitted is small and a long packet length is used when the amount of data to be transmitted is large.
11. 10. A method according to any one of the preceding claims, characterised in that a stored metric is used which indicates which packet length to select for which range of values of the latency requirement and / or the available bandwidth.
12. 10. A method according to any one of the preceding claims, characterised in that a stored metric is used which indicates which packet length to select for which latency requirement and which bandwidth.
13. 10. A method according to any one of the preceding claims, characterized in that the four predetermined packet lengths are 187 bits, 411 bits, 635 bits and 859 bits.
14. 10. A method according to any one of the preceding claims, characterised in that the physical data channel is operated electrically or optically.
15. 1. A system apparatus for packet-based data transmission over up to 128 virtual data paths over a vehicle physical data channel having deterministic latency, comprising: an interface unit adapted to read (100) a given latency time specification and / or bandwidth specification of said data channel for every virtual data path for the transmission of a bit sequence to be transmitted; an initialization unit configured to set (102) a packet length for each of the 128 data paths taking into account four predetermined packet lengths of the bit string, the packet lengths being selected (101) by a selection unit such that short packet lengths are used for short latency requirements and low available bandwidth, and long packet lengths are used for long latency requirements and high available bandwidth; A system device comprising:
16. A computer program product comprising instructions which, when executed by at least one computer, cause said computer to carry out the steps of the method according to any one of claims 1 to 14.
17. A computer readable storage medium comprising instructions which, when executed by at least one computer, cause said computer to perform the steps of the method of any one of claims 1 to 14.
Citation Information
Patent Citations
Method for authenticating time-sensitive network
CN114301937A
Multimedia client / server system with adjustable packet size and methods for use therewith
EP1993237A2
Method and system for low-latency networking
US9043509B2