KR20220170507A - Clustered Stationary Vehicles-based Vehicular Networking and Computing System - Google Patents

Abstract

The present invention relates to a vehicle networking and computing system based on platooned vehicles. In vehicular networks, including autonomous driving, edge computing based on information-centric microservices and fog computing based on stationary vehicles are integrated to enable mutual cooperation between computing layers to distribute a computational load. According to the vehicle networking and computing system based on platooned vehicles according to the present invention, in vehicular networks based on information-centric networks, microservice-based in-network computing is possible. By integrating edge computing, which performs communication and computational load balancing between multiple computing layers, and fog computing based on platooned vehicles into a single framework, mutual cooperation between multiple computing layers is enabled. Thus, it is possible to take advantage of the potential benefits of computation in proximity to consumer vehicles.

Description

Clustered Stationary Vehicles-based 　 Vehicular Networking and Computing System}

The present invention relates to a vehicle networking and computing system, and more particularly, to integrating edge computing based on information-centric microservices and fog computing based on stopped vehicles in a vehicle network including autonomous driving, thereby providing inter-computing layers. A vehicle networking and computing system based on platooning vehicles capable of distributing computational load by enabling mutual cooperation.

With the development of mobile devices and high-performance networks, traffic that can be distinguished as contents such as multimedia has increased in networks. Due to these changes in Internet traffic patterns, limitations and problems of the current TCP/IP network have arisen, and new future Internet structures are being studied.

Among them, the most promising future Internet structure is the Information Centric Network (hereinafter abbreviated as "ICN"), and one of the implementation technologies of this ICN is Named Data Networking (hereinafter abbreviated as "NDN"). to be. ICN or NDN is a technology for transmitting data to a destination using only content information and a router function in a network, and is considered as a future Internet architecture to replace the existing Internet transport network based on servers and IP addresses.

On the other hand, edge computing is in the limelight as a new internet paradigm. Edge computing is a technology that processes data at the edge where data is generated rather than at the central server. As the amount of data transmitted increases due to the spread of (Internet of Things) devices, the limit of cloud computing, which processes all data in a central server, is revealed, and the edge computing method is attracting attention. Using the edge computing method, it is possible to reduce the time required to deliver data to the central server, analyze it, and process the results by distributing and processing data around IoT terminals.

Recently, an intelligent vehicle network using edge computing has been developed. However, in a general edge-based intelligent vehicle network, support for ICN/NDN-based communication is insufficient, and thus, problems such as long backhaul delay, high bandwidth consumption, and network congestion in the computing domain are faced. Furthermore, since these tasks do not integrate stationary vehicle groups (or vehicle fog) with the framework's edge computing, they often face the issue of limited computational capacity in smart vehicle proximity, making resources unavailable in high-density traffic scenarios. There was a problem.

Republic of Korea Patent Publication No. 10-2020-0084394 (published on July 13, 2020) Republic of Korea Patent Publication No. 10-2020-0078385 (published on July 1, 2020)

The present invention has been proposed to solve problems occurring in the computing area of conventional edge-based intelligent vehicle networks, and an object of the present invention is to provide edge computing and fog computing based on clustered vehicles in an information-centric microservice-based vehicle network. It is an object of the present invention to provide a vehicle networking and computing system based on platooning vehicles that can integrate and hierarchically distribute and operate computational loads.

In order to achieve the above object, the clustered vehicle-based variable-volume networking and computing system according to the present invention enables microservice-based in-network computing in an information-centric network-based vehicular network, and multiple By integrating edge computing, which performs communication and computational load balancing between computing layers, and fog computing based on clustered vehicles into a single framework, mutual cooperation between multiple computing layers is possible.

Here, the vehicle networking and computing system based on clustered vehicles includes a Vehicles Layer consisting of a plurality of smart consumer vehicles moving on the road and communicating through a wireless ad-hoc interface; An edge layer composed of a plurality of static roadside edge nodes located in a direct wireless communication range of a smart vehicle in a roadside unit (RSU) and accepting and processing a computing request of the smart vehicle; A fog layer composed of a plurality of vehicle fog nodes, which are clustered stationary vehicles located near the edge layer, that process computing requests that cannot be fulfilled due to limited resources in the edge layer: the fog layer and the edge layer It is located several hops away from the cloud layer and handles computing requests offloaded from the fog layer due to limited computational resources.

In addition, the information-oriented network-based microservice naming scheme for mutual cooperation between computing layers includes the microservice name (traffic_status) in which input parameters (param1, param2) are defined, and local information (/ Korea/Seoul/Itaewon) are integrated and named.

An information-centric microservice access mechanism is applied through a unique hash-based Message Authentication Code (HMAC) in which a 17-character Vehicle Identification Number (VIN) is mapped to the named microservice name, so that the consumer vehicle of the vehicle layer is Interest An information field (access_rights) in which a hash-based message authentication code (HMAC) is inserted is added to the packet and transmitted to the edge node.

On the other hand, when the edge node receives an Interest packet having an information field (access_rights) from a consumer vehicle, it retrieves a hash-based message authentication code (HMAC) from the access storage (AS) to obtain microservice mapping (HMM), which is access right information. to find out if you have a legitimate right to use the microservice.

Here, if the edge node does not find microservice mapping (HMM) information in the access storage (AS), it requests microservice mapping (HMM) from the cloud node through an Interest packet to fetch access authority information, and from the cloud node Microservice mapping (HMM) information is transmitted through data packets and stored in the access storage (AS) so that the access storage (AS) of the edge node is synchronized with the access storage (AS) of the cloud node.

Meanwhile, the edge node performs communication between each edge node through a bridge router or requests a computing offload to the fog layer, and the fog layer requests the requested computing offload to the edge layer through the bridge router. is received through the vehicle fog gateway (VFG) and delivered to the vehicle fog node.

When the edge node receives an interest packet from the consumer vehicle, the edge node determines whether to compute the requested computing job locally or offload it to the next edge node according to the interest packet, and if the computing job is to be offloaded to the next edge node, An interest packet is generated and transmitted to the next edge node through a bridge router. The interest packet includes an adhoc_response field indicating that when the calculated result is ready, the response should be delivered to the ad-hoc air interface, not the reception interface.

Here, the interest packet transmitted from the consumer vehicle to the edge node includes field values of speed, direction, current_location, and delay requirements (speed, direction, current_location, delay_limit), and the edge node uses the field values included in the Interest packet determines where to perform the requested computing task.

In addition, when the edge node requests computing offload to the fog layer through a bridge router, (a) the edge node forwards an Interest packet to the bridge router, (b) the bridge router After transferring the interest packet to the optimal vehicle fog node through the gateway (VFG), the interest packet is forwarded to the next edge node along the vehicle direction to create a reverse PIT (Revel-PIT) entry, (c) the interest packet The next edge node receiving , responds with an Acknowledge Data message, but the Acknowledge Data message reversely writes PIT entries from the next edge node to the bridge router without deleting the entries in the PIT table, so that the PIT path is vehicular fog gateway (VFG) to be set up to the next edge node.

In the step (b), the bridge router serves as a virtual computing FIB and tracks a computing request requested to the fog layer for future vehicle fog node selection, a local resource access table for a request transmitted to a vehicle fog node ( L-RAT).

On the other hand, the vehicle fog gateway (VFG) manages the vehicle fog nodes provided in the fog layer, available computational resources, the state of the current instance running in the vehicle fog node, the current location of the vehicle in the parking area, and the parked vehicle. It manages the VF-RAT (VF Resource Access Table) that stores information including the expected time of .

According to the present invention, not only solves the networking problem by utilizing an information-centric name-based communication model, but also integrates edge and static vehicle fog computing into a single framework to exploit the potential benefits of computation in proximity of consumer vehicles, thereby enabling It has the effect of efficiently solving problems such as limited computing capacity, long backhaul delay, high bandwidth consumption and network congestion.

1 is a hierarchical structure diagram of a vehicle networking and computing system based on clustered vehicles according to the present invention;
2 is an example of an HMAC Mapper shared process combining approach according to the present invention;
3 is an example of a computing load distribution process according to the present invention;
4 to 13 show examples of fields added to an Interest packet and a Data packet according to the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

In the present invention, in a vehicle network based on a Named Data Network (NDN) or an Information Centric Network (ICN), mutual cooperation between multiple computing layers to enable microservice-based In Network Computing We suggest a possible way to do this. To this end, the present invention proposes a FoggyEdge Framework that integrates edge computing and clustered static vehicle-based fog computing into a single framework, that is, a vehicle networking and computing system based on clustered stationary vehicles.

1 illustrates a hierarchical structure diagram of a vehicle networking and computing system based on clustered vehicles according to an embodiment of the present invention.

As shown in FIG. 1, the vehicle networking and computing system according to the present invention is composed of four computing layers, and is implemented to enable smooth communication and computational load distribution between the respective layers. Each computing layer is as follows.

(1) Vehicles Layer: It consists of various smart consumer vehicles that travel on the road and communicate through a wireless ad-hoc interface.

(2) Edge Layer: Located in the direct wireless communication range of the smart vehicle in the Roadside Unit (RSU), and serves to accommodate the computing request of the smart vehicle. The edge layer consists of a number of static Roadside Edge nodes with limited computational and storage resources. The main responsibility of the Roadside Edge nodes located at the edge of a roadside is to accept smart vehicle computational requests via a wireless ad-hoc interface and to meet deadlines. to be processed within In this edge layer, communication is relayed through a bridge router.

(3) Fog Layer: A vehicle fog node, which is a cluster of parked (stopped) vehicles located near the edge layer (2 hops away) that processes computing requests that the edge layer cannot fulfill due to limited resources. consists of Vehicle fog nodes, which are clustered vehicles forming the fog layer, have limited storage and computing capacity, and the accumulation of computing and storage resources of these vehicle fog nodes can be viewed as a single large computing machine to the outside world. In this fog layer, communication is relayed through the vehicle fog gateway (VF Gateway).

(4) Cloud Layer: Consists of resource-rich cloud nodes deployed several hops away from a moving smart consumer vehicle (vehicle layer). This cloud layer is located several hops away from the vehicle fog layer and the edge layer and is responsible for handling all cloud computing requests offloaded from the fog layer due to limited computational resources.

In this way, in the present invention, unlike the conventional general vehicle edge cloud computing framework, it is formed with 4 layers of vehicle-edge-fog-cloud layer framework. When the fog layer is included between the edge layer and the cloud layer, backhaul traffic transmitted to and from the cloud layer is further reduced, thereby reducing the possibility of congestion, average delay, and bandwidth consumption. For example, in existing frameworks, when edge nodes offload compute requests, compute requests travel multiple hops to geographically distant cloud nodes, increasing backhaul traffic and average latency. Conversely, in the present invention, an offload request from an edge node is forwarded to a fog layer, a kind of giant computing machine located one hop away, utilizing the computational resources of today's smart vehicles parked near the edge node.

On the other hand, the present invention considers various speed patterns of vehicles, and whether to offload computing requests from an edge node included in the current edge layer to the next edge node of the same layer or load balancing (offload) to vehicle fog nodes in the fog layer decide whether to

In addition, the present invention not only enables offloading of computing workload between multiple layers, but also hierarchically and semantically classifies a 17-character Vehicle Identification Number (hereinafter abbreviated as “VIN”). By mapping to the devised microservice name, it provides an information-centric microservice access mechanism. In order to maintain the integrity and security of the vehicle ID, the present invention generates a hash-based Message Authentication Code (hereinafter abbreviated as "HMAC") of a microservice name with VIN as a random salt. This allows each microservice to have a unique HMAC value that the autonomous vehicle shares with the edge node. The edge node receiving the HMAC verifies the HMAC by looking up a local HMAC mapping table called the Access Store (AS). The structure of the HMM in the access store (AS) follows a key-value format, such as "HMAC: microservice-name", where HMAC is a unique key and microservice-name is the value. In addition to verifying the HMAC, the edge node synchronizes the local AS with the cloud node AS if the mapping is not available locally using the combined HMM synchronization mechanism proposed in the present invention.

And to efficiently manage and maintain multiple parked vehicles in the fog layer, the present invention provides 1) a vehicle approval mechanism, 2) allocation of parking slots based on computational resources and time availability, and 3) computational execution that is offloaded within the fog layer. Define a process like

Hereinafter, the characteristics of the present invention will be described in more detail. First, (1) the FogEdge microservice applied to the vehicle networking and computing system based on the clustered vehicles of the present invention will be described, then (2) the calculation processing method and offloading mechanism will be described, and then (3) vehicle fog management. explain about.

One. Fog Edge microservice

Since computing frameworks often require efficient management of computing services, the present invention introduces a well-known microservice architecture for each computing layer. Microservices refer to services that collaborate autonomously. Considering the approach process, microservices can be divided into the following two categories.

- Public microservices such as traffic situation and lane selection services

- Private microservices such as augmented reality-based image processing and game updates

(1-1) ICN Naming system for microservice operation based on

Microservices are named by following the hierarchical and semantically complete philosophy of NDN. In order to name such a microservice, in the present invention, in addition to the microservice name, region information is included in the transmission destination name of the interest packet. For example, the name

"FE:/Korea/Seoul/Itaewon | traffic_status? param1, param2"

contains the country's regional information.

Here, “Korea, city: Seoul, urban area: Itaewon” These three components play a key role in forwarding and/or offloading compute requests from edge nodes to vehicle fog nodes and finally to cloud nodes when needed. To this end, a city/district such as Itaewon indicates that when offloading from an edge node to a vehicle fog node, the current computation request should be forwarded to a vehicle fog node that is near the current edge node and is also in the Itaewon area. Similarly, Seoul, a component of the Seoul Metropolitan Government, specifies that when a Vehicle Fog Gateway (VFG) offloads a request, it must be forwarded to the corresponding cloud node deployed in the Seoul City. Lastly, Country: South Korea represents a centralized cloud node location.

After the local information, use a vertical pipe symbol ("|") to separate the local information from the microservice name. The microservice name is defined along with the input parameters, separated by "?", where each input parameter is further separated by a comma (",").

(1-2) Microservice access management method

Edge nodes can request access from requesting vehicles for specific microservice usage. Therefore, whenever a consumer vehicle transmits a Microservice_Compute_Interest packet to request a microservice (refer to (a) in FIG. 4 ), the consumer vehicle constructs a microservice name in “Interest packet field:access_rights (new field)” with the following name. Adds access rights information in the form of an encrypted and unique HMAC (Hash-Based Message Authentication Code) generated from the element and vehicle ID.

4 to 13 show examples of fields added to these Interest packets and Data packets. As shown in FIG. 4, the access_rights field is added as the second and last element in the interest packet in the type-length-value (TLV) format. The access_rights TLV-TYPE number assignment is 32768 and 0x8000 in decimal and hexadecimal format, respectively.

- Validate access rights and share HMAC:

When the edge node receives the Interest packet with access_rights information, it searches the HMAC in the access storage (AS) to find the microservice mapping (HMM). The structure of HMM in AS follows the key-value format as "HMAC: microservice-name", where HMAC is a unique key and microservice-name is a value. The HMAC is created by combining the microservice name with the vehicle ID (a 17-character unique Vehicle Identification Number (VIN)) used as a random salt (a salt used in cryptography).

Thus, the presence of HMM in the access store (AS) means that the vehicle requesting the service has a legitimate right to use the microservice. Edge nodes must have all access rights mapping information in advance so that verification time does not affect latency-sensitive microservice requests. However, if the access rights information is not available, it must be obtained from the cloud node. In the present invention, the HMAC Mapper shared process combination approach of FIG. 2 is applied to optimize the process of obtaining access authority information.

In the present invention, while requesting HMM, the edge node adds last_sync_time to the HMM_Fetch_Interest packet, indicating when the access storage (AS) of the edge node is finally synchronized with the access storage (AS) of the cloud node. The structure of the HMM_Fetch_Interest packet carrying the last_sync_time field is shown in FIG.

The cloud node receiving the interest packet prepares an HMM response, and in the meantime extracts the last synchronization time and compares it with the AS item time to check if there is a record with a time greater than the synchronization time. If there is a larger record, as shown in FIG. 10, the cloud node sets the more_access_rights bit of the HMM_Response_Data packet to true.

The more_access_rights above indicates that there are additional mappings that have not yet been fetched from the requesting edge node. Upon receiving the HMM_Response_Data packet, the edge node forwards another Interest packet to fetch all remaining HMMs. Thus, the access repository (AS) of the edge node is synchronized with the cloud access repository (AS). A single HMM item can occupy up to 100 bytes of memory space, including both the HMAC and microservice name, so the edge node can accommodate it within its storage capacity.

2. Calculation processing method and off roading mechanism

A computation offload process is run if the computation cannot be fulfilled on the current compute node. FIG. 3 shows an example of a computing load balancing process according to an embodiment of the present invention. In the present invention, offload mechanisms are classified into three categories as shown in FIG. 3 . (Case 2 to Case 4)

(2-1) Edge-to-edge off-road

The edge node receiving the Vehicle_Offloading_Interest packet including the fields shown in FIG. 6 (speed, direction, current_location, and delay_limit) performs the requested operation according to the new field values (speed, direction, current location, and delay requirements). Decide whether to compute locally or offload to the next edge node in the direction the consumer vehicle is traveling.

When a job needs to be offloaded to the next edge node based on the rate information, the current edge node creates an Edge_Offloading_Interest packet and forwards the packet to the next edge node using the bridge router. As shown in FIG. 7, the Edge_Offloading_Interest packet includes three additional fields. First, 1) next_edge (used in a bridge router) field. This field value is set to “true” if the current packet should be forwarded to the next edge node. Next, 2) the value of the microservice_availability field is set to "true" if the service code is available on the current edge node, and 3) the adhoc_response field is set so that the computed result is delivered to the ad hoc (wireless) interface rather than the wired Incoming Face. indicates intended. A Road Side Unit (RSU) containing an edge node assumes two types of interfaces: 1) an ad-hoc wireless interface that receives requests from smart vehicles moving on the road, and 2) a wired interface connected to a bridge router. Thus, the smart consumer vehicle receives data on the wireless ad hoc interface.

Upon receiving the Edge_Offloading_Interest packet, the next edge node sets the microservice_fetch field to true in the Microservice_Fetch_Data packet shown in FIG. 11 to fetch microservice content (which can be a program function, API, or data) from the previous edge. On the way back to the previous edge, the PIT items are not deleted and the receiving and sending sides of these items are reversed and used to deliver microservice content from the previous edge. The previous edge node that received the Microservice_Fetch_Data packet extracts the value from the microservice_fetch field and prepares a data packet containing the microservice content. The data packet follows the PIT items set in the previous step and finally reaches the next edge node. This type of offload mechanism is only used when the vehicle speed is high and the current edge cannot meet the closing requirement, because it avoids overloading the edge node in case of congested traffic scenario.

(2-2) Edge to vehicle fog off-road

Offloading from edge nodes to vehicular-fog nodes allows edge nodes to offload current computational requests to optimal vehicular-fog nodes when resources are unavailable or in short supply in the edge layer. The details of the request-response processing mechanism for this vehicle fog off-road are as follows.

After the offload decision, the edge node inserts information such as vehicle speed, direction and delay requirements into the interest packet and forwards it to the bridge router. When a bridge router receives a computing request, it immediately forwards it to the nearest and relatively optimal vehicle fog node. In addition, the bridge router maintains a local resource access table (L-RAT) for each request forwarded to the vehicle fog node through the vehicle fog gateway (VFG). The Local Resource Access Table (L-RAT), which also serves as the Virtual Computing FIB (VC-FIB), is an overlay of the existing FIB table and is utilized for interface selection.

After sending the request to the best vehicle fog node, the bridge router forwards the Interest packet to the next edge node (vehicle direction) to create a Revel-PIT entry similar to that described in the previous section. Next, when the edge node receives the Interest packet, it responds with an acknowledgment Data message. In contrast to the existing data message, the grant data message does not delete the entries in the PIT table, but changes the direction of the incoming and outgoing faces to create PIT entries in the reverse direction from the next edge node to the bridge router. . As a result of this operation, the PIT path is established all the way from the vehicle fog gateway (VFG) to the next edge node. Here, the next-generation node passes the computational results to an ad-hoc interface following a similar process described in the previous section.

(2-3) Off-road between vehicle fog and cloud

Vehicle fog nodes can offload computation to cloud nodes if there are not enough vehicle compute resources. Vehicle fog nodes offload computational requests through bridge routers. The bridge router receiving the offload request forwards it to the cloud node, and at the same time changes from the vehicle fog gateway (VFG) side to the cloud side to update the transmission path information of the PIT. This way, when the computed result arrives, it is passed directly to the next edge node or edge node requesting the calculation based on the updated PIT item.

3. Vehicle fog management

Since vehicle fog is a cluster of multiple vehicles providing computational and storage services, an efficient vehicle coordination mechanism is of paramount importance. To manage the resources of these vehicles, the vehicle fog gateway (VFG) includes information such as available computational resources, the state of the current instance running on the vehicle fog node, the vehicle's current location within the parking zone, and the expected parking time, VF- A RAT (VF resource access table) is maintained.

In the present invention, a vehicle fog gateway (VFG) can receive traffic coming from both a wired interface and a wireless ad-hoc interface. A wired interface is used to connect the Vehicle Fog Gateway (VFG) with edge nodes at the bottom and cloud nodes at the top tier, while a wireless ad-hoc interface is used for communication with parked vehicles.

- vehicle orchestration or approval process;

Whenever a vehicle enters a parking area and passes a ticket area, an interest packet is transmitted through a wireless ad-hoc interface to request parking slot information from the vehicle fog gateway (VFG), which is a manager node. While sending the Interest message, the vehicle adds the following information to the Admission_Interest packet shown in FIG. 8 .

1) Estimated parking time for the expected_park_time field

2) Total compute power for the compute_resource field

3) Available storage capacity for the storage_resource field

Upon receiving the Admission_Interest message, the Vehicle Fog Gateway (VFG) extracts information from the aforementioned fields and selects a suitable parking slot for the new vehicle. Immediately after selecting a slot number, the Vehicle Fog Gateway (VFG) does two things: 1) The data packet is sent back to the vehicle to inform the slot location, and 2) the vehicle information is stored in the VF-RAT table. This allows the Vehicle Fog Gateway (VFG) to maintain overall control over all vehicles under management and direct computing requests to the optimal vehicle in the cluster.

When the vehicle executing the computation is about to leave the parking area, the running computation instance is offloaded to the Vehicle Fog Gateway (VFG). The offload process is as follows.

The vehicle node creates a Parked_Vehicle_Offloading_Interest packet shown in Figure 9 on the wireless ad hoc interface, which is received by the vehicle fog gateway (VFG) over the ad hoc interface. Upon receiving the Parked_Vehicle_Offloading_Interest packet, the vehicle fog gateway (VFG) selects the optimal vehicle to be managed, inserts the VIN into the VFG_Offloading_Response_Data packet shown in FIG. 12, and transmits a response to the wireless ad hoc interface.

The vehicle that sent the Parked_Vehicle_Offloading_Interest packet and the new vehicles selected for calculation receive VFG_Offloading_Response_Data, and at this time, the vehicle that sent the Parked_Vehicle_Offloading_Interest packet sends a running calculation instance to the newly selected vehicle using the Computation_Offloading_Data packet shown in FIG. 13, Finally leave the parking area. The presence of a VIN in the Computation_Offloading_Data packet indicates that this data packet is for a vehicle with a specific VIN, so other vehicles receiving this data packet ignore this packet.

As soon as the vehicle passes through the ticket booth and exits the parking lot, the Vehicle Fog Gateway (VFG) erases all VF-RAT records.

As such, the present invention proposes a vehicle networking and computing system based on clustered vehicles to effectively hierarchically distribute and operate computational loads in a microservice-based information centric network (ICN). Components and operating processes of the clustered vehicle-based vehicle networking and computing system of the present invention described above are summarized as follows.

1. 4 Layers: Vehicle Layer (Consumer Vehicle) - Edge Layer (RSU, Edge Node) - Fog Layer (Vehicle Fog Node) - Cloud Layer (Cloud Node)

2. Information-Centric Network Protocol for Communication and Cooperation between Computing Layers for Offloading Computing in Information-Centric Networks (ICN)

The invention proposed in the present invention modified the structure of the Interest and Data packets of the Naming Data Network (NDN) to enable efficient computing offload in the edge, fog and cloud layers. It is built into the structure of existing Interest/Data packets to convey information such as offloading requests to the next edge to enable compute offload within the edge layer, microservice code availability, microservice code fetching, and ad hoc response indication. 4 to 13, new fields were applied.

On the other hand, in order to offload from the edge layer to the fog layer via the bridge router, the local resource access table (L-RAT) is operated in the bridge router. It serves as a Virtual Computing Forwarding Information Base (VC-FIB) in the bridge router and is responsible for keeping track of compute requests going out to the fog layer for future fog selection. In addition, in order to deliver the computer results from the fog layer to the next edge layer (vehicle direction due to high speed) in a timely manner, the present invention introduces an inverse PIT mechanism.

3. VIN-based microservice naming mechanism for information system communication

Microservices are named by following the hierarchical and semantically complete philosophy of NDN. In addition to the microservice name, the proposed framework for naming these microservices includes local information in the transmission destination name of the Interest packet.

4. Communication process with HMAC

A hash-based message authentication code (HMAC) calculation procedure was designed considering both the integrity and security requirements of the vehicle ID. In order to share the HMAC, the present invention introduces a new field in the Interest packet named access_rights as shown in FIG. The smart vehicle inserts the HMAC value into the access_rights field and forwards the Interest packet to the edge node while offloading the private microservice-based computational request. When the edge node receives the HMAC, it needs to compare the received HMAC with the HMM (microservice name mapping) value with the locally stored value. To this end, the present invention maintains an HMAC mapping table at each roadside edge node and synchronizes it with a cloud node using the combined HMAC sharing approach proposed in the present invention.

5. Fog layer vehicle management and maintenance method for vehicles

To manage the resources of vehicles parked within the vehicle fog layer, the Vehicle Fog Gateway (VFG) maintains a resource access table named VF-RAT, which contains the available compute resources, the state of current instances running on the vehicle fog nodes , the current location of the vehicle inside, the parking area and the expected time of the parked vehicle (vehicle fog node).

As such, the present invention integrates edge and fog computing into a single framework to fully exploit the potential benefits of computation in proximity of a consumer vehicle. The present invention is not limited to the above-described embodiments, and various modifications and variations within the scope of equivalents of the technical spirit of the present invention and the claims to be described below by those skilled in the art to which the present invention pertains. Of course, this can be done.

Claims (12)

In information-centric network-based vehicular networks,
Microservice-based in-network computing (In Network Computing) is possible, and edge computing that performs communication and calculation load balancing between multiple computing layers and fog computing based on clustered vehicles are integrated into a single framework, enabling multiple computing A vehicle networking and computing system based on clustered vehicles, characterized in that mutual cooperation between layers is possible.
According to claim 1,
a Vehicles Layer consisting of a plurality of smart consumer vehicles moving on the road and communicating via a wireless ad-hoc interface;
An edge layer composed of a plurality of static roadside edge nodes located in a direct wireless communication range of a smart vehicle in a roadside unit (RSU) and accepting and processing a computing request of the smart vehicle;
A Fog Layer consisting of a plurality of Vehicle Fog Nodes, which are clustered stationary vehicles located near the Edge Layer, that process computing requests that cannot be fulfilled due to limited resources at the Edge Layer; and
A cloud layer located several hops away from the fog layer and the edge layer and processing computing requests offloaded from the fog layer due to limited computational resources; and computing systems.
According to claim 2,
Information-centric network-based microservice naming system for mutual cooperation between computing layers,
The name of the microservice (traffic_status) in which the input parameters (param1, param2) are defined and the regional information (/Korea/Seoul/Itaewon) indicating the transmission destination of the interest packet are integrated and named based on the clustered vehicles. networking and computing systems.
According to claim 3,
An information-centric microservice access mechanism is applied through a unique hash-based message authentication code (HMAC) in which a 17-character vehicle identification number (VIN) is mapped to the named microservice name,
The vehicle networking and computing system based on clustered vehicles, characterized in that the consumer vehicle of the vehicle layer adds an information field (access_rights) in which a hash-based message authentication code (HMAC) is inserted to the interest packet and transmits it to the edge node.
According to claim 4,
When the edge node receives an Interest packet having an information field (access_rights) from a consumer vehicle, it retrieves a hash-based message authentication code (HMAC) from the access storage (AS) to find microservice mapping (HMM), which is access right information, A vehicle networking and computing system based on platooning vehicles, characterized in that it verifies that it has a legitimate right to use the corresponding microservice.
According to claim 5,
If the edge node does not find microservice mapping (HMM) information in the access storage (AS), it requests microservice mapping (HMM) from the cloud node through an interest packet to obtain access authority information, and data packets from the cloud node Receives microservice mapping (HMM) information through and stores it in the access storage (AS),
A vehicular networking and computing system based on clustered stationary vehicles, characterized in that an access store (AS) of an edge node is synchronized with an access store (AS) of a cloud node.
According to claim 2,
The edge node performs communication between each edge node through a bridge router or requests computing offload to the fog layer,
The fog layer receives a compute offload request to the edge layer through a bridge router through a vehicle fog gateway (VFG) and forwards it to a vehicle fog node.
According to claim 7,
When the edge node receives the interest packet from the consumer vehicle, it determines whether to perform the requested computing task locally or offload to the next edge node according to the interest packet;
When computing tasks need to be offloaded to the next edge node, an interest packet is generated and transmitted to the next edge node through the bridge router. When the calculated result is prepared in the interest packet, the response is sent to the ad-hoc air interface, not the receiving interface. A vehicle networking and computing system based on platooning vehicles, characterized in that an adhoc_response field indicating that it should be delivered is included.
According to claim 8,
The interest packet transmitted from the consumer vehicle to the edge node includes speed, direction, current location, and delay requirement (speed, direction, current_location, delay_limit) field values,
The edge node determines where to perform the requested computing task according to field values included in the Interest packet.
According to claim 7,
When the edge node requests computing offload to the fog layer through a bridge router,
(a) When the edge node forwards the Interest packet to the bridge router,
(b) The bridge router transfers the interest packet to the optimal vehicle fog node through the vehicle fog gateway (VFG), and then forwards the interest packet to the next edge node along the vehicle direction to obtain a reverse PIT (Revel-PIT) entry. create,
(c) The next edge node receiving the Interest packet responds with an acknowledgment data message, but the acknowledgment data message reversely writes PIT items from the next edge node to the bridge router without deleting items in the PIT table, so that the PIT path is established. A vehicle networking and computing system based on clustered vehicles, characterized in that a vehicle fog gateway (VFG) is established to the next edge node.
According to claim 10,
In step (b),
The bridge router serves as a virtual computing FIB and operates a local resource access table (L-RAT) for requests transmitted to vehicle fog nodes in order to track computing requests requested to the fog layer for future vehicle fog node selection. A vehicle networking and computing system based on parked vehicles, characterized in that.
According to claim 7,
The vehicle fog gateway (VFG) manages the vehicle fog nodes provided in the fog layer, including available computing resources, the state of the current instance running on the vehicle fog node, the current location of the vehicle in the parking area, and the prediction of the parked vehicle. A vehicle networking and computing system based on clustered vehicles, characterized in that it manages a VF-RAT (VF Resource Access Table) that stores information including time.

Images