Efficient Access Method for Multi-access Edge Servers in Dynamic Map Systems

Research and development on connected cars equipped with communication functions is being conducted, and dynamic maps are being researched and developed as an information and communication platform for cooperative automatic driving. There is a concern about scalability when dynamic maps are constructed on a cloud server to aggregate a wide range of vehicle information. The problem can be alleviated by deploying edge servers that divide the geographic area where vehicles travel and manage each of them. The IP addresses of the edge servers need to be resolved on the basis of the location information of the moving vehicles. Using TCP improves reliability but reduces efficiency because the vehicles move. In this study, we developed a novel method for accessing edge servers that achieves higher reliability and efficiency by adopting UDP using anycast for transmission from vehicle to edge server and implementing a retransmission function. The effectiveness of this access method was verified by using a vehicle driving simulation.


Introduction
With the aim of realizing a safe and secure mobility society, efforts are being made to develop automobile traffic systems that integrate automobiles and information communications, such as safe driving support systems and automated vehicles [1][2][3]. In particular, the sophistication of sensors installed in vehicles has enabled detailed recognition of the surrounding driving environment, which has accelerated the research and development of advanced safe driving support systems that warn the driver and automatically avoid danger, as well as automated driving systems that enable autonomous driving [4,5].
However, the range of objects that can be recognized by sensors mounted on vehicles is limited, and although these sensors can detect objects within the range of visibility, they cannot detect objects beyond it [6,7]. For example, it is difficult to respond to an imminent collision at an intersection that has poor visibility or a sudden jump out from behind an object. To cope with these situations, research is being conducted on cooperative automatic driving, which aims to improve safety by using wireless communication technology to exchange information between vehicles in motion or between vehicles and roadside equipment [8][9][10].
Various applications of cooperative automatic driving are being considered, such as for warning of a risk of collision at an intersection, providing information on traffic congestion, road surface conditions, and signal status, as well as support for merging on expressways [11]. Maps are expected to play a role not only in conventional route search to a destination but also in providing highly accurate spatial features for self-positioning estimation of each automated vehicle and as basic information for linking sensor information shared among vehicles. Currently, each piece of information is managed and processed separately for each application. An information and communication platform that enables dynamic information obtained from sensors to be superimposed on a high-precision road map is called a "dynamic map," and it is a necessary information infrastructure that supports advanced transportation services such as automated driving [12,13]. As shown in Fig. 1, the generally recognized structure of a dynamic map consists of a static road map on which dynamic information is layered in accordance with the frequency of information updates.
Dynamic maps provide the necessary functions for data management, such as collection, integration, and retrieval, of high-precision road maps and sensor information, making it possible to develop and execute applications that provide transportation services more flexibly and easily. Sensor and signal information transmitted from vehicles, shown as dynamic data in Fig. 1, are generally required to be updated at a frequency of 100 ms in a dynamic map [14]. Transient dynamic data, which involves accident and traffic information, requires an update frequency of about one minute, while transient static data, which involves traffic control and construction information, requires an update frequency of about one hour. Finally, static data, such as lane and structure information, is expected to be updated at a frequency of about one month. Applications that have a high impact on traffic safety, such as safe driving support and cooperative automatic driving, operate on the basis of this information, so information processing with low latency is required. Normally, a dynamic map system assumes the use of a cloud server on the Internet, but if a huge amount of data from vehicles is concentrated on the server, it will cause a processing load and communication delay, so scalability will become a problem. Many applications that operate on dynamic maps have a high impact on traffic safety, such as intersection collision risk warning and merge control. Therefore, these applications need to communicate and process data with vehicles with low latency. Thus, the processing load should be distributed and communication delay reduced by deploying an edge server between cloud servers and vehicles [15][16][17].
Data sent from vehicles is processed sequentially by geographically distributed edge servers, and the processing results are notified directly to the vehicles, which is expected to improve the real-time performance. However, as shown in Fig. 2, since dynamic maps handle applications that have a high impact on traffic safety, edge servers not only need to process vehicle data in real time but also need to aggregate all vehicle data in a target area for the applications handled by each edge server. ETSI is considering Multi-access Edge Computing (MEC), where edge servers are placed around mobile phone base stations [18,19].
In this paper, we propose an access method for a dynamic map system that can aggregate and process the data sent from a vehicle to an edge server through a core network  [20]. However, those architectures assume that end devices are fixed or move within a very narrow range; thus, they do not account for vehicles with a wide range and high speed of movement, as in this study. Accordingly, the dynamic map system needs to aggregate the data sent from vehicles to appropriate edge servers. We thus propose a dynamic map system based on MEC, in which each edge server has jurisdiction over a geographically segmented area. To facilitate this system, we propose an access method in which edge servers are linked through a core network in order to operate dynamic maps more efficiently for vehicles moving at high speed.

Proposed Methods
Our dynamic map system reduces the load on a network by distributing the processing of data collection and distribution between a vehicle and the nearest edge server and enables real-time processing, as shown in Fig. 3. When this system is implemented on the cloud, tens of millions of cars will be connected, constantly communicating and processing. To exchange support information for safe driving control, a single cloud needs to receive and process data from each vehicle at a rate of about 100 milliseconds per cycle, which is not appropriate from the perspective of network load, server processing load, and real-time performance. In this study, we consider a dynamic map system with edge servers located around mobile phone base stations that receive and send data from moving vehicles. Vehicles send data obtained from onboard sensors to edge servers. The data sent from the vehicles include the vehicle ID, vehicle position, speed, direction of travel, time stamp, etc. The vehicle position is obtained by using vehicle position information obtained by GPS or scan matching [21][22][23]. In this paper, each vehicle and edge server are referred to as a node, and each node has a unique ID, like the ITS systems that are being standardized in Europe [24]. Each node sends and receives data, and applications are executed. The dynamic map system can be used as a common infrastructure for linking sensor information and map data, and it facilitates the construction of applications.
In the dynamic map system in this paper, IP is used as the communication method between the vehicle and the edge server. And 5G, Wi-Fi, C-V2X, DSRC, etc. are assumed to be used as the communication method between the vehicle and the edge server [25][26][27]. In the case of using the dynamic map system only on the cloud, when sending data from the vehicle, the IP address of the vehicle is used as the source and the IP address of the cloud as the destination. When an application is executed on the dynamic map system in the cloud, the IP address of the vehicle can be used to notify the vehicle of the processing result. However, in a configuration using edge servers, the IP address of the edge server cannot be uniquely set as the destination when sending data from the vehicle because the vehicle switches between multiple edge servers while driving. One solution to this problem is to link the IP addresses of neighboring edge servers corresponding to the location information and keep this information in each vehicle in advance. In this case, however, it is necessary for the vehicle to have information on all edge servers, and the process of updating the information held by each vehicle becomes complicated. In addition, since each vehicle transmits data on the basis of the information of its own edge server, each edge server on which the dynamic map operates cannot know whether it has received all the vehicle data in the target range. In addition, it is not always possible to connect to the target edge server due to wireless communication conditions. In addition, the range managed by the edge servers changes depending on the road conditions. Therefore, we propose an access method for our dynamic map system that assigns an edge server on the basis of the location information of vehicles and uses UDP anycast addresses [28]. Our dynamic map system allows vehicles to send data to edge servers using UDP with an anycast address as the destination. Each edge server that receives data is assigned the same anycast address, which allows a vehicle to send data without being aware of the destination server while it continues to move. However, although the use of anycast addresses allows vehicles to be unaware of the destination server, they do not know which edge server will receive the data sent from each vehicle. In addition, since the applications operated by the dynamic map system include those that have a high impact on traffic safety, each edge server needs to aggregate all vehicle data within an application's operating area. Each edge server determines which edge server will receive data from a vehicle on the basis of the vehicle location information in the received data and transfers the data to the surrounding edge servers as necessary. In addition to a payload consisting of sensor data, a unique header is added to the UDP data sent by the vehicle [29]. This header is used to manage the vehicle data in the dynamic map system and includes a station ID (SID) to identify the vehicle and a transfer flag to recognize the transfer between edge servers. The UDP packets sent by a vehicle are shown in Table 1. When an edge server receives the data from a vehicle, it determines the necessity of the transfer on the basis of the SID, and if the transfer is necessary, it specifies the edge server to be the destination using unicast and sends a TCP packet.
Instead of the vehicle designating the edge server to which the data is to be sent, the edge server closest to the vehicle receives the data and, if necessary, transfers the data using high-speed dedicated lines maintained between each edge server, thereby enabling more efficient exchange of vehicle data [30]. In addition, we are considering placing each edge server in the vicinity of a cell phone base station, and the operating area of the applications running on the dynamic map system on each edge server is expected to basically overlap with the reception area of the base station, thus reducing the need for data transfer and improving realtime performance. This is expected to reduce the need for transmission and improve real-time performance.
We define two types of areas covered by edge servers. The receiving area is the area under the jurisdiction of the dynamic map running on each edge server. The jurisdictional area is the geographical area under the jurisdiction of the dynamic map running on each edge server. Each edge server aggregates the vehicle data within its jurisdictional area, regardless of the reception area. The reason for this is that the reception area of each edge server may change due to the influence of radio wave conditions. In addition, the reception area of each edge server may have overlapping ranges. In this paper, we propose a method to aggregate the data of vehicles in a dynamic map, which can be used for applications that have a high impact on traffic safety. The proposed method can determine the edge server to send the vehicle data based on the vehicle location. In order to operate in a large-scale environment in the future, we are conducting a demonstration experiment in a natural environment using a dynamic map system based on this method. Here, we assume that the jurisdictional area of the edge server is different from the receiving area or that the receiving areas overlap. We confirm that the data sent from the vehicle is correctly received by the dynamic map on the target edge server.
UDP is a connectionless protocol, so it is faster than TCP, but it is less reliable, and packet loss is a concern [31]. In addition, since the communication between a vehicle and edge server is wireless, it is less reliable than wired communication [32]. To solve this problem, the edge server sends back ACK data to confirm the reception of the data sent by the vehicle. As shown in Fig. 4, the vehicle continues to retransmit sensor data periodically until it receives ACK from the edge server and stops retransmitting data when it receives it. Data from the vehicle is sent to an anycast address, and the edge server sends back ACK to the sender's unicast address. The edge server forwards the data between the edge servers as necessary, using the Unicast address of the vehicle as the source of the data as the destination, and sends an ACK, as shown in Fig. 5. Since the ACK data from the edge server is also sent using UDP, there is no guarantee that the ACK data will reach the vehicle. Therefore, each edge server filters the data from the vehicle and discards the data if it is the same data due to retransmission.
Data transmission from a vehicle to an edge server uses an anycast address, and for data transmission from an edge server to a vehicle, the IP address of the vehicle is determined from the packets sent by the vehicle, and the unicast address is used. In this case, there is no problem if the edge server has received the data from the vehicle beforehand, but it is not possible to notify information such as on the location of emergency vehicles before receiving the data from the vehicle. In addition, when unicast is used, communication occurs for each vehicle, which increases the communication cost. The information notified to vehicles from applications in dynamic map systems is not only individual information for each vehicle but also the same information in many cases. Therefore, we use the multicast address as a method of simultaneous notification from edge servers to vehicles [33]. This allows an edge server to send data without knowing the unicast address of each vehicle. In addition, each vehicle can determine the necessity of discarding data by judging the SID of the destination stored in the header of the data sent by the edge server.

Related Works
Usually, an end device sends data to an edge server by specifying the IP unicast address of the destination edge server. Adika's research proposes the use of anycast addresses as an access method from end devices to edge servers in multiaccess edge computing [34]. In this research, however, the objective is to send data to the nearest edge server, and it is thus unknown which edge server will receive the data sent from a vehicle. A dynamic map requires aggregating the vehicle data in the area under the jurisdiction of each edge server. In addition, because vehicles keep moving at high speed across the areas of different edge servers, it is necessary to resolve the edge server to which the data is sent. Hence, in this paper, we propose a dynamic map based on an access method that uses anycast addresses to link fastmoving vehicles and edge servers.
Mobile IP is a protocol that allows devices to connect with a unique IP address regardless of the network to which they are connected [35,36]. Mobile IP operates at the network layer and provides mobility transparency by maintaining sessions even when nodes move. However, in dynamic maps for use in cooperative automatic driving, applications require a vehicles location information, and it is not necessary to guarantee location transparency, which is a feature of Mobile IP. Therefore, by managing the location information in the application layer rather than in the network layer, the proposed system can use the existing network layer mechanism instead of the complicated Mobile IP mechanism. Specifically, a custom header is introduced between the UDP header and the payload. By managing the location information at the application layer, a flexible dynamic map system can be implemented for various network environments. Furthermore, the use of Mobile IP requires communication through a home agent, which entails a redundant triangular path and thus causes issues such as reduced communication efficiency and a single point of failure. For these reasons, in this paper, we propose an efficient access method between a vehicle and an edge server by using IP anycast addresses, which can use the existing network layer mechanism instead of Mobile IP. In addition, Mobile IPv6 and its extensions allow knowing location information and avoiding redundant triangular transmissions. Nevertheless, Mobile IPv6 cannot be applied to the use cases such as merging arbitration because the edge server needs to be determined by accurate location information based on GPS. Most mobile operators do not support Mobile IPv6 from the perspective of efficient mobility support (i.e., the current mobile networks provide mobility support in L2 instead of L3). Therefore, as

Experiments
To evaluate the access method, we prepared an edge server and a PC as a vehicle and constructed a dynamic map system. Using dynamic map system, we implemented an access method using anycast and a retransmission function using ACK. To evaluate the effectiveness of three access methods introduced below, we simulated the dynamic map system by driving multiple vehicles. The access methods used and the evaluation environment are described in this section.

UDP Access Method Using Anycast & no Retransmission by ACK
The data sent from the vehicle was a UDP packet destined to a unique anycast address assigned to the edge server. Each edge server determined the edge server that needed the data on the basis of the SID and vehicle location information stored in the header of the data received from the vehicle. If the data needed to be forwarded, it sent a TCP packet with the unicast address of the destination edge server as the destination. The vehicle sent the sensor data, including the current position information, to the edge server at intervals of 100 milliseconds, without retransmission. Each edge server executed an application in the dynamic map system on the basis of the aggregated vehicle data and notified the vehicle of the processing results.

UDP Access Method Using Anycast & with Retransmission by ACK
As in Section 4.1.1, the vehicle sent data to the edge server using the assigned anycast address as the destination. The edge server received the data and forwarded the data as necessary on the basis of the SID and vehicle location information stored in the header. The edge server that received the data with its own destination sent back ACK data to the sender vehicle. The vehicle retransmitted the data until it received the ACK data.

TCP Access Method Using Unicast
The vehicle sent a TCP packet with the unicast address of the edge server as the destination. In this case, the vehicle was assumed to have the unicast address of the edge server corresponding to its own location information. The TCP packets sent by the vehicle are shown in Table 2.

Scenarios for Simulation
To evaluate the effectiveness of the access method of the dynamic map system, we conducted a simulation of vehicle driving. Vehicles traveled around a road with two edge servers and sent data to them. To evaluate the effectiveness of the access method without depending on the application on the dynamic map system, we simulated vehicles driving through the Shirosato Test Center of the Japan Automobile Research Institute [37]. The high-speed track of the Shirosato Test Center is 5500-m long, and vehicles can drive around it. Two edge servers were installed at the track, and each handled over half of the track. The vehicles traveled at a speed between 40 and 60 km/h with a smooth speed change. The data sent from the vehicles was received by the nearest edge server on the basis of the radio wave conditions, etc. The data was not necessarily sent directly to the appropriate edge server but was forwarded as necessary. The scene during the simulation is shown in Fig. 6. Each vehicle is indicated by a marker of the color of the edge server that received the transmitted data. The vehicles sent 1158 bytes of data, consisting of an Ether header, IP header, UDP header, proprietary header, and payload. In order to evaluate the impact of an increase in the number of vehicles operated by the edge server, we construct a PC as a load vehicle and perform a driving simulation. Tables 3 and 4 show the configuration of the edge server and the PC used as the vehicle for the dynamic map system we constructed. The structure of the dynamic map system we constructed is shown in Fig. 7. The vehicle is expected to communicate with the dynamic map using multiple wireless communication methods, such as 5G and Wi-Fi, and we previously conducted demonstration experiments with dynamic maps using LTE and Wi-Fi. However, wireless communication depends not only on system factors such as the access method proposed in this paper but also on communication conditions [38]. In this paper, we propose the novel method for accessing edge servers for moving vehicles in used for any networks. We are constructing a dynamic map system to manage vehicles in an integrated manner by flexibly using such technologies and have proposed a method for accessing edge servers for moving vehicles. To clarify the contribution of the access method to the effectiveness of the dynamic map system, we constructed and evaluated a communication environment using Ethernet, which reduces the uncertainty of wireless communication.

Dynamic Map System
To verify the effectiveness of the access method, we measured the packet loss rate, throughput, and latency. These were measured using log data from our dynamic map system and Wireshark, the most widely used network protocol analyzer in the world [39]. We also use the Google Maps Platform to visualize the location of the vehicles and the edge servers [40].

Results
We evaluated the UDP access method using anycast addresses, the retransmission function using ACK, and the data transfer function between edge servers, in terms of the packet loss rate, throughput, and latency of each system. For each scenario, we conducted 20 trials of a 5-minute simulation.

AccEss Method Using Anycast Address
We compared our proposed UDP access method using anycast addresses with the conventional TCP access method using unicast addresses. First, we explain the evaluation results obtained with one vehicle. As shown in Fig. 8, the packet loss rate was 0 % for all trials with the TCP access method. For the UDP access method, the average packet loss rate was 0.05 % and the 95 % confidence interval by the chi-squared distribution was 0.033 % ≤ ≤ 0.058 % . The reason for this result is that UDP is a connectionless protocol, so packet loss may occur when there is no retransmission function in the upper protocol.
Next, we measured the throughput on the vehicle side, which sends the data, and on the edge server side, which receives it. As shown in Fig. 9, the sending throughput averaged 18.1Kbps for both the TCP access method and the UDP access method, and the receiving throughput averaged 18.0Kbps for both access methods.
Finally, we measured the latency as the time it took for the data sent from the vehicle to reach the dynamic map    application on the edge server that needed the data. As shown in Fig. 10, for the TCP access method, the average latency was 7.9ms with a 95 % confidence interval of 7.7ms ≤ ≤ 8.2ms . For the UDP access method, the average latency was 5.1ms with a 95 % confidence interval of 4.9ms ≤ ≤ 5.3ms . The latency of the TCP access method using the unicast address was large because of the influence of TCPs three-way handshake and retransmission control, whereas the proposed UDP access method using the anycast address enabled communication with low latency. This experiment was performed not only with the measurement vehicle but also with simulated load vehicles running around the same course. Specifically, we ran the simulation with 1000, 3000, 5000, 7500, 10000, and 12000 load vehicles. We assumed that all the load vehicles ran at varying speeds and sent data to the edge server in the same way as the measurement vehicle.
As shown in Fig. 11, with the TCP access method using the unicast address, the packet loss rate remained low up to a certain number of vehicles but then increased rapidly. This may be due to the fact that our system reached its throughput limit because of the use of TCP. In contrast, with the UDP access method using the anycast address, the packet loss rate remained lower than with the TCP access method even as the number of vehicles increased. However, some packet loss occurred even with a small number of vehicles because of the use of UDP. Figure 12 shows the throughput of the server at the receiving end when the number of vehicles was varied. With the proposed UDP access method, the throughput increased as the number of vehicles increased, with an upper limit of about 950Mbps, beyond which packets were discarded. As for the TCP access method, the upper limit was about 650Mbps, and packets beyond that were also discarded. This may be due to the fact that the throughput of TCP decreases with the RTT. For dynamic maps that send and receive huge amounts of data, higher throughput would make the UDP access method more effective. In this experiment, we used Ethernet to verify the effectiveness of the access method.    However, actual vehicles are expected to communicate wirelessly, and the RTT is likely to decrease; thus, the proposed method would be effective because it can achieve high throughput independently of the RTT.
As shown in Fig. 13, the latency with the UDP access method using the anycast address did not change significantly as the number of vehicles increased, whereas the latency of the TCP access method using the unicast address did increase with the number of vehicles. This increasing tendency with the TCP access method was probably due to the influence of TCPs retransmission control and congestion control. In a dynamic map system, real-time performance is a very important issue, and the shorter the latency in sending and receiving data, the better. Accordingly, the proposed UDP access method has the benefit of providing data transmission with very low latency as compared to TCP communication.

ACK Retransmission
As described in Section 5.1, our proposed UDP access method using anycast addresses can be used in dynamic map systems to efficiently manage a large number of vehicles. However, UDP communication is less reliable and more prone to packet loss as compared to TCP communication. In our experiment, as shown in Fig. 8, the UDP access method caused slightly more packet loss than the TCP access method. Accordingly, we implemented the ACK retransmission function described in Section 2 to improve the reliability of the proposed UDP access method, and we compared the performance with and without ACK retransmission.
First, we explain the evaluation results obtained with only one measurement vehicle. As shown in Fig. 8, the average packet loss rate was 0.05 % without the ACK retransmission function, but it was reduced to 0 % in all trials by implementing the retransmission function. As shown in Fig. 9, the throughputs of the sending vehicle and the receiving server averaged 18.1 and 18.0Kbps, respectively, both with and without ACK retransmission. Furthermore, the average latency was 6.0ms both with and without ACK retransmission, as shown in Fig. 10.
This experiment was also performed with simulated load vehicles (1000, 3000, 5000, 7500, 10000, and 12000) running around the same course. The load vehicles ran at different speeds and sent data to the edge server in the same way as the measurement vehicle.
As shown in Fig. 11, the packet loss rate with the ACK retransmission function remained lower than that without the retransmission function even when the number of vehicles increased. When the number exceeded approximately 10000, a small amount of packet loss occurred even with the retransmission function, but this was because the sent packets exceeded 1Gbps, which was the bandwidth of the dynamic map system used in this experiment. Figure 12 shows that the throughput of the server at the receiving end increased as the number of vehicles increased, with or without the ACK retransmission function. The throughput was capped at about 950Mbps, and packets beyond that were discarded.
Finally, as shown in Fig. 13, there was almost no difference in latency between the cases with and without the ACK retransmission function. The slightly larger latency with ACK retransmission was probably due to the delay caused by retransmission when packet loss occurred.

Data Transfer Between Edge Servers
As described in Section 2, when edge servers are deployed to construct a dynamic map, each edge server needs to aggregate the data of all vehicles in the area where it operates. However, in the proposed system with a UDP access method using the anycast address, the data sent by a vehicle is not always received by the target edge server. Therefore, we implemented a function to transfer data between edge servers as needed. Basically, the operating area is determined according to the reception range of each edge server, so the number of vehicles that require data transfer is expected to be small, but it may depend on the communication situation. Accordingly, we evaluated the performance of the system with and without data transfer between edge servers. We ran the same simulation as above and compared the performance between the case without data transfer, in which the data sent from a vehicle was always received by the target edge server, and the case with data transfer, in which the data was always received by a non-target edge server and then transferred.
Again, we first describe the evaluation results obtained with only one measurement vehicle. As shown in Fig. 14, the packet loss rate was 0 % in all trials regardless of whether data was transferred between the edge servers. The latency,  Fig. 15, averaged 4.9ms without data transfer, with a 95 % confidence interval of 4.8ms ≤ ≤ 5.0ms ; with data transfer between the edge servers, the mean latency was 5.6ms with a 95 % confidence interval of 5.5ms ≤ ≤ 5.7ms.
This experiment was also performed with simulated load vehicles (1000, 3000, 5000, 7500, 10000, and 12000) running around the same course. The load vehicles ran at different speeds and sent data to the edge server in the same way as the measurement vehicle.
As shown in Fig. 16, the packet loss rate remained similar regardless of the data transfer between the edge servers even when the number of vehicles increased. This result is similar to the result described in Section 5.2 for the proposed system with the ACK retransmission function. The packet loss rate increased when the number of vehicles exceeded about 10000, but this again occurred when the sent packets exceeded 1Gbps, the bandwidth of the dynamic map system.
As shown in Fig. 17, the latency was slightly higher when there was data transfer between edge servers than when there was no data transfer. However, this difference did not increase as the number of vehicles increased, and the latency was still lower than that of the conventional TCP access method using unicast addresses.

Discussion
In this paper, to evaluate the effectiveness of the proposed system, we conducted a multi-vehicle driving simulation with a dynamic map system. In our experiments, the UDP access method using anycast addresses achieved lower latency and higher throughput than the conventional TCP access method using unicast addresses. A dynamic map system requires low latency because its real-time operation is a very important issue. In addition, for a dynamic map system that manages a large number of vehicles, it is better to have high throughput in the same environment.
Accordingly, we showed that the proposed UDP access method is effective for dynamic map systems.
However, this UDP access method cannot guarantee the arrival of data because it uses the UDP protocol, and packet loss may occur. Hence, we implemented a retransmission function using ACK to guarantee the arrival of data while using UDP. The simulation results showed that the packet loss rate was as low as that of the conventional access method. As a result, by applying the UDP access method using anycast addresses and the ACK retransmission function, we have developed a dynamic map system that provides low-latency, high-capacity communication while maintaining the same high reliability as the conventional access method. In dynamic maps with a significant impact on traffic safety, data sent from vehicles must be transmitted to edge servers in real time. In our dynamic map system, it is possible to switch the ACK retransmission function on or off. As a result, we believe that the proposed UDP access method is effective because it can be configured according to the requirements of a dynamic map application. As described in Section 2, in a dynamic map system with edge servers, the data sent by a vehicle is not always received by the desired edge server. Accordingly, for our dynamic map system, we implemented a function to transfer data between edge servers. The latency for this data transfer is a little higher than the latency when the data sent from a vehicle is received directly by the target edge server. However, this overhead was experimentally found to be very small compared to the latency of the conventional access method. In addition, the data transfer between the edge servers improved the packet loss rate and did not degrade the throughput, thus demonstrating that the proposed system is effective.
In each simulation, the number of vehicles was increased to evaluate the scalability. As a result, we found that the proposed system could handle about 9500 vehicles with low latency and high reliability, whereas the conventional access system could handle only about 5500 vehicles. This was because the bottleneck in each system is the limit of processing by physical resources. If we have more such resources, we can manage more vehicles; however, the latency of the proposed system is lower than that of the conventional access method even with more physical resources. In addition, the proposed system requires fewer resources to manage a certain number of vehicles. Overall, these results suggest that our access system is more effective than the conventional access system.
In this paper, to evaluate the specific effectiveness of the access method, we constructed a dynamic map system using wired communication to mitigate the uncertainty of wireless communication. In the future, we plan to conduct a demonstration experiment using wireless technology, which will be closer to the actual application environment. Dynamic maps will need to cover a huge number of roads in the future, and it will be necessary to assign the same anycast address to each edge server in order to access the map via anycast addresses. Therefore, we will also need to discuss the need for a provider to assign these addresses.

Conclusion
Cooperative automatic driving is actively studied to improve safety by exchanging information between vehicles and roadside equipment. Dynamic map systems are being studied; they are an information and communication platform for superimposing dynamic information such as sensor data on high-precision road maps, managing them in an integrated manner and executing applications. A vehicle always sends sensor data to the dynamic map system, and the applications on the dynamic map system need to process the aggregated data in real time and notify the results to the vehicle. Therefore, it is expected that dynamic map systems can be built on geographically distributed edge servers, which can efficiently communicate and process the data.
In a dynamic map system that deals with applications that have a large impact on traffic safety, the data sent from a vehicle must be sent to the appropriate edge server. In addition, high real-time performance is required. We propose a UDP access method using anycast addresses to access data from a vehicle to an edge server, and we conducted a simulation to evaluate the effectiveness of the method. The proposed UDP access method with anycast addresses showed superiority in throughput and latency compared with a TCP access method with unicast addresses and achieved the same reliability as TCP by implementing an ACK retransmission function.
Dynamic map systems for safe driving support and automatic driving require low-latency communication, and the amount of data communicated between vehicles and servers is expected to increase in the future. In this paper, we evaluated the effectiveness of our access method by allocating edge servers geographically on roads where vehicles travel and constructing a vehicle driving simulation environment. The effectiveness of the access method between the vehicle and the edge server was demonstrated by constructing a dynamic map system using this access method.