Roadside equipment deployment method and system and electronic equipment

Abstract

The invention relates to a road side equipment deployment method and system and electronic equipment. The method relates to an edge node and a center node which are in communication connection with each other, the edge node is deployed in an MEC of a roadside network, the center node is deployed in a core network, and the edge node executes the following steps: storing project information issued by the center node into an edge database of the edge node; the project information is generated by the center node based on a plurality of device information lists provided by different manufacturers; when it is detected that the first roadside equipment is accessed to the switch in the roadside network, the item information in the edge database is adopted to perform security authentication on the first roadside equipment; and if the first roadside equipment does not pass the security authentication, determining the first roadside equipment as illegal access equipment, and refusing the illegal access equipment to access the roadside network. According to the scheme provided by the invention, the network security risk can be reduced, the deployment efficiency is improved, the deployment cost is reduced, and normal use requirements are ensured.

Description

Technical Field

[0001] The present application relates to the field of equipment management technology, and in particular to roadside equipment deployment methods, systems, and electronic equipment. Background Art

[0002] In the construction of the vehicle-road-cloud integration project, roadside sensors (such as cameras, lidar, etc.) are connected to the roadside network via Ethernet to complete the final deployment of roadside sensors. Roadside sensors can realize the digitization, coordination and intelligence of traffic elements, and provide real-time data support for autonomous driving, traffic management and travel services.

[0003] Due to the lack of corresponding automatic security management and control mechanisms in related technologies, various roadside sensors can be directly connected to the roadside network without authentication, which greatly increases the security risks of the roadside network. Alternatively, related technologies only have simple authentication methods, such as 802.1X authentication and MAC address authentication. However, both authentication methods require manual configuration on roadside sensors, resulting in low deployment efficiency and high deployment costs. In addition, in certain situations (such as when the roadside network is disconnected from the core network), the authentication process cannot be completed, resulting in the roadside sensors being unable to connect to the roadside network, affecting normal usage needs. Summary of the Invention

[0004] In order to solve or partially solve the problems existing in the related technologies, the present application provides a roadside equipment deployment method, system and electronic equipment, which can reduce the security risks of the roadside network while improving the deployment efficiency of roadside equipment and reducing the deployment cost of roadside equipment. It can also be applied to situations where the roadside network is disconnected from the core network to ensure normal use needs.

[0005] In a first aspect, the present application provides a roadside equipment deployment method, which is applied to an edge node, wherein the edge node is communicatively connected to a central node, the edge node is deployed in an MEC of a roadside network, and the central node is deployed in a core network. The method includes: The project information sent by the central node is stored in its own edge database; the project information is generated by the central node based on multiple equipment information lists provided by different manufacturers; When detecting that a first roadside device is connected to a switch in the roadside network, performing security authentication on the first roadside device using the project information in the edge database; If the first roadside device fails the security authentication, the first roadside device is determined to be an illegal access device, and the illegal access device is denied access to the roadside network.

[0006] A second aspect of the present application provides a roadside equipment deployment method, which is applied to a central node, wherein the central node is communicatively connected to an edge node, the central node is deployed in a core network, and the edge node is deployed in an MEC of a roadside network. The method includes: Get multiple device information lists provided by different manufacturers; generating project information based on the plurality of equipment information lists; The project information is sent to the edge node, so that the edge node uses the project information to perform security authentication on a first roadside device connected to a switch in the roadside network.

[0007] A third aspect of the present application provides a roadside equipment deployment system, the system comprising: a central node and an edge node, the central node being communicatively connected to the edge node, the central node being deployed in a core network, and the edge node being deployed in an MEC of a roadside network; wherein, The central node is configured to obtain multiple device information lists provided by different manufacturers; generate project information based on the multiple device information lists; and send the project information to the edge node; The edge node is used to store the project information sent by the central node in its own edge database; when it is detected that a first roadside device is connected to a switch in the roadside network, the project information in the edge database is used to perform security authentication on the first roadside device; if the first roadside device fails the security authentication, the first roadside device is determined to be an illegally accessed device, and the illegally accessed device is denied access to the roadside network.

[0008] A fourth aspect of the present application provides an electronic device, including: processor; and The memory stores executable codes thereon, and when the executable codes are executed by the processor, the processor is caused to execute the method described above.

[0009] A fifth aspect of the present application provides a computer-readable storage medium having executable code stored thereon. When the executable code is executed by a processor of an electronic device, the processor is caused to execute the method described above.

[0010] A sixth aspect of the present application provides a computer program product, which includes computer instructions, and when the computer instructions are executed by a processor, implements the method described above.

[0011] The technical solution provided by this application may include the following beneficial results: The solution provided in the present application automatically generates project information through a central node based on multiple device information lists provided by different manufacturers. Therefore, there is no need for manual configuration by the user, which greatly reduces the time and manpower consumed by manual configuration, thereby improving deployment efficiency and reducing deployment costs; further, by sending the project information generated by the central node to the edge database of the edge node in advance for storage when the edge node and the central node are in communication connection, even if a disconnection occurs between the roadside network and the core network, since the edge database already contains the project information, the edge node can use the project information in the edge database to perform security authentication on the first roadside device requesting to connect to the roadside network, thereby ensuring normal usage needs; further, since the edge node is close to the data source, the edge node can immediately refuse the first roadside device from accessing the roadside network when the first roadside device fails the security authentication, thereby reducing the security risk of the roadside network.

[0012] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The above and other objects, features and advantages of the present application will become more apparent by describing in more detail exemplary embodiments of the present application in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the present application.

[0014] Figure 1 This is a flow chart of a method for deploying roadside equipment according to an embodiment of the present application; Figure 2 This is a schematic diagram of the deployment of central nodes and edge nodes shown in an embodiment of the present application; Figure 3 This is another flowchart of the roadside equipment deployment method shown in an embodiment of the present application; Figure 4 This is a functional diagram of a central node and an edge node shown in an embodiment of the present application; Figure 5 This is another flowchart of the roadside equipment deployment method shown in an embodiment of the present application; Figure 6 Schematic diagram of the roadside equipment deployment system shown in an embodiment of the present application; Figure 7 This is a schematic diagram of the structure of the central node shown in an embodiment of the present application; Figure 8 This is a schematic diagram of the structure of an edge node shown in an embodiment of the present application; Figure 9 It is a structural diagram of an electronic device shown in an embodiment of the present application. DETAILED DESCRIPTION

[0015] The following describes embodiments of the present application in more detail with reference to the accompanying drawings. Although the accompanying drawings illustrate embodiments of the present application, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. Rather, these embodiments are provided to make the present application more thorough and complete, and to fully convey the scope of the present application to those skilled in the art.

[0016] Due to the lack of corresponding automatic security control mechanisms in related technologies, various roadside sensors can be directly connected to the roadside network without authentication, which greatly increases the security risks of the roadside network. In other cases, related technologies only have simple authentication methods. Currently, there are two main security authentication methods: 1. 802.1X authentication method: After each traditional roadside sensor (such as a camera) is connected to a switch in the roadside network, operations and maintenance personnel must log in to each camera's configuration management interface one by one to manually configure each camera's authentication parameters (such as the authentication server address, certificate, and username / password). Furthermore, this authentication method requires the deployment of a corresponding authentication server in the core network, which then securely authenticates each camera's authentication parameters uploaded from the switch.

[0017] 2. MAC (Media Access Control) address authentication method: After each roadside sensor is connected to a switch in the roadside network, operations and maintenance personnel need to log in to each switch one by one to manually bind the MAC address of each roadside sensor to each port of each switch, so that each switch can perform security authentication on each connected roadside sensor.

[0018] It can be seen that the security authentication method of the relevant technology has the following problems: (1) Low deployment efficiency and high deployment cost: Both of the above two authentication methods require manual configuration on roadside sensors. Since vehicle-road-cloud integration projects are usually large-scale, whether 802.1X authentication or MAC address authentication is used, it will greatly increase the construction period and labor costs, resulting in low deployment efficiency and high deployment costs.

[0019] (2) Poor adaptability: The 802.1X authentication method has high requirements for the network between the switch and the authentication server. When there is a disconnection between the roadside network and the core network, the switch cannot upload the authentication parameters of these cameras to the authentication server, causing the authentication server to be unable to complete the authentication process, and then causing these cameras to be unable to access the roadside network normally, affecting normal usage needs.

[0020] In response to the above problems, an embodiment of the present application provides a roadside equipment deployment method that can reduce the security risks of the roadside network while improving the deployment efficiency of roadside equipment and reducing the deployment cost of roadside equipment. It can also be applied to situations where the roadside network is disconnected from the core network to ensure normal usage needs.

[0021] The technical solutions of the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0022] Figure 1 The figure is a flow chart of a method for deploying roadside equipment according to an embodiment of the present application. Steps S110 to S130 may be performed by an edge node, wherein the edge node is in communication with a central node, the edge node is deployed in the MEC of the roadside network, and the central node is deployed in the core network.

[0023] See also Figure 1 The roadside equipment deployment method of the present application includes: S110, storing the project information sent by the central node in its own edge database; the project information is generated by the central node based on multiple device information lists provided by different manufacturers.

[0024] like Figure 2 As shown, the system for secure access of roadside sensing equipment (hereinafter referred to as the "roadside deployment system") may include a central node and multiple edge nodes. The embodiment of the present application may deploy the central node in the security management area of ​​the core network. Since the vehicle-road cloud project involves the deployment of roadside equipment at multiple intersections, the embodiment of the present application may deploy each edge node separately in the MEC (Multi-access Edge Computing) within the roadside network of each intersection, that is, one edge node is deployed in the roadside network of each intersection, where the roadside network may be a local area network or an intranet.

[0025] It should be noted that the central node can also be deployed in the server area of ​​the core network. The specific deployment location can be deployed in the security management area or server area of ​​the core network according to the actual situation of the user's existing network.

[0026] Among them, each edge node can be communicated with the central node, and steps S110 to S130 can be executed by any edge node. The embodiment of the present application is described below using a single edge node as an example.

[0027] During the early stages of the vehicle-road cloud project, operations and maintenance personnel purchased a batch of secondary roadside equipment from various manufacturers. This equipment may include, but is not limited to, cameras, lidars, millimeter-wave radars, and RSUs (Roadside Units). Each manufacturer provides an equipment list upon shipment, which contains information about each piece of secondary roadside equipment supplied. Because the format of each manufacturer's equipment list varies, this embodiment of the present application pre-configures a preset table template in the central node so that the central node can aggregate the equipment lists provided by each manufacturer into this preset table template to generate project information for the project. The central node can store this project information in its own central database. This project information includes information about all secondary roadside equipment involved in the project. Fields in the project information may include, but are not limited to, project name, equipment type, model, serial number (SN), warranty period, MAC address, and IP address.

[0028] In one example, suppose that cameras A1 to A500 and lidars A1 to A500 are purchased from manufacturer A, cameras B1 to B500, lidars B1 to B500, and millimeter-wave radars B1 to B1000 are purchased from manufacturer B, and RSU devices C1 to C1000 are purchased from manufacturer C. Then, the device information list A provided by manufacturer A can include the device information of cameras A1 to A500 and lidars A1 to A500, and the device information list B provided by manufacturer B can include the device information of cameras B1 to B500, lidars B1 to B500, and millimeter-wave radars B1 to B1000. The device information list C provided by manufacturer C can include the device information of RSU devices C1 to C1000. The central node summarizes the device information lists A to C into the preset table template to generate project information. The project information covers the device information of 1,000 cameras (i.e., cameras A1 to A500, cameras B1 to B500), 1,000 lidars (i.e., lidars A1 to A500, lidars B1 to B500), 1,000 millimeter-wave radars (i.e., millimeter-wave radars B1 to B1000), and 1,000 RSU devices (i.e., RSU devices C1 to C1000).

[0029] It should be noted that the project name refers to the procurement batch of the second roadside equipment. For example, if this project is the first phase of construction, the corresponding project name of the second roadside equipment is the first phase procurement batch; if this project is the second phase of construction, the corresponding project name of the second roadside equipment is the second phase procurement batch.

[0030] When the edge node is in communication with the central node, the central node sends the project information of the current project to the edge node, so that the edge node can store the project information in its own edge database.

[0031] It should be noted that when the construction workers connected this batch of second roadside equipment to the switch at each intersection on site, they did not connect them in sequence according to the device serial number, but connected them randomly. Therefore, the project information received by each edge node is the same, that is, it covers the equipment information of all second roadside equipment involved in this project.

[0032] S120: When it is detected that a first roadside device is connected to a switch in the roadside network, security authentication is performed on the first roadside device using project information in the edge database.

[0033] like Figure 2 As shown, MEC can be connected to the switch in the roadside network at the intersection, so the edge node can detect the connection status of the switch in real time. If it is detected that a first roadside device is connected to the switch at the intersection, since the edge database already contains project information, the edge node can use the project information in the edge database to achieve security authentication of the first roadside device.

[0034] Because the project information covers the device information of all second roadside devices involved in this project, it can be assumed that the second roadside devices are legally connected devices. This embodiment of the present application uses the project information to perform security authentication on the first roadside device to verify whether the first roadside device is the second roadside device. If the first roadside device is the second roadside device, it indicates that the first roadside device is a legally connected device, and the first roadside device can be determined to have passed security authentication. If the first roadside device is not the second roadside device, it indicates that the first roadside device is an illegally connected device, and the first roadside device can be determined to have failed security authentication.

[0035] Similarly, the first roadside equipment may include but is not limited to: cameras, lidars, millimeter-wave radars, and RSU equipment.

[0036] S130: If the first roadside device fails the security authentication, the first roadside device is determined to be an illegal access device, and the illegal access device is denied access to the roadside network.

[0037] If it is determined that the first roadside device has not passed the security authentication, the edge node can determine the first roadside device as an illegally accessed device. If the illegally accessed device is connected to the roadside network at the intersection, the illegally accessed device is likely to publish false information, causing vehicles on the road to be misguided, which can easily cause safety accidents. In this regard, the edge node can refuse the illegal access device from accessing the roadside network at the intersection, thereby reducing the security risk of the roadside network.

[0038] In a specific implementation, the edge node can block the network port corresponding to the illegally accessed device through the Layer 2 control function of the switch at the intersection. For example, the edge node can automatically log in to the switch at the intersection, and then block the network port corresponding to the illegally accessed device through the Layer 2 access control list of the switch port, thereby denying the illegally accessed device access to the roadside network at the intersection.

[0039] Compared with related technologies that require operation and maintenance personnel to manually log in to the switch to implement port blocking, the embodiments of the present application can implement automated port blocking, thereby further improving deployment efficiency and reducing deployment costs.

[0040] As can be seen from this example, the solution provided by the present application automatically generates project information through a central node based on multiple device information lists provided by different manufacturers. Therefore, there is no need for manual configuration by the user, which greatly reduces the time and manpower consumed by manual configuration, thereby improving deployment efficiency and reducing deployment costs; further, by sending the project information generated by the central node to the edge database of the edge node in advance for storage when the edge node and the central node are in communication connection, even if there is a disconnection between the roadside network and the core network, since the edge database already contains the project information, the edge node can use the project information in the edge database to perform security authentication on the first roadside device requesting to connect to the roadside network, thereby ensuring normal usage needs; further, since the edge node is close to the data source, the edge node can immediately refuse the first roadside device from accessing the roadside network when the first roadside device fails the security authentication, thereby reducing the security risk of the roadside network.

[0041] Figure 3 This is another flowchart illustrating a method for deploying roadside equipment according to an embodiment of the present application. Steps S310 to S340 may be performed by an edge node, wherein the edge node is in communication with a central node, the edge node is deployed in the MEC of the roadside network, and the central node is deployed in the core network.

[0042] See also Figure 3 The roadside equipment deployment method of the present application includes: S310, storing the project information sent by the central node in its own edge database; the project information is generated by the central node based on multiple device information lists provided by different manufacturers.

[0043] like Figure 4 As shown, the system for secure access of roadside sensing devices (hereinafter referred to as the “roadside deployment system”) may include a central node and multiple edge nodes ( Figure 4 Only one edge node is shown), in an embodiment of the present application, the central node can be deployed in the security management area or server area of ​​the core network, and each edge node can be deployed separately in the MEC of the roadside network at each intersection.

[0044] Among them, each edge node can be communicated with the central node, and steps S310 to S340 can be executed by any edge node. The embodiment of the present application is described below using a single edge node as an example.

[0045] During the early stages of the vehicle-road cloud project, operations personnel procured a batch of secondary roadside equipment from various manufacturers. This equipment included, but was not limited to, cameras, lidar, millimeter-wave radar, and RSUs. Each manufacturer provided a list of equipment information upon shipment. This list contained information about each piece of secondary roadside equipment supplied by the manufacturer. Because each manufacturer's list format varied, the central node aggregated the lists into a pre-set table template to generate project information.

[0046] like Figure 4 As shown, the central node consists of four main components: "Device Information," "SDK (Software Development Kit) Module Library," "System Management," and "Alarm Management." The "Device Information" component is the central node's central database, which stores project information for each project. For example, the central node can store the project information generated above in the central database. This project information can include all the second roadside equipment involved in the project. Fields in the project information may include, but are not limited to, project name, device type, model, serial number, warranty period, MAC address, and IP address.

[0047] The central node provides a visual interface, and operation and maintenance personnel can update project information in the visual interface. In response to the update operation, the central node updates the project information in the central database. The update operation may include at least one of a modification operation, an addition operation, and a deletion operation. For example, if the device information of a second roadside device is incorrect, the operation and maintenance personnel can perform a modification operation in the visual interface. In response to the modification operation, the central node modifies the device information of the second roadside device in the central database. For example, if a second roadside device previously connected to the roadside network is severely damaged and needs to be replaced with a new one, the operation and maintenance personnel can perform an addition operation and a deletion operation in the visual interface. In response to the addition operation, the central node adds the device information of the newly replaced second roadside device to the central database, and in response to the deletion operation, deletes the device information of the damaged second roadside device from the central database.

[0048] like Figure 4 As shown in the figure, an edge node consists of four main parts: "Device Information," "Device Detection," "Device Management," and "Data Reporting." The "Device Information" part is the edge node's edge database, which stores project information sent by the central node. For example, when an edge node is connected to a central node, the central node sends project information to the edge node, which then stores the project information in its own edge database.

[0049] It should be noted that the project information stored in the edge database can be the same as the project information stored in the central node. For example, the information fields of the project information stored in the edge database also include, but are not limited to, the project name, device type, device model, device serial number, device warranty period, MAC address, IP address, etc. Alternatively, the project information stored in the edge database is only a portion of the project information stored in the central node. For example, the information fields of the project information stored in the edge database only include the device type, device model, device serial number, MAC address, and IP address. These information fields are subsequently used as comparison parameters to determine whether the first roadside device is accessible.

[0050] S320: When it is detected that a first roadside device is connected to a switch in the roadside network, security authentication is performed on the first roadside device using the project information in the edge database.

[0051] like Figure 4As shown in the figure, the "Device Detection" section of the edge node covers three detection methods: ping detection, port detection, and SDK detection. Among them, the ping detection method sends a detection packet via the ICMP (Internet Control Message Protocol) protocol to detect whether the device is online and network connectivity; the port detection method uses TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) port scanning to detect service availability and device type; the SDK detection method actively calls the API (Application Programming Interface) or protocol interface through the SDK provided by the manufacturer to obtain in-depth information.

[0052] The edge node can use the port detection method or the SDK detection method to detect the connection status of the switch in real time. If it is detected that a first roadside device is connected to the switch at the intersection, since the edge database already contains project information, the edge node can use the project information in the edge database to achieve security authentication of the first roadside device.

[0053] Because the project information covers the device information of all second roadside devices involved in this project, it can be assumed that the second roadside devices are legally connected devices. This embodiment of the present application uses the project information to perform security authentication on the first roadside device to verify whether the first roadside device is the second roadside device. If the first roadside device is the second roadside device, it indicates that the first roadside device is a legally connected device, and the first roadside device can be determined to have passed security authentication. If the first roadside device is not the second roadside device, it indicates that the first roadside device is an illegally connected device, and the first roadside device can be determined to have failed security authentication.

[0054] In one embodiment, the project information includes device information of each second roadside device. When a first roadside device is detected to be connected to a switch in a roadside network, security authentication of the first roadside device is performed using the project information in the edge database, which may include: When it is detected that a first roadside device is connected to a switch in the roadside network, the Docker image is run; the Docker image includes an SDK module, which is obtained by integrating a central node based on multiple SDK resource packages provided by different manufacturers; the device information of the first roadside device is detected through the SDK module; the device information of the first roadside device is matched with the device information of each second roadside device in the edge database; if the device information of the first roadside device does not match the device information of any second roadside device, it is determined that the first roadside device has failed the security authentication.

[0055] In addition, the security authentication method of the relevant technology still has the following problems: (3) Poor compatibility: The 802.1X authentication method only supports traditional roadside sensors (such as cameras). However, due to hardware resource limitations, protocol compatibility incompatibility, and differences in design intentions, the 802.1X authentication method does not support new roadside sensors (such as lidar, millimeter-wave radar, etc.).

[0056] In this regard, the embodiment of the present application can obtain corresponding SDK resource packages for different brands of equipment, and mount the integrated SDK module into the roadside deployment system according to the actual needs of this project, thereby achieving support for different brands of equipment.

[0057] In the specific implementation, in addition to providing a list of device information, each manufacturer can also provide a corresponding SDK resource package. Each SDK resource package corresponds to a second roadside device of a device type produced by a manufacturer. The SDK resource package may include but is not limited to: libraries or frameworks, drivers or firmware, tools (debugging tools, compilers, simulators, etc.), documentation (detailed instructions for using the SDK, API interfaces, functional descriptions, etc.), sample code, resource files (images, configuration files, templates, etc.). The central node can integrate all the SDK resource packages involved in this project into an SDK module, and then store the SDK module in the SDK module library. The SDK module library contains SDK modules corresponding to different projects. When carrying out the deployment of this project, the central node can directly call the SDK module corresponding to this project from the SDK module library, and then encapsulate the SDK module into a Docker image so that the Docker image can be sent to each edge node.

[0058] Continuing with the example of step S110 above, manufacturer A can provide SDK resource package 1 of camera type and SDK resource package 2 of lidar type, manufacturer B can provide SDK resource package 3 of camera type, SDK resource package 4 of lidar type and SDK resource package 5 of millimeter wave radar, and manufacturer C can provide SDK resource package 6 of RSU device type. The central node can integrate SDK resource packages 1 to 6 into an SDK module, and then encapsulate the SDK module into a Docker image so that the Docker image can be sent down to each edge node.

[0059] Docker image is an open source containerization platform that allows applications and all their dependencies (code, libraries, environment configuration, etc.) to be packaged into a standardized unit (i.e., container). Therefore, when the edge node detects that a first roadside device is connected to a switch in the roadside network, it can call the detection function of the SDK module by running the Docker image, for example, using the SDK module to detect the device information of the first roadside device.

[0060] It should be noted that Figure 4 The SDK detection method shown is actually implemented by calling the SDK module, so the edge node can run the Docker image in real time to detect the connection status of the switch in real time through the SDK module.

[0061] It should be noted that because the SDK module is integrated based on multiple SDK resource packages provided by different manufacturers, each SDK resource package corresponds to a second roadside device of a specific device type produced by a specific manufacturer. Therefore, if the first roadside device and the second roadside device are of the same device type and produced by the same manufacturer, the SDK module can detect the device information of the first roadside device. For example, assume that the first roadside device is a camera produced by Manufacturer A. Since Manufacturer A provides SDK Resource Package 1 for the camera type, i.e., SDK Resource Package 1 is an integration parameter of the SDK module, the SDK module can detect the device information of the first roadside device.

[0062] After the SDK module detects the device information of the first roadside device, the edge node can verify whether the first roadside device is one of the second roadside devices by matching the device information of the first roadside device with the device information of each second roadside device in the edge database. If the device information of the first roadside device does not match the device information of any second roadside device, it indicates that the first roadside device is not the second roadside device, and it can be determined that the first roadside device has not passed security authentication. If the device information of the first roadside device matches the device information of one of the second roadside devices, it indicates that the first roadside device is the second roadside device, and it can be determined that the first roadside device has passed security authentication.

[0063] In one embodiment, the method may further include: When the SDK module cannot detect the device information of the first roadside device, it is determined that the first roadside device has failed the security authentication.

[0064] If the first roadside device and the second roadside device are of different device types produced by the same manufacturer, or of the same device type produced by different manufacturers, or of different device types produced by different manufacturers, the SDK module cannot detect the device information of the first roadside device.

[0065] As an example, assume that the first roadside device is a millimeter-wave radar produced by manufacturer A. Since manufacturer A only provides SDK resource package 1 for camera type and SDK resource package 2 for lidar type, and does not provide SDK resource package for millimeter-wave radar type, that is, the SDK resource package for millimeter-wave radar type of manufacturer A is not an integrated parameter of the SDK module, and therefore the SDK module cannot detect the device information of the first roadside device.

[0066] As another example, assume that the first roadside device is a camera produced by manufacturer D. Since this project does not involve manufacturer D, that is, the SDK resource package of manufacturer D's camera type is not an integrated parameter of the SDK module, the SDK module cannot detect the device information of the first roadside device.

[0067] As another example, assume that the first roadside device is an ultrasonic radar produced by manufacturer D. Since this project does not involve manufacturer D or the type of ultrasonic radar, that is, the SDK resource package of manufacturer D's ultrasonic radar type is not an integrated parameter of the SDK module, the SDK module cannot detect the device information of the first roadside device.

[0068] When the SDK module cannot detect the device information of the first roadside device, it indicates that the first roadside device is not the second roadside device, and it can be determined that the first roadside device has not passed the security authentication.

[0069] It should be noted that if the second roadside equipment of a new manufacturer (such as manufacturer D) and / or a new device type (such as ultrasonic radar type) is used in the construction of Phase N of the project (N is an integer greater than 1), the central node can use the new SDK resource package to update the previous SDK module, and then encapsulate the updated SDK module into a Docker image so that the Docker image can be sent to each edge node again, so that each edge node can detect the device information of the first roadside equipment through the updated SDK module, thereby realizing the image upgrade of each edge node.

[0070] In one embodiment, the device information includes a device type, a device model, a device serial number, a MAC address, and an IP address; matching the device information of the first roadside device with the device information of each second roadside device in the edge database may include; Match the device type of the first roadside device with the device type of each second roadside device in the edge database respectively, and match the device model of the first roadside device with the device model of each second roadside device in the edge database respectively, and match the device serial number of the first roadside device with the device serial number of each second roadside device in the edge database respectively, and match the MAC address of the first roadside device with the MAC address of each second roadside device in the edge database respectively, and match the IP address of the first roadside device with the IP address of each second roadside device in the edge database respectively; if the device type of the first roadside device does not match the device type of any second roadside device, and / or the device model of the first roadside device does not match the device model of any second roadside device, and / or the device serial number of the first roadside device does not match the device serial number of any second roadside device, and / or the MAC address of the first roadside device does not match the MAC address of any second roadside device, and / or the IP address of the first roadside device does not match the IP address of any second roadside device, then it is determined that the device information of the first roadside device does not match the device information of any second roadside device.

[0071] In addition, the security authentication method of the relevant technology still has the following problems: (4) Poor security: Both 802.1X authentication and MAC address authentication belong to Layer 2 authentication methods and lack Layer 3 network security protection. Therefore, both have certain security issues. For example, the MAC address that the MAC address authentication method relies on can be tampered with by an attacker. In this way, the attacker can tamper with the MAC address of the illegal access device to the MAC address of the legal access device, causing the switch to authenticate the illegal access device. For example, the 802.1X authentication method cannot identify or prevent IP spoofing (such as an attacker forging a legal IP address to send a data packet), causing the authentication server to authenticate the illegal access device.

[0072] In this regard, the embodiment of the present application can implement multi-faceted security authentication of the first roadside device based on device information of different dimensions, thereby increasing the three-layer network security protection, avoiding the situation where the device information of illegally accessed devices is forged, and improving the reliability of security authentication.

[0073] In a specific implementation, the device information of the first roadside device and the second roadside device includes at least the device type, device model, device serial number, MAC address and IP address. The edge node can match the device type of the first roadside device with the device type of each second roadside device in the edge database, and can match the device model of the first roadside device with the device model of each second roadside device in the edge database, and can match the device serial number of the first roadside device with the device serial number of each second roadside device in the edge database, and can match the MAC address of the first roadside device with the MAC address of each second roadside device in the edge database, and can match the IP address of the first roadside device with the IP address of each second roadside device in the edge database, so as to comprehensively combine the matching results of the five types of device information to determine whether the first roadside device has passed the security authentication.

[0074] If the device type of the first roadside device does not match the device type of any second roadside device, and / or the device model of the first roadside device does not match the device model of any second roadside device, and / or the device serial number of the first roadside device does not match the device serial number of any second roadside device, and / or the MAC address of the first roadside device does not match the MAC address of any second roadside device, and / or the IP address of the first roadside device does not match the IP address of any second roadside device, then it can be determined that the device information of the first roadside device does not match the device information of any second roadside device, indicating that the first roadside device is not the second roadside device, and therefore it can be determined that the first roadside device has not passed the security authentication.

[0075] If the device type of the first roadside device matches the device type of the target roadside device, and the device model of the first roadside device matches the device model of the target roadside device, and the device serial number of the first roadside device matches the device serial number of the target roadside device, and the MAC address of the first roadside device matches the MAC address of the target roadside device, and the IP address of the first roadside device matches the IP address of the target roadside device, then it can be determined that the device information of the first roadside device matches the device information of the target roadside device, wherein the target roadside device is one of the second roadside devices, which means that the first roadside device is the second roadside device, and therefore it can be determined that the first roadside device has passed the security authentication.

[0076] That is to say, all five types of device information must match in order to determine that the first roadside device has passed the security authentication. In this way, even if the MAC address of the first roadside device is tampered with so that the MAC address of the first roadside device matches the MAC of one of the second roadside devices, the edge node can also determine that the first roadside device has not passed the security authentication based on device type mismatch, and / or device model mismatch, and / or device serial number mismatch, and / or IP address mismatch.

[0077] In addition, the embodiment of the present application can also determine whether the first roadside device has passed the security authentication based solely on the matching results of the device serial number and the MAC address. Specifically, the edge node can match the device serial number of the first roadside device with the device serial number of each second roadside device in the edge database, and can match the MAC address of the first roadside device with the MAC address of each second roadside device in the edge database. If the device serial number of the first roadside device does not match the device serial number of any second roadside device, and / or the MAC address of the first roadside device does not match the MAC address of any second roadside device, it can be determined that the device information of the first roadside device does not match the device information of any second roadside device, indicating that the first roadside device is not the second roadside device, and therefore it can be determined that the first roadside device has not passed the security authentication. If the device serial number of the first roadside device matches the device serial number of the target roadside device, and the MAC address of the first roadside device matches the MAC address of the target roadside device, it can be determined that the device information of the first roadside device matches the device information of the target roadside device, wherein the target roadside device is one of the second roadside devices, which means that the first roadside device is the second roadside device, and therefore it can be determined that the first roadside device has passed the security authentication.

[0078] In other words, the device serial number and MAC address are necessary comparison parameters. Both types of device information must match in order to determine that the first roadside device has passed the security authentication. In this way, even if the MAC address of the first roadside device is tampered with, so that the MAC address of the first roadside device matches the MAC address of one of the second roadside devices, the edge node can also determine that the first roadside device has not passed the security authentication based on the mismatch of the device serial number.

[0079] In order to minimize the possibility of device information of illegally accessed devices being forged, the preferred solution of the embodiment of the present application is that all five types of device information must match before it can be determined that the first roadside device has passed the security authentication.

[0080] After completing the security authentication of the first roadside device, if the first roadside device fails the security authentication, proceed to step S330; if the first roadside device passes the security authentication, proceed to step S340.

[0081] S330: If the first roadside device fails the security authentication, the first roadside device is determined to be an illegal access device, and the illegal access device is denied access to the roadside network.

[0082] like Figure 4 As shown, the "system management" part of the central node covers multiple management functions, including but not limited to: version distribution, full network topology, device management and policy management. Among them, the policy management function means that the central node distributes multiple control strategies to each edge node in advance, so that the "device control" part of each edge node covers multiple control strategies, including but not limited to: release strategy, blocking strategy, and switch management.

[0083] If the first roadside device is determined to have failed security authentication, the edge node may identify the first roadside device as an unauthorized access device. The edge node may implement a blocking strategy for unauthorized access devices. Specifically, the edge node may use the Layer 2 control function of the switch at the intersection to block the network port corresponding to the unauthorized access device, thereby preventing the unauthorized access device from accessing the roadside network at the intersection.

[0084] In a specific implementation, the edge node can automatically log in to the switch at the intersection, and then block the network port corresponding to the illegal access device through the switch's port Layer 2 access control list, thereby denying the illegal access device access to the roadside network at the intersection.

[0085] Compared with related technologies that require operation and maintenance personnel to manually log in to the switch to implement port blocking, the embodiments of the present application can implement automated port blocking, thereby further improving deployment efficiency and reducing deployment costs.

[0086] In one embodiment, after denying access to the roadside network to the illegal access device, the method may further include: A first detection result is generated for an illegal access device; the first detection result includes at least one of the port information of the illegal access device in the switch and the device information of the illegal access device; the first detection result is uploaded to the central node, so that the central node generates and pushes an alarm message to the user for the first detection result; the alarm message is used to prompt the user to verify the illegal access device; an adjustment instruction issued by the central node is received; the adjustment instruction is triggered when the user verifies that the illegal access device belongs to a special access device; the special access device includes at least one of a newly replaced second roadside device and a terminal device for debugging the second roadside device; in response to the adjustment instruction, the illegal access device is adjusted to a legal access device, and the legal access device is allowed to access the roadside network, and the device information of the legal access device is stored in the edge database.

[0087] like Figure 4As shown, the "data reporting" part of the edge node covers multiple reporting methods, including but not limited to: network topology and illegal access, where illegal access means that the edge node reports the illegal access of the first roadside device to the central node to trigger the alarm function of the "alarm management" part of the central node and / or the device management function of the "system management" part.

[0088] In a specific implementation, the edge node can detect the port information of the illegally accessed device in the switch through port detection or SDK detection. The port information is used to identify the port location of the switch where the illegally accessed device is located. As previously described, if the first roadside device and the second roadside device are of the same device type and manufactured by the same manufacturer, the SDK module can detect the device information of the first roadside device. Otherwise, the device information of the first roadside device cannot be detected. Therefore, when the SDK module detects the device information of the illegally accessed device (i.e., the first roadside device), the edge node can use both the port information of the illegally accessed device in the switch and the device information of the illegally accessed device to generate a first detection result. If the SDK module cannot detect the device information of the illegally accessed device (i.e., the first roadside device), the edge node can use only the port information of the illegally accessed device in the switch to generate the first detection result.

[0089] The first detection result is used to characterize that the first roadside device is an illegally accessed device, and the edge node uploads the first detection result to the central node.

[0090] It should be noted that the edge node can first block the port of the illegally accessed device and then upload the first detection result, or it can only upload the first detection result without blocking the port of the illegally accessed device, so as to subsequently determine whether to block the port of the illegally accessed device based on the processing result of the central node.

[0091] The "alarm management" section of the central node covers a variety of alarm parameters, including but not limited to: alarm personnel, alarm level, alarm information and alarm email. Therefore, after receiving the first detection result of the edge node, the central node can generate alarm information for the first detection result, and then push the alarm information to the user (such as operation and maintenance personnel) through SMS or email, so as to notify the user (such as operation and maintenance personnel) to verify the illegally accessed device in time.

[0092] The illegal access device may be a terminal device used by an attacker, a roadside device newly replaced by the operation and maintenance personnel, or a terminal device used by the operation and maintenance personnel. Therefore, after receiving the alarm information, the operation and maintenance personnel can verify whether the illegal access device is a special access device. The special access device may include at least one of the newly replaced second roadside device and the terminal device used to debug the second roadside device.

[0093] In one example, assuming that a second roadside device previously connected to the roadside network is severely damaged, the operation and maintenance personnel replace the damaged second roadside device with a new second roadside device. Since the device information of the newly replaced second roadside device is not added to the central database and the edge database in a timely manner, the newly replaced second roadside device is determined by the edge node as an illegal access device when it is used as the first roadside device. In this regard, the embodiment of the present application can push alarm information to the operation and maintenance personnel so that when the operation and maintenance personnel verify that the illegal access device is actually the newly replaced second roadside device, they can perform adjustment operations in the visual interface. The central node generates an adjustment instruction in response to the adjustment operation, and then sends the adjustment instruction to the edge node, so that the edge node responds to the adjustment instruction and adjusts the first roadside device from an illegal access device to a legal access device. Since the first roadside device is already a legal access device, the edge node can allow the first roadside device to access the roadside network.

[0094] In another example, assume that a second roadside device connected to the roadside network experiences a problem but is not yet scrapped. Therefore, an operator may use terminal device X (such as a computer) to debug the second roadside device. During the debugging process, terminal device X used by the operator needs to temporarily access the roadside network. Because the device information of terminal device X is not in the central database or the edge database, terminal device X, when acting as the first roadside device, is determined by the edge node to be an illegally accessed device. In response to this, an embodiment of the present application can push an alarm message to the operator so that, upon verifying that the illegally accessed device is actually terminal device X used to debug the second roadside device, the operator can perform an adjustment operation in a visual interface. In response to the adjustment operation, the central node generates an adjustment instruction and then issues the adjustment instruction to the edge node. The edge node, in response to the adjustment instruction, adjusts the first roadside device from an illegally accessed device to a legally accessed device. Since the first roadside device is now a legally accessed device, the edge node can allow the first roadside device to access the roadside network.

[0095] In another example, suppose an attacker forges the MAC address of terminal device Y and connects to the switch, but the edge node determines that terminal device Y is an illegally accessed device when it is the first roadside device based on device type mismatch, and / or device model mismatch, and / or device serial number mismatch, and / or IP address mismatch. In this regard, the embodiment of the present application can push an alarm message to the operation and maintenance personnel so that when the operation and maintenance personnel verify that the illegally accessed device is neither the newly replaced second roadside device nor the terminal device X used to debug the second roadside device, there is no need to trigger an adjustment operation. In this way, the first roadside device is still an illegally accessed device and continues to be denied access to the roadside network.

[0096] It should be noted that if the edge node only uploads the first detection result and does not block the port of the first roadside device, then when the edge node has not received the adjustment instruction from the central node after waiting for the preset time, it determines to block the port of the illegally accessed device, so that the illegally accessed device is denied access to the roadside network.

[0097] It should be noted that when the illegally accessed device is a special access device, the central node can trigger the device management function in the "System Management" section. In a specific implementation, if the first detection result carries the device information of the special access device (i.e., the first roadside device), the central node can add the device information to the central database, and the edge node can add the device information to the edge database. If the first detection result does not carry the device information of the special access device (i.e., the first roadside device), the central node can obtain the device information of the special access device. For example, if the special access device is a newly replaced second roadside device, the central node can obtain the device list information provided by the corresponding manufacturer, or the operation and maintenance personnel can perform an add operation in the visual interface to enable the central node to obtain the device information of the newly replaced second roadside device. If the special access device is terminal device X used to debug the second roadside device, the operation and maintenance personnel can perform an add operation in the visual interface to enable the central node to obtain the device information of terminal device X. The central node then adds the device information to the central database, and the edge node can add the device information to the edge database.

[0098] S340: If the first roadside device passes the security authentication, the first roadside device is determined to be a legal access device, and the legal access device is allowed to access the roadside network.

[0099] If the first roadside device passes security authentication, the edge node can identify the first roadside device as a legitimate access device. For legitimate access devices, the edge node can adopt a release policy, meaning the edge node does not block the network port corresponding to the legitimate access device, allowing the legitimate access device to access the roadside network at the intersection.

[0100] In one embodiment, after allowing the legal access device to access the roadside network, the method may further include: Generate a second detection result for the legal access device; the second detection result includes the port information of the legal access device in the switch and the status information of the legal access device; upload the second detection result to the central node so that the central node adds the port information and status information in the second detection result to its own central database.

[0101] like Figure 4As shown, the "data reporting" part of the edge node covers multiple reporting methods, including but not limited to: network topology and illegal access. Among them, network topology refers to the edge node reporting the port location of the switch where the legal access device is located and the status information of the legal access device to the central node to form a network topology architecture, so as to trigger the full network topology function of the "system management" part of the central node.

[0102] In a specific implementation, the edge node can detect the port information of the legal access device in the switch through port detection or SDK detection, and detect the status information of the legal access device through ping detection, port detection or SDK detection. The port information is used to indicate the port location of the switch where the legal access device is located, and the status information is used to indicate whether the legal access device is online or offline. Since the legal access device is actually a second roadside device, the device information of the legal access device is already stored in the central database. Therefore, the edge node can only use the port information of the legal access device in the switch and the status information of the legal access device to generate the second detection result.

[0103] The second detection result is used to indicate that the first roadside device is a legal access device, and the edge node uploads the second detection result to the central node.

[0104] After receiving the second detection result from the edge node, the central node can trigger the full network topology function in the "System Management" section of the central node. In specific implementations, the central node adds the port information and status information from the second detection result to the central database to supplement the missing port information and status information in the central database. The central node can form a full network topology map of the device, port information, and status information of all legal access devices connected to the roadside network at each intersection, thereby monitoring the online and offline status of each legal access device at each intersection.

[0105] As can be seen from this example, the solution provided by this application has at least the following advantages: 1. Automated offline deployment capabilities: 1. The roadside deployment system consists of two parts: a central node and edge nodes. The central node automatically generates project information based on multiple device information lists provided by different manufacturers, eliminating the need for manual configuration. This significantly reduces the time and manpower required for manual configuration, thereby improving deployment efficiency and reducing deployment costs.

[0106] 2. When the edge node and the central node are in communication connection, the central node sends the project information to the edge database of the edge node in advance for storage. In this way, even if there is a disconnection between the roadside network and the core network, since the edge database already contains the project information, the edge node can use the project information in the edge database to perform security authentication on the first roadside device requesting to connect to the roadside network, thereby ensuring normal usage needs.

[0107] 3. The edge node is close to the data source. Therefore, when the first roadside device fails to pass the security authentication, the edge node can immediately deny the first roadside device from accessing the roadside network, thereby reducing the security risk of the roadside network.

[0108] 2. Flexible deployment architecture selection: 1. The roadside deployment system consists of two parts: the central node and the edge node. The standard deployment method is to deploy the central node in the security management area or server area of ​​the core network, and the edge node in the MEC of the roadside network at the intersection.

[0109] 2. Some projects can combine the central node and edge nodes of the roadside deployment system into one according to actual needs and deploy them uniformly in the core network.

[0110] 3. In smaller-scale vehicle-road cloud projects, such as those that only include a few intersections and have no central system server resources, it is possible to deploy only edge nodes, and mounting corresponding alarm modules in the edge nodes can also realize the alarm function of the central node.

[0111] 3. Multi-architecture support: 1. Compatible with two mainstream hardware architectures: amd64 and arm64.

[0112] 2. Supports mixed deployment of servers with different architectures, improving resource utilization efficiency and flexibility.

[0113] 4. Highly customized configuration: 1. The second roadside equipment used in different projects has different manufacturers and equipment types. During the first phase of the project, the central node can integrate multiple SDK resource packages provided by different manufacturers into an SDK module, and then encapsulate the SDK module into a Docker image so that the Docker image can be distributed to the edge node. The Docker image has the advantage of being lightweight, so it can reduce the system size of the edge node.

[0114] 2. During the second phase of the project, if a second roadside device from a new manufacturer and / or a new device type is used, the central node can use the new SDK resource package to update the previous SDK module, and then encapsulate the updated SDK module into a Docker image so that the Docker image can be sent to the edge node again to achieve an image upgrade for the edge node.

[0115] 5. Simplified deployment process: 1. Through Docker deployment, after running the Docker image, the edge node can use the SDK module to automatically detect all the first roadside devices in the local area network of the IP network segment where the MEC is located (that is, the roadside network at the intersection).

[0116] 2. When running the Docker image, you can also specify the corresponding IP address segment by adding additional parameters to complete the detection of the specified segment.

[0117] 6. Efficient management and monitoring: 1. It can periodically detect the information of legal access devices in the entire LAN (such as port information, status information), and notify the detection results (i.e., the second detection results) to the central node to form a network topology architecture of the device.

[0118] 2. Provide an alarm and notification mechanism to promptly detect illegal access devices and notify the central node, which will then notify relevant personnel through the alarm module of the central node.

[0119] Figure 5 This is another flowchart illustrating a method for deploying roadside equipment according to an embodiment of the present application. Steps S510 to S530 may be performed by a central node, wherein the central node is in communication with an edge node, the central node being deployed in the core network, and the edge node being deployed in the MEC of the roadside network.

[0120] See also Figure 5 The roadside equipment deployment method of the present application includes: S510: Obtain multiple device information lists provided by different manufacturers.

[0121] This step can refer to the description of the above-mentioned step S110 or step S310, and will not be repeated here.

[0122] S520: Generate project information based on multiple equipment information lists.

[0123] This step can refer to the description of the above-mentioned step S110 or step S310, and will not be repeated here.

[0124] S530: Send the project information to the edge node, so that the edge node uses the project information to perform security authentication on the first roadside device connected to the switch in the roadside network.

[0125] This step can refer to the description of the above-mentioned step S110 or step S310, and will not be repeated here.

[0126] In one embodiment, after generating project information based on the plurality of equipment information lists, the method may further include: Store project information in its own central database.

[0127] This step can refer to the description of the above-mentioned step S110 or step S310, and will not be repeated here.

[0128] In one embodiment, the project information is stored by the edge node in its own edge database, and the project information includes device information of each second roadside device; the method may further include: Obtain multiple SDK resource packages provided by different manufacturers; integrate SDK modules based on multiple SDK resource packages; encapsulate the SDK modules into a Docker image; and send the Docker image to the edge node, so that the edge node runs the Docker image when detecting that a first roadside device is connected to a switch in the roadside network, so that the edge node detects the device information of the first roadside device through the SDK module in the Docker image, and then determines that the first roadside device has not passed the security authentication when the device information of the first roadside device does not match the device information of any second roadside device, or determines that the first roadside device has not passed the security authentication when the SDK module cannot detect the device information of the first roadside device.

[0129] This step can refer to the description of the sub-step of "When it is detected that a first roadside device is connected to a switch in the roadside network, the project information in the edge database is used to perform security authentication on the first roadside device" in the above-mentioned step S320, which will not be repeated here.

[0130] In one embodiment, after integrating SDK modules based on multiple SDK resource packages, the method may further include: Store the SDK module in its own SDK module library.

[0131] This step can refer to the description of the sub-step of "When it is detected that a first roadside device is connected to a switch in the roadside network, the project information in the edge database is used to perform security authentication on the first roadside device" in the above-mentioned step S320, which will not be repeated here.

[0132] In one embodiment, the device information includes device type, device model, device serial number, MAC address, and IP address.

[0133] In one embodiment, the method may further include: Receive a first detection result uploaded by an edge node; the first detection result is used to characterize that the edge node determines that the first roadside device is an illegal access device when the first roadside device fails to pass security authentication, and the illegal access device is denied access to the roadside network by the edge node, and the first detection result includes at least one of the port information of the illegal access device in the switch and the device information of the illegal access device; generate and push an alarm message to the user based on the first detection result; the alarm information is used to prompt the user to verify the illegal access device; receive an adjustment instruction triggered when the user verifies that the illegal access device belongs to a special access device; wherein the special access device includes at least one of a newly replaced second roadside device and a terminal device for debugging the second roadside device; send the adjustment instruction to the edge node, so that the edge node responds to the adjustment instruction, adjusts the illegal access device to a legal access device, and then enables the edge node to store the device information of the legal access device in the edge database, wherein the legal access device is allowed to access the roadside network by the edge node.

[0134] This step can refer to the description of the extended step of "after denying illegal access devices from accessing the roadside network" in the above step S330, and will not be repeated here.

[0135] In one embodiment, when the illegally accessed device is a special access device, the method may further include: The device information of the special access device is stored in the central database.

[0136] If the SDK module can detect the device information of the first roadside device, then after determining that the illegal access device (ie, the first roadside device) is a special access device, the device information of the special access device (ie, the first roadside device) can be stored in the central database.

[0137] In one embodiment, the method may further include: Receive a second detection result uploaded by the edge node; the second detection result is used to characterize that the edge node determines that the first roadside device is a legal access device when the first roadside device passes security authentication, and the legal access device is allowed by the edge node to access the roadside network. The second detection result includes the port information of the legal access device in the switch and the status information of the legal access device; the port information and status information in the second detection result are added to the central database.

[0138] This step can refer to the description of the extended step of "after allowing the legal access device to access the roadside network" in the above-mentioned step S340, and will not be repeated here.

[0139] As can be seen from this example, the solution provided by the present application automatically generates project information through a central node based on multiple device information lists provided by different manufacturers. Therefore, there is no need for manual configuration by the user, which greatly reduces the time and manpower consumed by manual configuration, thereby improving deployment efficiency and reducing deployment costs; further, by sending the project information generated by the central node to the edge database of the edge node in advance for storage when the edge node and the central node are in communication connection, even if there is a disconnection between the roadside network and the core network, since the edge database already contains the project information, the edge node can use the project information in the edge database to perform security authentication on the first roadside device requesting to connect to the roadside network, thereby ensuring normal usage needs; further, since the edge node is close to the data source, the edge node can immediately refuse the first roadside device from accessing the roadside network when the first roadside device fails the security authentication, thereby reducing the security risk of the roadside network.

[0140] Corresponding to the aforementioned application function implementation method embodiment, the present application also provides a roadside equipment deployment system, electronic equipment and corresponding embodiments.

[0141] Figure 6 It is a structural diagram of the roadside equipment deployment system shown in an embodiment of the present application.

[0142] See also Figure 6 The present application provides a roadside equipment deployment system 60, which may include: a central node 61 and an edge node 62, wherein the central node 61 is in communication with the edge node 62, the central node 61 is deployed in the core network, and the edge node 62 is deployed in the MEC of the roadside network; wherein, The central node 61 is used to obtain multiple device information lists provided by different manufacturers; generate project information based on the multiple device information lists; and send the project information to the edge nodes; The edge node 62 is used to store the project information sent by the central node in its own edge database; when it is detected that a first roadside device is connected to a switch in the roadside network, the project information in the edge database is used to perform security authentication on the first roadside device; if the first roadside device fails the security authentication, the first roadside device is determined to be an illegally accessed device, and the illegally accessed device is denied access to the roadside network.

[0143] The specific structure of the central node 61 can be found in Figure 7 The specific structure of edge node 62 can be found in Figure 8 .

[0144] See also Figure 7 The central node 61 may include a device information list acquisition module 710, a project information generation module 720, and a project information delivery module 730, wherein: The device information list acquisition module 710 is used to acquire multiple device information lists provided by different manufacturers; A project information generating module 720 is configured to generate project information based on multiple equipment information lists; The project information sending module 730 is used to send the project information to the edge node, so that the edge node uses the project information to perform security authentication on the first roadside device connected to the switch in the roadside network.

[0145] In one embodiment, after generating the project information based on the multiple device information lists, the central node 61 may further include: The project information storage module is used to store project information in its own central database.

[0146] In one embodiment, the project information is stored by the edge node in its own edge database, and the project information includes device information of each second roadside device; the central node 61 may also include: SDK resource package acquisition module, used to obtain various SDK resource packages provided by different manufacturers; SDK integration module, used to integrate SDK modules based on multiple SDK resource packages; SDK packaging module, used to package SDK modules into Docker images; The SDK sending module is used to send the Docker image to the edge node, so that the edge node runs the Docker image when it detects that the first roadside device is connected to the switch in the roadside network, so that the edge node can detect the device information of the first roadside device through the SDK module in the Docker image, and then the edge node determines that the first roadside device has not passed the security authentication when the device information of the first roadside device does not match the device information of any second roadside device, or determines that the first roadside device has not passed the security authentication when the SDK module cannot detect the device information of the first roadside device.

[0147] In one embodiment, after integrating SDK modules based on multiple SDK resource packages, the central node 61 may further include: The SDK storage module is used to store SDK modules in its own SDK module library.

[0148] In one embodiment, the device information includes device type, device model, device serial number, MAC address, and IP address.

[0149] In one embodiment, the central node 61 may further include: A first detection result receiving module is configured to receive a first detection result uploaded by an edge node; the first detection result is configured to indicate that the edge node determines that the first roadside device is an illegal access device when the first roadside device fails security authentication, and that the illegal access device is denied access to the roadside network by the edge node, the first detection result including at least one of port information of the illegal access device in a switch and device information of the illegal access device; An alarm module is used to generate and push an alarm message to the user based on the first detection result; the alarm message is used to prompt the user to verify the illegally accessed device; an adjustment instruction receiving module, configured to receive an adjustment instruction triggered when a user verifies that the illegally accessed device is a special access device; the special access device includes at least one of a newly replaced second roadside device and a terminal device used to debug the second roadside device; The adjustment instruction sending module is used to send the adjustment instruction to the edge node, so that the edge node responds to the adjustment instruction and adjusts the illegal access device to a legal access device, and then the edge node stores the device information of the legal access device in the edge database, wherein the legal access device is allowed by the edge node to access the roadside network.

[0150] In one embodiment, the central node 61 may further include: The new device information storage module is used to store the device information of special access devices in the central database.

[0151] In one embodiment, the central node 61 may further include: A second detection result receiving module is configured to receive a second detection result uploaded by the edge node; the second detection result is used to indicate that the edge node determines that the first roadside device is a legal access device when the first roadside device passes security authentication, and that the legal access device is allowed to access the roadside network by the edge node, and the second detection result includes port information of the legal access device in the switch and status information of the legal access device; The supplementing module is used to add the port information and status information in the second detection result to the central database.

[0152] See also Figure 8 , the edge node 62 may include a project information storage module 810, a security authentication module 820 and an access denial module 830, wherein: The project information storage module 810 is used to store the project information issued by the central node in its own edge database; the project information is generated by the central node based on multiple equipment information lists provided by different manufacturers; The security authentication module 820 is configured to, upon detecting that a first roadside device is connected to a switch in the roadside network, perform security authentication on the first roadside device using the project information in the edge database; The access rejection module 830 is configured to determine the first roadside device as an illegal access device if the first roadside device fails security authentication, and reject the illegal access device from accessing the roadside network.

[0153] In one embodiment, the project information includes device information of each second roadside device; the security authentication module 820 may include: The Docker image running submodule is used to run the Docker image when it is detected that a first roadside device is connected to a switch in the roadside network; the Docker image includes an SDK module, which is obtained by integrating a central node based on multiple SDK resource packages provided by different manufacturers; A device information detection submodule, configured to detect device information of the first roadside device through the SDK module; a device information matching submodule, configured to match the device information of the first roadside device with the device information of each second roadside device in the edge database; The first determination submodule for failure to pass security authentication is configured to determine that the first roadside device has failed security authentication if the device information of the first roadside device does not match the device information of any second roadside device.

[0154] In one embodiment, the security authentication module 820 may further include: The second determination submodule for failure to pass security authentication is configured to determine that the first roadside device has failed to pass security authentication when the SDK module cannot detect device information of the first roadside device.

[0155] In one embodiment, the device information includes device type, device model, device serial number, MAC address, and IP address; the device information matching submodule may include: a device type matching unit, configured to match the device type of the first roadside device with the device type of each second roadside device in the edge database, and a device model matching unit, configured to match the device model of the first roadside device with the device model of each second roadside device in the edge database, and a device serial number matching unit, configured to match the device serial number of the first roadside device with the device serial numbers of each second roadside device in the edge database, and a MAC address matching unit, configured to match the MAC address of the first roadside device with the MAC address of each second roadside device in the edge database, and An IP address matching unit, configured to match the IP address of the first roadside device with the IP addresses of each second roadside device in the edge database; A device information mismatch determination unit is used for a device type matching unit, and is used to determine that the device information of the first roadside device does not match the device information of any second roadside device if the device type of the first roadside device does not match the device type of any second roadside device, and / or the device model of the first roadside device does not match the device model of any second roadside device, and / or the device serial number of the first roadside device does not match the device serial number of any second roadside device, and / or the MAC address of the first roadside device does not match the MAC address of any second roadside device, and / or the IP address of the first roadside device does not match the IP address of any second roadside device.

[0156] In one embodiment, the edge node 62 may further include: The access permission module is used to determine the first roadside device as a legal access device if the first roadside device passes the security authentication, and to allow the legal access device to access the roadside network.

[0157] In one embodiment, after denying access to the roadside network to the illegal access device, the edge node 62 may further include: A first detection result generating module is configured to generate a first detection result for an illegally accessed device; the first detection result includes at least one of port information of the illegally accessed device in the switch and device information of the illegally accessed device; A first detection result uploading module is used to upload the first detection result to the central node, so that the central node generates and pushes an alarm message to the user based on the first detection result; the alarm message is used to prompt the user to verify the illegally accessed device; An adjustment instruction receiving module is configured to receive an adjustment instruction issued by a central node; the adjustment instruction is triggered when a user verifies that an illegally accessed device is a special access device; the special access device includes at least one of a newly replaced second roadside device and a terminal device used to debug the second roadside device; The adjustment instruction response module is used to adjust the illegal access device to a legal access device in response to the adjustment instruction, allow the legal access device to access the roadside network, and store the device information of the legal access device in the edge database.

[0158] In one embodiment, after allowing the legal access device to access the roadside network, the edge node 62 may further include: A second detection result generating module is used to generate a second detection result for the legal access device; the second detection result includes port information of the legal access device in the switch and status information of the legal access device; The second detection result uploading module is used to upload the second detection result to the central node, so that the central node adds the port information and status information in the second detection result to its own central database.

[0159] Regarding the system in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated again here.

[0160] Figure 9 It is a structural diagram of an electronic device shown in an embodiment of the present application.

[0161] See also Figure 9 , the electronic device 900 includes a memory 910 and a processor 920 .

[0162] The processor 920 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor. Memory 910 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage. ROM may store static data or instructions required by processor 920 or other computer modules. Permanent storage may be a readable and writable storage device. Permanent storage may be a non-volatile storage device that retains stored instructions and data even when the computer is powered off. In some embodiments, the permanent storage device utilizes a mass storage device (e.g., a magnetic or optical disk, flash memory). In other embodiments, the permanent storage device may be a removable storage device (e.g., a floppy disk, optical drive). System memory may be a readable and writable storage device or a volatile readable and writable storage device, such as dynamic random access memory (DRAM). System memory may store some or all instructions and data required by the processor during operation. Furthermore, memory 910 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), as well as magnetic disks and / or optical disks. In some embodiments, the memory 910 may include a readable and / or writable removable storage device, such as a compact disc (CD), a read-only digital versatile disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not include carrier waves and transient electronic signals transmitted wirelessly or wired.

[0163] The memory 910 stores executable codes. When the executable codes are processed by the processor 920 , the processor 920 may execute part or all of the above-mentioned methods.

[0164] In addition, the method according to the present application may also be implemented as a computer program or a computer program product, which includes computer program code instructions for executing some or all of the steps in the above method of the present application.

[0165] Alternatively, the present application can also be implemented as a computer-readable storage medium (or non-transitory machine-readable storage medium or machine-readable storage medium), which stores executable code (or computer program or computer instruction code) and, when executed by a processor of an electronic device (or server, etc.), enables the processor to perform part or all of the steps of the above-mentioned method according to the present application.

[0166] The present application also provides a computer program product, which includes computer instructions, and when the computer instructions are executed by a processor, the method described above is implemented.

[0167] The embodiments of the present application have been described above. The above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to the technology in the market, or to enable other persons skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for deploying roadside equipment, characterized in that: Applied to an edge node, the edge node is communicatively connected to a central node, the edge node is deployed in an MEC of a roadside network, and the central node is deployed in a core network, the method comprising: The project information sent by the central node is stored in its own edge database; the project information is generated by the central node based on multiple equipment information lists provided by different manufacturers; When detecting that a first roadside device is connected to a switch in the roadside network, performing security authentication on the first roadside device using the project information in the edge database; If the first roadside device fails the security authentication, the first roadside device is determined to be an illegal access device, and the illegal access device is denied access to the roadside network.

2. The method according to claim 1, characterized in that The project information includes device information of each second roadside device; when detecting that a first roadside device is connected to a switch in the roadside network, using the project information in the edge database to perform security authentication on the first roadside device, including: When detecting that a first roadside device is connected to a switch in the roadside network, running a Docker image; the Docker image includes an SDK module, the SDK module being obtained by the central node based on integration of multiple SDK resource packages provided by different manufacturers; Detecting device information of the first roadside device through the SDK module; Matching the device information of the first roadside device with the device information of each second roadside device in the edge database; If the device information of the first roadside device does not match the device information of any of the second roadside devices, it is determined that the first roadside device has failed the security authentication.

3. The method according to claim 2, characterized in that The method further comprises: When the SDK module cannot detect the device information of the first roadside device, it is determined that the first roadside device has failed security authentication.

4. The method according to claim 2, characterized in that The device information includes device type, device model, device serial number, MAC address and IP address; the matching of the device information of the first roadside device with the device information of each second roadside device in the edge database includes: Matching the device type of the first roadside device with the device type of each second roadside device in the edge database, and matching the device model of the first roadside device with the device model of each second roadside device in the edge database, and matching the device serial number of the first roadside device with the device serial number of each second roadside device in the edge database, and matching the MAC address of the first roadside device with the MAC address of each second roadside device in the edge database, and matching the IP address of the first roadside device with the IP address of each second roadside device in the edge database; If the device type of the first roadside device does not match the device type of any of the second roadside devices, and / or the device model of the first roadside device does not match the device model of any of the second roadside devices, and / or the device serial number of the first roadside device does not match the device serial number of any of the second roadside devices, and / or the MAC address of the first roadside device does not match the MAC address of any of the second roadside devices, and / or the IP address of the first roadside device does not match the IP address of any of the second roadside devices, then it is determined that the device information of the first roadside device does not match the device information of any of the second roadside devices.

5. The method according to claim 1, wherein The method further comprises: If the first roadside device passes the security authentication, the first roadside device is determined as a legal access device, and the legal access device is allowed to access the roadside network.

6. The method according to claim 1, wherein After denying the illegal access device access to the roadside network, the method further includes: Generate a first detection result for the illegally accessed device; the first detection result includes at least one of port information of the illegally accessed device in the switch and device information of the illegally accessed device; Uploading the first detection result to the central node, so that the central node generates and pushes an alarm message to the user based on the first detection result; the alarm message is used to prompt the user to verify the illegally accessed device; receiving an adjustment instruction issued by the central node; the adjustment instruction is triggered when the user verifies that the illegal access device is a special access device; the special access device includes at least one of a newly replaced second roadside device and a terminal device used to debug the second roadside device; In response to the adjustment instruction, the illegal access device is adjusted to a legal access device, the legal access device is allowed to access the roadside network, and the device information of the legal access device is stored in the edge database.

7. The method according to claim 5 or 6, characterized in that After allowing the legal access device to access the roadside network, the method further includes: Generate a second detection result for the legal access device; the second detection result includes port information of the legal access device in the switch and status information of the legal access device; The second detection result is uploaded to the central node, so that the central node adds the port information and the status information in the second detection result to its own central database.

8. A method for deploying roadside equipment, characterized in that: Applied to a central node, the central node is communicatively connected to an edge node, the central node is deployed in a core network, and the edge node is deployed in an MEC of a roadside network, the method comprising: Get multiple device information lists provided by different manufacturers; generating project information based on the plurality of equipment information lists; The project information is sent to the edge node, so that the edge node uses the project information to perform security authentication on a first roadside device connected to a switch in the roadside network.

9. A roadside equipment deployment system, characterized in that: The system includes: a central node and an edge node, wherein the central node is in communication connection with the edge node, the central node is deployed in the core network, and the edge node is deployed in the MEC of the roadside network; wherein, The central node is configured to obtain multiple device information lists provided by different manufacturers; generate project information based on the multiple device information lists; and send the project information to the edge node; The edge node is used to store the project information sent by the central node in its own edge database; when it is detected that a first roadside device is connected to a switch in the roadside network, the project information in the edge database is used to perform security authentication on the first roadside device; if the first roadside device fails the security authentication, the first roadside device is determined to be an illegally accessed device, and the illegally accessed device is denied access to the roadside network.

10. An electronic device, characterized in that: include: processor; as well as A memory having executable codes stored thereon, which, when executed by the processor, causes the processor to execute the method according to any one of claims 1 to 7 or claim 8.

Images