CN117319142A - Air-space-ground integrated vehicle networking gateway model based on NFV - Google Patents

Abstract

The invention discloses an air-to-ground integrated vehicle networking gateway model based on network function virtualization (Network Functions Virtualization, NFV) technology, which can realize the problem of rapid conversion of heterogeneous network protocols, integrates multi-mode networks such as special short-range communication, cellular network, satellite network and the like, and comprises five main modules: the system comprises a receiving module, a safety module, a conversion module, a load balancing module and a transmission module, wherein direct or indirect information interaction between in-vehicle network data and out-vehicle heterogeneous network data is realized, and high reliability and high throughput of data transmission can be effectively maintained. Based on an air-ground integrated vehicle network system architecture, the vehicle networking gateway provided by the invention can provide flexible and effective gateway protocol conversion functions, is realized based on a container virtualization technology, has the characteristics of flexible construction, convenient test and high test performance-price ratio, and can meet various complex vehicle networking application scenes.

Description

Air-space-ground integrated vehicle networking gateway model based on NFV

Technical Field

The invention belongs to the field of network communication, and relates to a vehicle networking gateway model, in particular to an air-to-ground integrated vehicle networking gateway model based on network function virtualization (Network Functions Virtualization, NFV).

Background

The internet of vehicles is composed of heterogeneous networks of In-vehicle networks (IVN) and on-vehicle internets (Internet of Vehicles, ioV), the IVN is used for exchanging information between In-vehicle devices, and common In-vehicle communication technologies include CAN-FD, flexRay, etherNet, MOST and the like, in order to process data generated by each functional module In the vehicle at a high speed, high bandwidth required for data transmission generated from the vehicle devices is satisfied, and the In-vehicle networks are integrated into an ethernet main trunk. IoV builds a Vehicle-to-X (V2X) network outside the Vehicle and exchanges information between V2X elements. V2X communications use cellular-based communications technologies (e.g., LTE and 5G) or IEEE 802.11-based dedicated short range communications technologies (DSRC) to communicate with each other. For automated driving services in advanced driving, data exchange often occurs in IVNs and IoV. Even though the Ethernet backbone provides enough bandwidth to handle a large amount of data, as the communication strength of the Ethernet backbone increases, information transmission for automatic driving control will be delayed, which may seriously affect vehicle safety. For autopilot, it is important to consider the integration of IVN and IoV networks under various network conditions, rather than a single network.

DSRC (Dedicated Short-range communication) is a small-range wireless communication technology, has characteristics of low delay, high reliability and the like, is mature in technology, but is easy to block by a building in a transmission distance range, and may require repeated construction of a signal transmitter. Considering the drawbacks of DSRC technology, LTE-V2X technology based on cellular communication technology has evolved, which includes two modes of operation, centralized (LTE-V-Cell) and distributed (LTE-V-Direct). The LTE-V-Cell needs the base station as a control center to realize large-bandwidth and large-coverage communication, and the LTE-V-Direct can directly realize low-delay and high-reliability communication between the vehicle and surrounding environment nodes. But LTE-V is not as good as DSRC in terms of time delay. Compared with other network protocol systems, the delay tolerant network (Delay Tolerant Network, DTN) has expandability and better performance in a space network environment, and is also taken as the development direction of space network interconnection by CCSDS.

The key of network interconnection is the design of a gateway, wherein the gateway is an interface device for connecting different types of networks, integrates the functions of a bridge and a router, and is a bridge between an internal network and an external network of a vehicle. In heterogeneous vehicle networks, separating IoV and IVN by gateway has a security advantage in that the gateway can more efficiently check intrusion detection before connecting external data to the domain gateway in the IVN backbone. The efficient protocol conversion method is one of the key points of network interconnection in gateway design, and meanwhile, the selection of a proper protocol system is also one key point.

NFV-based internet of vehicles gateway implementation methods are studied to provide efficient connectivity for vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) or vehicle-to-road (V2R), vehicle-to-sensor (V2S), vehicle-to-person (V2P), vehicle-to-cellular (V2C), and vehicle-to-internet (V2I). The platform integrates a 4G-LTE cellular base station, DSRC, DTN network and the like, meanwhile, the rapid change of the vehicle density along with time is considered, and the ground network resources are related to the geographic area to a certain extent, so that the resource waste and the short of different time and place are caused, and even if an optimized deployment strategy is used, the efficient resource utilization and the service quality satisfaction degree are difficult to realize in the long term; in addition, the ground network is covered in rural areas and remote mountain areas to have loopholes, so that the ubiquitous connection of vehicles is limited, and the development of future automatic driving can be influenced to a certain extent. Thus, the experimental platform designed herein introduced an aerial and space network to provide connectivity for vehicles, where on-demand deployment of the aerial network (i.e., the drone) adapts the network to different environments, while the space satellite network may provide ubiquitous wireless coverage. The air-ground integrated Internet of vehicles gateway can be connected with an internal network and an external network of the vehicle, so that communication among vehicles is realized. Therefore, the coordination among vehicles can be improved, the road traffic condition is improved, and the driving safety and the driving efficiency are improved. The gateway can realize the safety isolation between the vehicle and the external network, prevent the vehicle-mounted network from being hacked, and ensure the driving safety of the vehicle. Meanwhile, the air-space-ground integrated Internet of vehicles gateway can encrypt data generated by vehicles, and the safety and reliability of the data are guaranteed.

The method and the system have the advantages that a complex real network environment is built, high cost and a longer period are required, so that the NFV technology is introduced, network functions are realized in a virtualized mode, the cost of purchasing special hardware equipment is reduced, the innovation of a network and the deployment of new services are accelerated, and the complexity of managing a large number of hardware equipment is reduced. The method can quickly construct a low-cost, high-fidelity and virtualized V2X gateway system platform under laboratory conditions, and has important theoretical significance and practical value.

Disclosure of Invention

The invention provides an air-space-ground integrated vehicle networking gateway model based on an NFV technology, which has the characteristics of light weight, high test cost performance and flexible construction.

The technical scheme of the invention is as follows:

1 vehicle heterogeneous network communication

The vehicle network consists of heterogeneous networks of gateway-connected IVNs and IoV, as shown in fig. 1. The IVN is an in-vehicle network, which is a highly autonomous local area network constructed among devices in the vehicle through various in-vehicle communication technologies such as CAN-FD, flexRay, etherNet, MOST and the like, and is connected to a surrounding public access network in a wireless mode through a vehicle-mounted communication gateway so as to realize direct or indirect communication among the vehicle and the surrounding devices. In the IoV network, a traveling vehicle is virtualized as individual mobile network nodes, RSUs and the like located to roadsides are virtualized as network stationary nodes, which are connected in a mesh network topology, and a V2X communication network is constructed using a radio access technology such as Dedicated Short Range Communication (DSRC), cellular communication (LTE or NR), and the like.

2 Integrated vehicle network architecture

The integrated network architecture compatible with protocols such as DSRC, LTE, DTN is designed aiming at the actual demands of integrated networking and comprehensive application of the future Internet, wireless mobile networks (aviation telecommunication networks), space networks (CCSDS) and the like. The gateway is a key node of the integrated network, however, the traditional internet of vehicles gateway generally adopts a fixed protocol conversion and data forwarding mode, and lacks expandability. Thus, the gateway node is given programmability.

At the same time, the introduction of aerial and space networks provides connectivity for vehicles, where on-demand deployment of the aerial network (i.e., the drone) adapts the network to different environments, while space satellite networks can provide ubiquitous wireless coverage. Compared with the ultra-dense ground cellular network, the unmanned aerial vehicle can be deployed according to different requirements and serve as a flight relay or buffer unit with different services, so that the unmanned aerial vehicle is more flexible and economical. As shown in fig. 1, the heterogeneous network realizes interconnection through the gateway, thereby forming an integrated network.

3V 2X gateway model

3.1 V2X gateway design

The V2X gateway is a network gateway connecting an in-vehicle network and an off-vehicle network. The vehicle-mounted data generated by the vehicle-mounted device is connected with a IoV network through a V2X gateway. The V2X gateway is also used for the vehicle to receive vehicle-mounted data from other vehicles or road data from the RSU, and can even be connected with unmanned aerial vehicles and satellite equipment. For IoV services, a heterogeneous network consisting of IVNs and IoV is created by IoV access gateways.

The inter-communication with the vehicle external RSU and the connection to the ethernet backbone are supported by converting the messages of the vehicle internal CAN-FD, flexRay, etherNet, MOST to the message type of the destination protocol and converting the structure of the in-vehicle communication protocol to the ethernet structure.

V2X Gateway (V2 XGW) is a network Gateway connecting an in-Vehicle network and an off-Vehicle network, connected to a domain Gateway using an ethernet backbone. V2XGW is a connection point of two different networks, and is responsible for performing operations such as protocol conversion and routing on transmission of communication data between different domains, so that the gateway must be able to run on an EtherNet protocol system and a DSRC/LTE/DTN network protocol system at the same time, that is, the gateway has two protocol stacks. Fig. 2 shows the V2X composition, and the gateway host is composed of five modules, namely a receiving module, a security module, a conversion module, a load balancing module and a transmission module, and the main functional modules are described as follows:

and a receiving module: there are two different buffer registers of Ethernet and DSRC/LTE/DTN in the module.

And (3) a safety module: there is first a Cyclic Redundancy Check (CRC) to ensure that security measures at the data link layer integrate Ethernet and DSRC/LTE/DTN techniques, both of which involve the use of checksum protection of the header and payload information as part of each frame. In the ethernet architecture, the IP header information (e.g., source address, destination address) is protected by a 16-bit checksum, in addition to exchanging real-time data via the widely used User Datagram Protocol (UDP), which adds an additional 16-bit arithmetic checksum to protect the underlying IP header. And performing error detection by adopting a three-way handshake operated by a TCP protocol in the security module.

And a conversion module: data and control information are converted between incompatible networks to enable communication therebetween. The conversion between protocols is essentially a process of encapsulation and decapsulation of both protocols. When a Packet enters V2XGW, the gateway needs to set a header consistent with the protocol stack according to the Packet destination address. Taking a Packet sent by an in-vehicle sensor A to a road side unit B as an example, the specific process is as follows: v2XGW receives Packet from transport layer a and parses out data and its header related control information such as source address, destination address; v2XGW needs to convert the relevant fields of the header of the Packet according to the transport layer protocol of B, such as supplementing or deleting some information, then encapsulating the received Data with DSRC/LTE/DTN message format, and finally forwarding the Packet to B until the B completes receiving.

Load balancing module: the gateway supports load balancing and bandwidth management to optimize the quality of communication between the in-vehicle network and the off-vehicle network. The router needs to be configured according to parameters such as network traffic and transmission speed to ensure balance of data transmission and maximum utilization of bandwidth. By using load balancing algorithms and flow control techniques, such as dynamic routing and quality of service (Quality of Service, qoS) control.

And a transmission module: one cross-domain transmission can be divided into two procedures, and its reliable transmission procedure also includes two parts: a can reliably transfer data to V2XGW and the gateway can then reliably transfer data to B again, which completes a reliable transfer.

3.2 gateway interface State

The network interface has four states, ioV _Recv 、IoV _Send 、IVN _Send 、IVN _Recv Incoming IoV flow has three states, ioV _Queue 、IoV _eMonitoring 、IoV _Scheduling Outgoing fromThere are three states of IVN flow, namely IVN _Queue 、IVN _iMonitoring 、IVN _{Virtualization} . The eMonitoring, iMonitoring status results are used for outgoing and incoming flows, respectively, as shown in fig. 3.

From IoV _Recv The received data traffic passes through IoV _Queue And IoV _Scheduling Status through IVN _Send And flows into the IVN Ethernet main trunk. At IoV _Queue In the state, incoming data packets are classified according to priority. At IoV _Scheduling In a state, the data packets in the queues are scheduled to be sent to the IVN backbone network.

IVN _Recv The state received vehicle-mounted data from the vehicle-mounted sensor passes through the IVN _Queue And IVN _{Virtualization} Status is sent to IoV _Send Status of the device. In IVN _Queue In the state, the data packets are queued in a plurality of queues according to the priority. In IVN _{Virtualization} In the state, a predetermined packet is transmitted using the virtualized IoV network. The network interface may be switched according to wireless IoV network conditions.

3.3 gateway translation protocol

The key to heterogeneous interconnection is the protocol conversion and address mapping of the network adaptation layer, and the protocol stack conditions on both sides of V2XGW, as shown in fig. 4. The protocol stack adopts a modularized design idea and has certain representativeness and universality. For cross-domain communication, V2XGW is required to properly translate the protocol. For this reason, a gateway conversion protocol (V2X Gateway Transform Protocol, V2 XGTP) needs to be defined to solve the problem of lack of relevant field information during protocol conversion between the cross-domain nodes, where V2XGTP can provide a communication specification between a source node and a gateway in the domain, that is, a connection needs to be established with the gateway before the source node crosses over and transmits, and the gateway obtains information required for constructing a DSRC/LTE/DTN or Ethernet packet header, so as to support connection between the gateway and a destination node, and the specific conversion is divided into the following two cases:

1) When the IoV node sends a data packet to the IVN node, the gateway needs to convert the DSRC/LTE/DTN protocol stack to an Ethernet protocol stack. When comparing the DSRC/LTE/DTN header and the Ethernet header, if the control information in the header is irrelevant to the Ethernet protocol, for example, the DTN header is one more Bundle header than the TCP header, the header only needs to be deleted from the message. When forming the Ethernet header, the source address may use the gateway's left-side interface address, and the address to reach the destination node in IoV needs to be obtained from V2 XGTP.

2) When the IVN node sends a packet to the IoV node, the gateway needs to convert the Ethernet packet into a DSRC/LTE/DTN packet, and adds a corresponding header to the DSRC/LTE/DTN packet. In this process, the target address in IoV and other control field information of the DSRC/LTE/DTN header need to be obtained from V2 XGTP.

Compared with the prior art, the air-space-ground integrated vehicle-connected gateway based on the NFV has the following beneficial effects:

1) The platform is based on a container virtualization technology and has the advantages of flexible construction, convenience in testing and high test cost performance.

2) The lightweight container platform customized based on the characteristics of the Internet of vehicles gateway is not limited by special hardware any more, the resource occupancy rate is low, and the complexity of managing a large number of hardware devices is reduced through automatic control.

3) The V2X gateway merges special short-range communication, cellular network, satellite network and other multimode networks, and provides network connection service with wider coverage range, richer transmission resources and higher transmission reliability for vehicles.

4) To better accommodate various types of gateway devices, V2X gateways provide a related API call interface to manage containers, thereby enabling secondary development.

5) The lightweight V2X gateway based on the container virtualization technology can enable users to rapidly deploy applications in batches, realizes resource isolation among applications, and can be suitable for various Internet of vehicles application scenes.

[ description of the drawings ]:

FIG. 1V 2X gateway communication architecture;

FIG. 2 gateway system state logic;

FIG. 3 is a schematic diagram of a V2X gateway architecture;

FIG. 4 is an integrated network protocol stack;

FIG. 5 is a V2X gateway topology;

FIG. 6 is a flow chart for the construction of an NFV-based V2X gateway system

Specific embodiment(s):

the invention is described in detail below with reference to the drawings and specific examples.

Fig. 5 shows a topology structure of a V2X gateway based on NFV technology, where the topology structure mainly includes three domains, namely a vehicle domain DV, a road domain DR and a space-based network domain DS, each domain includes a plurality of virtual network devices, the DV domain includes virtual hosts V1, V2 and V3, which represent a cart, and the V2X gateway is deployed on the cart; the DR domain includes RSU1, RSU2, eNB1, eNB2, etc., where RSU stands for a road side unit, configures DSRC protocol, eNB stands for a base station, and configures LTE protocol. The DS domain represents the space-based network, and adopts a DTN protocol to ensure the reliable communication of the network. Communication between hosts in two domains is accomplished by means of a V2X gateway, whereas communication between hosts in a domain is not required.

A Linux container (LXC) is adopted as a virtual middlebox, and a corresponding VNF is run on the middlebox to construct a corresponding V2X gateway, a virtual router, a mobile host, a virtual host, and the like.

For the configuration of the ground network, we configure the network card and the communication program on the LXC as a common virtual host. Quagga software is installed and configured on the LXC to serve as a virtual router. By using Linux virtual bridge technology as a simulated network link, we connect virtual middleboxes according to fig. 5 to form NFV-based internet of vehicles test platforms.

And configuring the LTE network according to specific requirements, creating two containers of the LTE-base and the core-network, respectively configuring the LTE base station and the core network, entering a core-network container, and installing and configuring a core network component. The core network is generally composed of MME, HSS, SPGW and PCRF components. The connection of the UE and the base station is configured. This may be achieved by configuring the enb. The connection between the core network and the Internet is configured. This may be achieved by adding a NAT network to the core network container.

The DTN container is configured by installing DTN2 first, and DTN2 mainly realizes the bundle protocol defined in RFC5050, security policy and integrity protection. Before compiling install Dtn2, it is necessary to ensure that gcc compiler is above version 3.3. First, enter the corresponding lxc container installation tool command language tcl (tool command language), which is often used for rapid prototyping, script programming, GUI, and testing; then installing an open-source embedded database management system Berkeley DB, which can provide high-performance data management service for the application program; the object oriented adapter system interface oasys, in effect a c++ library, is then installed to provide a tool for encapsulating the collection of classes and system programs.

After the corresponding installation process is completed in Ubuntu, the installed Dtn2 is configured in two main configuration modes: initializing the configuration using the dtn.conf file and altering the configuration with the console. Dtn.conf is the default configuration file for dtn network connections, first a directory creation dtn folder is selected to hold some of the demand files for dtnd, and the bundles and db folders are created under dtn folder. Then, edit dtn-2.9.0/daemon/dtn.conf file, set IP address, port, storage mode, bundle load file, route configuration, etc. The dtn application may be launched after the corresponding configuration is completed in the container.

The following is a specific embodiment of V2X gateway system construction based on NFV technology, see fig. 6, including:

step S1, creating a Linux container, realizing isolation and encapsulation of an operating system environment, installing a Virtual Network Function (VNF), providing various network functions for network equipment, and performing personalized configuration on the VNF through a configuration file so as to meet the requirement of a specific network environment and form software-based network equipment;

step S2, installing quagga in a Linux container, configuring the quagga, including setting a routing protocol, a router ID, an interface address and the like, starting the quagga software package to enable the quagga software package to run in the Linux container, connecting a plurality of virtual routers according to a certain network topology structure to form an end-to-end path, and configuring a routing protocol to enable the virtual routers to select an optimal path according to the network topology structure;

step S3, simulating DTN, LTE, DSRC and other specific networks by programming a special network protocol or controlling virtual router interface performance parameters, and combining two methods: one approach is to compile a proprietary network protocol that needs to be matched to the type of network being simulated to achieve accurate network behavior simulation. Another approach is to simulate the network by controlling performance parameters of the virtual router interface, such as bandwidth, delay, packet loss rate, etc. And performing performance test by using corresponding network simulation software. The two methods are comprehensively used, so that a specific type of network can be more accurately simulated, and various network simulation and performance test requirements can be met;

step S4, constructing the V2X gateway container needs to respectively run and configure the network container and the customized protocol conversion program according to different layers of the protocol stack. In terms of network containers, multiple virtual containers may be created using LXC container technology. The containers are isolated from each other, so that interference among different protocols is avoided, and various network application programs can be flexibly deployed and managed. In terms of protocol conversion programs, corresponding programs are written according to conversion requirements among different network protocols;

and S5, finally, connecting the network equipment including the gateway host according to a certain network topology structure to realize communication between the in-vehicle network and the out-vehicle heterogeneous network.

Embodiments for testing whether a heterogeneous network is capable of implementing data communication through a gateway specifically include:

1、D _S network interconnection in domains

In the virtual host h1 shown in fig. 5, a daemon process dtn is started, and a terminal running application program is started in another virtual host h2, so that two virtual hosts can be tested to ping. Regarding the setting of routing nodes, DTLSR routing protocol implemented with Dtn2 is employed and LSAs are sent and accepted by a link discovery agent. Let h1 be the transmitting end and transmit data by dtnsend; and h2 is taken as a receiving end, data is received by using dtnrrecv, and a communication test between two nodes is carried out. Experiments show that file transmission can be performed between any two DTN virtual hosts.

2、D _V Domain and D _R Network interconnection of domains

D _V Node in the domain to D _R Nodes in the domain send files, and D _R Node in the domain to D _V Nodes in the domain send files, i.e., communications between the analog vehicle and roadside nodes or cellular base stations. An ethernet interface is configured inside the in-vehicle network container, and an IP address is assigned thereto. DSRC communication protocols are configured inside roadside node RSU containers, configured using standards such as IEEE802.11 p. The roadside node RSU container is configured with an IP address and a communication interface is enabled in the DSRC protocol stack. The gateway container is started so that the in-vehicle network container can communicate with the roadside node RSU through the V2X gateway. The base station container eNB is configured, assigned a unique IP address, and configured with the LTE network. Communication between the in-vehicle network container and the roadside node RSU1 container and the base station eNB1 are tested. In the in-vehicle network container, connectivity with the roadside node RSU1 container and the base station eNB1 is tested using a ping command. In the roadside node RSU1 container, a message may be sent to v1 and a message from v1 may be received indicating that communication between the vehicle and the roadside node may be through a gateway. In the base station eNB1 container, a message may be sent to v1 and a message from v1 may be received indicating that communication between the vehicle and the base station may be through a gateway.

3、D _V Domain and D _S Network interconnection of domains

D _V Domain and D _S The domains cannot communicate directly, communication needs to be completed through a gateway, network connection between a virtual host and the gateway needs to be established first, a dhcp server is installed in gateway nodes of the two domains, wireless connection is simulated, and an IP address is dynamically acquired. To achieve communication between nodes and gateways, we program implementation based on the interface of the DTN protocol stack for gateway translation protocol and file transfer. Separately test slave D _V Node in the domain to D _S Nodes in the domain send files and D _S Node in the domain to D _V Nodes in the domain send files. In D _S Domain to D _V For example, the domain communication starts the receiving procedure in the ordinary Ethernet node, the dtnrrecv procedure in the gateway, and the data is given in the dtn source node, e.g. h1The gateway sends a message, then starts the dtncp program to send a file to the gateway, and tests show that file transmission can be carried out between the two domains through the gateway.

The air-space-ground integrated Internet of vehicles gateway system based on the NFV technology provided by the invention is described in detail, and a gateway construction method is also described. The principles and embodiments of the present invention have been described herein with specific application to the details of the method and its core concept, which are set forth in the examples above. It should be noted that it will be apparent to those skilled in the art that several improvements and modifications can be made to the present invention without departing from the principle of the invention, and these improvements and modifications fall within the scope of the claims of the invention.

Claims (3)

1. Heterogeneous Internet of vehicles architecture

The In-vehicle network is composed of an In-vehicle network (IVN) and an In-vehicle internet (Internet of Vehicles, ioV), the IVN exchanging information between In-vehicle devices, the IOV building a vehicle-to-X (V2X) network outside the vehicle, and exchanging information between V2X elements. IoV data flows into the IVN through the network gateway of the vehicle and is transmitted to the on-board equipment required by the intelligent service, and the on-board data of the IVN is also transmitted to the IoV network through the network gateway. Namely, the gateway is connected with IoV and the IVN heterogeneous network to realize vehicle-mounted data exchange between IoV and IVN networks.

In IVN, CAN-FD, flexRay, etherNet, MOST and other communication technology is integrated to Ethernet main network to raise speed of processing data generated by each functional module in vehicle. In IVN, on-board data is used to control autopilot or share its vehicle information with other vehicles. If the communication strength of the ethernet backbone increases, information transmission for automatic driving control will be delayed, thereby seriously affecting vehicle safety. Therefore, it is necessary to manage the transmission traffic in consideration of the status of the IVN backbone.

2. Gateway model of Internet of vehicles

2.1 gateway Structure design

The V2X access gateway (V2 XGW) is a network gateway connecting an in-vehicle network and an off-vehicle network. And the vehicle-mounted data generated by the vehicle-mounted equipment is connected with a IoV network through a V2X gateway. The V2X gateway is also used for the vehicle to receive vehicle-mounted data from other vehicles or road data from the RSU, and can even be connected with unmanned aerial vehicles and satellite equipment. For IoV services, a heterogeneous network consisting of IVNs and IoV is created by IoV access gateways.

V2XGW is a connection point of two different networks, and is responsible for performing operations such as protocol conversion and address mapping on transmission of communication data between different domains, so that the gateway must be able to operate on two network protocol systems of EtherNet and DSRC/LTE/DTN at the same time, i.e. the gateway has two protocol stacks. One side of the protocol stack at two sides of the V2XGW adopts an EtherNet system architecture, and the other side adopts a DSRC/LTE/DTN system architecture.

2.2 gateway function requirement

And (3) a safety module: there is first a Cyclic Redundancy Check (CRC) to ensure that security measures at the data link layer integrate Ethernet and NR techniques, both of which involve the use of checksum protection of the header and payload information as part of each frame. In the ethernet architecture, the IP header information (e.g., source address, destination address) is protected by a 16-bit checksum, in addition to exchanging real-time data via the widely used User Datagram Protocol (UDP), which adds an additional 16-bit arithmetic checksum to protect the underlying IP header. And performing error detection by adopting a three-way handshake operated by a TCP protocol in the security module.

And a conversion module: data and control information are converted between incompatible networks to enable communication therebetween. The conversion between protocols is essentially a process of encapsulation and decapsulation of both protocols. When a Packet enters V2XGW, the gateway needs to set a header consistent with the protocol stack according to the Packet destination address. Taking a Packet sent by an in-vehicle sensor A to a road side unit B as an example, the specific process is as follows: v2XGW receives Packet from transport layer a and parses out data and its header related control information such as source address, destination address; v2XGW needs to convert the relevant fields of the header of the Packet according to the transport layer protocol of B, such as supplementing or deleting some information, then encapsulating the received Data with DSRC/LTE/DTN message format, and finally forwarding the Packet to B until the B completes receiving.

Load balancing: the on-board gateway needs to support load balancing and bandwidth management to optimize the communication quality between the in-car network and the off-car network. The router needs to be configured according to parameters such as network traffic and transmission speed to ensure balance of data transmission and maximum utilization of bandwidth.

And a transmission module: one cross-domain transmission can be divided into two procedures, and its reliable transmission procedure also includes two parts: a can reliably transfer data to V2XGW and the gateway can then reliably transfer data to B again, which completes a reliable transfer.

2.3 gateway interface State

The network interface has four states, ioVRecv, ioVSend, IVNSend, IVNRecv, the incoming IoV flow has three states, ioVQueue, ioVeMonitoring, ioVScheduling, and the outgoing IVN flow has three states, IVNQueue, IVNiMonitoring, IVNVirtualization. The eMonitoring, iMonitoring status results are used for outgoing and incoming flows, respectively, as shown in fig. 3.

Data traffic received from the IoVRecv flows into the IVN Ethernet main backbone through the IVNSend through the IoVQueue and IoVScheduling states. In the IoVQueue state, incoming packets are classified according to priority. In the IoVScheduling state, data packets in a plurality of queues are scheduled to be sent to the IVN backbone network.

And the vehicle-mounted data from the vehicle-mounted sensor, which is received by the IVNRecv state, is sent to the IoVSend state through the IVNQueue and the IVNVirtualination state. In the IVNQueue state, packets are queued in multiple queues according to priority. In the ivnvirtualination state, a predetermined packet is transmitted using the virtualized IoV network. The network interface may be switched according to wireless IoV network conditions.

3. Gateway translation protocol

The key to heterogeneous interconnection is the protocol conversion and address mapping of the network adaptation layer, and the protocol stack conditions on both sides of V2XGW, as shown in fig. 4. The protocol stack adopts a modularized design idea and has certain representativeness and universality. For cross-domain communication, V2XGW is required to properly translate the protocol. For this purpose, a gateway conversion protocol (V2X Gateway Transform Protocol, V2 XGTP) needs to be defined to solve the problem of lack of relevant field information during protocol conversion between the cross-domain nodes, where V2XGTP can provide a communication specification between a source node and a gateway in the domain, that is, a connection needs to be established between the source node and the gateway before the source node crosses over the transmission, and the gateway obtains information required for constructing a DSRC/LTE/DTN or Ethernet packet header, as shown in fig. 5, and supports connection between the gateway and a destination node, where specific conversion is divided into the following two cases:

1) When the IoV node sends a data packet to the IVN node, the gateway needs to convert the DSRC/LTE/DTN protocol stack to an Ethernet protocol stack. When comparing the DSRC/LTE/DTN header and the Ethernet header, if the control information in the header is irrelevant to the Ethernet protocol, for example, the DTN header is one more Bundle header than the TCP header, the header only needs to be deleted from the message. When forming the Ethernet header, the source address may use the gateway's left-side interface address, and the address to reach the destination node in IoV needs to be obtained from V2 XGTP.

2) When the IVN node sends a packet to the IoV node, the gateway needs to convert the Ethernet packet into a DSRC/LTE/DTN packet, and adds a corresponding header to the DSRC/LTE/DTN packet. In this process, the target address in IoV and other control field information of the DSRC/LTE/DTN header need to be obtained from V2 XGTP.