IPv6 Neighbor Discovery for IP-Based Vehicular Networks
Department of Software
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Department of Electrical and Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106+82 31 290 7996chrisshen@skku.edu
Department of Electrical and Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 10 9895 1211+82 31 290 7996xz618@skku.edu
Internet
IPWAVE Working GroupInternet-Draft
This document specifies a Vehicular Neighbor Discovery (VND) as an extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular networks. An optimized Address Registration and a multihop Duplicate Address Detection (DAD) mechanism are established for both operation efficiency and the saving of wireless bandwidth and vehicle energy. Also, the three new ND options for prefix discovery, service discovery, and mobility information report are used to announce the network prefixes and services inside a vehicle (i.e., a vehicle's internal network). Finally, a mobility management scheme is proposed for moving vehicles in vehicular environments to support seamless communication for the continuity of transport-layer sessions (e.g., TCP connections).
Vehicular Ad Hoc Networks (VANET) have been researched for Intelligent Transportation System (ITS) such as driving safety, efficient driving and entertainment. Considering the high-speed mobility of vehicular network based on Dedicated Short-Range Communications (DSRC), IEEE 802.11p has been specialized and was renamed IEEE 802.11 Outside the Context of a Basic Service Set (OCB) in 2012. IEEE has standardized Wireless Access in Vehicular Environments (WAVE) standard which is considered as a key component in ITS. The IEEE 1609 standards such as IEEE 1609.0 , 1609.2 , 1609.3 , 1609.4 provide a low-latency and alternative network for vehicular communications. What is more, IP-based vehicular networks specialized as IP Wireless Access in Vehicular Environments (IPWAVE) can enable many use cases over vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications.
VANET features high mobility dynamics, asymmetric and lossy connections, and moderate power constraint (e.g., electric cars and unmanned aerial vehicles). Links among hosts and routers in VANET can be considered as undetermined connectivities with constantly changing neighbors described in . IPv6 is selected as the network-layer protocol for Internet applications by IEEE 1609.0 and 1609.3. However, the relatively long-time Neighbor Discovery (ND) process in IPv6 is not suitable in VANET scenarios.
To support the interaction between vehicles or between vehicles and Rode-Side Unit (RSU), this document specifies a Vehicular Neighbor Discovery (VND) as an extension of IPv6 ND for IP-based vehicular networks. VND provides vehicles with an optimized Address Registration, a multihop Duplicate Address Detection (DAD), and an efficient mobility management scheme to support efficient V2V, V2I, and V2X communications.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 .
This document uses the terminology described in , , and .
In addition, the following new terms are defined as below:
WAVE: Acronym for "Wireless Access in Vehicular Environments"
.
Road-Side Unit (RSU): A node that has physical communication devices
(e.g., DSRC, Visible Light Communication, 802.15.4, LTE-V2X, etc.)
for wireless communications with
vehicles and is also connected to the Internet as a router or
switch for packet forwarding. An RSU is typically deployed on the
road infrastructure, either at an intersection or in a road segment,
but may also be located in car parking area.
On-Board Unit (OBU): A node that has a DSRC device for wireless
communications with other OBUs and RSUs, and may be connected to
in-vehicle devices or networks. An OBU is mounted on a
vehicle. It is assumed that a radio navigation receiver (e.g.,
Global Positioning System (GPS)) is included in a vehicle with
an OBU for efficient navigation.
Mobility Anchor (MA): A node that maintains IP addresses and
mobility information of vehicles in a road network to support
the address autoconfiguration and mobility management of them.
It has end-to-end connections with RSUs under its control.
It maintains a DAD table having the IP addresses of the vehicles
moving within the communication coverage of its RSUs.
Vehicular Cloud: A cloud infrastructure for vehicular networks,
having compute nodes, storage nodes, and network nodes.
Traffic Control Center (TCC): A node that maintains road
infrastructure information (e.g., RSUs, traffic signals, and
loop detectors), vehicular traffic statistics (e.g., average
vehicle speed and vehicle inter-arrival time per road segment),
and vehicle information (e.g., a vehicle's identifier, position,
direction, speed, and trajectory as a navigation path). TCC is
included in a vehicular cloud for vehicular networks and has
MAs under its management.
This document proposes an optimized ND, which has a more adaptive structure for
vehicular networks considering fast vehicle mobility and wireless control traffic
overhead related to the ND. Further more, prefix and service discovery can be
implemented as part of the ND's process along with an efficient Address
Registration procedure and DAD mechanism for moving vehicles. This document
specifies a set of behaviors between vehicles and RSUs to accomplish these goals.
There is a relationship between a link and a network prefix along with
reachability scopes, such as link-local and global scopes.
The legacy IPv6 ND protocol has the following link model.
All IPv6 nodes in the same on-link subnet, which use the same subnet prefix with
on-link bit set, are reachable with each other by one-hop
link. The symmetry of the connectivity among the nodes is preserved, that is,
bidirectional connectivity among two on-link nodes. On the other hand, a link model
in vehicular networks (called vehicular link model) should consider the asymmetry
of the connectivity that unidirectional links can exist due to interference in
wireless channels and the different levels of transmission power in wireless
network interfaces.
The on-link subnet can be constructed by one link (as a basic service set) or
multiple links (as an extended service set) called a multi-link subnet
. In the legacy multi-link subnet, an all-node-multicasted
packet is copied and related to other links by an ND proxy.
On the other hand, in vehicular networks having fast moving vehicles, multiple links
can share the same subnet prefix for operation efficiency. For example, if two wireless
links under two adjacent RSUs are in the same subnet, a vehicle as an IPv6 host does
not need to reconfigure its IPv6 address during handover between those RSUs. However,
the packet relay by an RSU as an ND proxy is not required because such a relay can
cause a broadcast storm in the extended subnet. Thus, in the multi-link subnet,
all-node-multicasting needs to be well-calibrated to either being confined to
multicasting in the current link or being disseminated to other links in the same subnet.
In a connected multihop VANET, for the efficient communication, vehicles in the same link
of an RSU can communicate directly with each other, not through the relay of the RSU.
This direct wireless communication is similar to the direct wired communication in an on-link
subnet using Ethernet as a wired network. The vehicular link model needs to accommodate both
the ad-hoc communication between vehicles and infrastructure communication between a vehicle
and an RSU in an efficient and flexible way.
Therefore, the IPv6 ND should be extended to accommodate the concept of a new IPv6 link model
in vehicular networks.
This document takes advantage of the optimized ND for Low-Power Wireless
Personal Area Network (6LoWPAN)
because vehicular environments have common parts with 6LoWPAN, such as the
reduction of unnecessary wireless traffic by multicasting and the energy saving
in battery. Note that vehicles tend to be electric vehicles whose energy source
is from their battery.
In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are assumed
to be asymmetric and unidirectional because of changing radio environment and
loss signal. The authors proposed an improved IPv6 ND which greatly eliminates
link-scope multicast to save energy by constructing new options and a new scheme
for address configurations. Similarly, this document proposes an improved IPv6 ND
by eliminating many link-scope-multicast-based ND operations, such as DAD for
IPv6 Stateless Address Autoconfiguration (SLAAC) .
Thus, this document suggests an extension of IPv6 ND as vehicular ND tailored
for vehicular networks along with new ND options (e.g., prefix discovery, service
discovery, and mobility information options).
The vehicular ND in this document has the following design goals:
To perform prefix and service discovery through ND procedure;
To implement host-initiated refresh of Router Advertisement (RA) and remove the need
for routers to use periodic or unsolicited multicast RA to find hosts;
To create Neighbor Cache Entries (NCE) for all registered vehicles in RSUs by adding
Address Registration Option (ARO) in Neighbor Solicitation (NS),
Neighbor Advertisement (NA) messages;
To support a multihop DAD with two new ICMPv6 messages called Duplicate Address
Request(DAR) and Duplicate Address Confirmation(DAC) to eliminate multicast storm and
save energy; and
To provide a mobility management mechanism for seamless communication during a
vehicle's travel in subnets via RSUs.
This section describes a vehicular network architecture for V2V and V2I communication.
A vehicle and an RSU have their internal networks having in-vehicle devices or servers,
respectively.
A vehicular network architecture for V2I and V2V is illustrated in . Three RSUs are deployed along roadside and are connected to an MA through wired links.
There are two subnets such as Subnet1 and Subnet2. The wireless links of RSU1 and RSU2 belong to the same subnet
named Subnet1, but the wireless link of RSU3 belongs to another subnet named Subnet2.
Vehicle1 and Vehicle2 are wirelessly connected to RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 and RSU3, respectively. Vehicles can directly communicate with each other through V2V connection (e.g., Vehicle1 and Vehicle2) to share driving information. Vehicles are assumed to start the connection to an RSU when they entered the coverage of the RSU.
The document recommends a multi-link subnet involving multiple RSUs, as shown in . This recommendation aims at the reduction of the frequency with which vehicles have to change their IP address during handover between two adjacent RSUs. When they pass through RSUs in the same subnet, vehicles do not need to perform the Address Registration and DAD again because they can use their current IP address in the wireless coverage of the next RSU, belonging to the same subnet. On the other hand, if they enter the wireless coverage of an RSU belonging to another subnet with a different prefix, vehicles repeat the Address Registration and DAD procedure to update their IP address with the new prefix.
In , RSU1 and RSU2 are deployed in the a multi-link subnet with the same prefix in their address. When vehicle1 leaves the coverage of RSU1 and enters RSU2, it maintains its address and ignores Address Registration and DAD steps. If vehicle1 moves into the coverage of RSU3, since RSU3 belongs to another subnet and holds a different prefix from RSU1 and RSU2, so vehicles must do Address Registration and DAD just as connecting to a new RSU.
Note that vehicles and RSUs have their internal networks having in-vehicle devices and servers, respectively.
The structures of the internal networks are described in .
This subsection explains V2I internteworking between vehicle network and RSU network
where vehicle network is an internal network in a vehicle, and RSU network is
an internal network in an RSU, as shown in .
shows the V2I networking of a vehicle and an RSU whose internal networks are Moving Network1 and Fixed Network1, respectively.
Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2).
RSU1 has the DNS Server (RDNSS3), one host (Host5), the two routers (Router5 and Router6).
It is assumed that RSU1 has a collection of servers (Server1 to ServerN) for various services in the road networks, such as road emergency notification and navigation services. Vehicle1's Router1 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for I2V networking for various vehicular services.
The vehicular applications, such as road emergency notification and navigation services, can be registered into the DNS Server (i.e., RDNSS) through DNSNA protocol in along with IPv6 ND DNS options in .
Vehicle1's Router1 and RSU1's Router5 can know what vehicular applications exist in their internal network by referring to their own RDNSS through the DNSNA protocol . They can also know what network prefixes exist in their internal network through an intra-domain routing protocoli, such as OSFP.
Each vehicle and each RSU announce their network prefixes and services through ND options defined in .
This subsection explains V2V internteworking between vehicle networks,
which are internal networks in vehicles, as shown in .
shows the V2V networking of two vehicles whose internal networks are Moving Network1 and Moving Network2, respectively.
Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2).
Vehicle2 has the DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two routers (Router3 and Router4).
It is assumed that Host1 and Host3 are running a Cooperative Adaptive Cruise Control (C-ACC) program for physical collision avoidance. Also, it is assumed that Host2 and Host4 are running a Cooperative On-board Camera Sharing (C-OCS) program for sharing road hazards or obstacles to avoid road accidents.
Vehicle1's Router1 and Vehicle2's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for V2V networking for various vehicular services. The vehicular applications, such as C-ACC and C-BCS, can be registered into the DNS Server (i.e., RDNSS) through DNSNA protocol in along with IPv6 ND DNS options in .
Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular applications exist in their internal network by referring to their own RDNSS through the DNSNA protocol . They can also know what network prefixes exist in their internal network through an intra-domain routing protocoli, such as OSFP.
Each vehicle announces its network prefixes and services through ND options defined in .
This section specifies an IPv6 ND extension for vehicle-to-vehicle (V2V) or
vehicle-to-infrastructure (V2I) networking.
This section also defines three new ND options for prefix discovery, service discovery, and
mobility information report:
(i) Vehicular Prefix Information (VPI) option, (ii) Vehicular Service Information (VSI) option,
and (iii) Vehicular Mobility Information (VMI) option. It also describes the procedure of
the ND protocol with those options.
The VPI option contains IPv6 prefix information in the internal network.
shows the format of the VPI option.
The VSI option contains vehicular service information in the internal network.
shows the format of the VSI option.
The VMI option contains one vehicular mobility information of a vehicle or an RSU.
shows the format of the VMI option.
Prefix discovery enables hosts (e.g., vehicles and in-vehicle devices) to distinguish destinations
on the same link from those only reachable via RSUs. A vehicle (or its in-vehicle devices) can
directly communicate with on-link vehicles (or their in-vehicle devices) without the relay of
an RSU, but through V2V communications along with VPI ND option. This VPI option contains
IPv6 prefixes in a vehicle's internal network.
Vehicles announce services in their internal networks to other vehicles through an VSI ND option.
The VSI option contains a list of vehicular services in a vehicle's or an RSU's internal network.
A vehicle periodically announces an NS message containing VPI and VSI options with
its prefixes and services in all-nodes multicast address to reach all neighboring nodes.
When it receives this NS message, another neighboring node responds to this NS message by sending
an NA message containing the VPI and VSI options with its prefixes and services via unicast towards
the NS-originating node.
Therefore, prefix and service discovery can be achieved via ND messages (e.g., NS and NA) by
vehicular ND with VPI and VSI options. This VND-based discovery eliminates an additional
prefix and service discovery scheme, such as DNS-based Service Discovery
(e.g., Multicast DNS (mDNS) and DNSNA ),
other than ND. That is, vehicles and RSUs can rapidly discover the network prefixes and
services of the other party without any additional service discovery protocol.
This subsection explains a message exchange procedure for vehicular neighbor discovery in V2I networking,
where a vehicle communicates with its correponding node in the Internet via an RSU.
shows an example of message exchange procedure in V2I networkging.
The detailed steps of the procedure are explained in
and .
Note that a vehicle could also perform the prefix and service discovery simultaneously along with
Address Registration procedure, as shown in .
Note that RSUs as routers do not transmit periodical and unsolicited multicast RA messages including a prefix for energy saving in vehicular networks. Vehicles as hosts periodically initiate an RS message according to a time interval (considering its position and an RSU's coverage). Note that since they have a digital road map with the information of RSUs (e.g., position and communication coverage), vehicles can know when they will go out of the communication range of an RSU along with the signal strength (e.g., Received Channel Power Indicator (RCPI) ) from the RSU. RSUs replies with a solicited RA in unicast only when they receive an RS message.
This section explains address configuration, consisting of IP Address Autoconfiguration, Address Registration, and multihop DAD.
This document recommends a new Address Registration and DAD scheme in order to avoid multicast flooding and decrease link-scope multicast for energy and wireless channel conservation on a large-scale vehicular network. Host-initiated refresh of RA removes the need for routers to use periodic and unsolicited multicast RAs to accommodate hosts. This also enables the same IPv6 address prefix(es) to be used across a subnet.
There are two scenarios about Address Registration part. If they have already configured their IP addresses with the prefix obtained from the previous RSU, and the current RSU located in the same subnet as the previous RSU, which means that they have the same prefix, then vehicles have no need to repeat the Address Registration and multihop DAD. However, if the current RSU belongs to another subnet, vehicles need to perform the Address Registration and multihop DAD in the following subsections.
A vehicle as an IPv6 host creates its link-local IPv6 address and global IPv6 address as follows . When they receive RS messages from vehicles, RSUs send back RA messages containing prefix information. The vehicle makes its global IPv6 addresses by combining the prefix for its current link and its link-layer address.
The address autoconfiguration does not perform the legacy DAD as defined in . Instead, a new multihop DAD is performed in .
After its IP tentative address autoconfiguration with the known prefix from an RSU
and its link-layer address, a vehicle starts to register its IP
address to the serving RSU along with multihop DAD.
Address Register Option (ARO) is used in this step and its format is defined in .
ARO is always host-initiated by vehicles. The information contained in ARO becomes included in multihop Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages used between RSU and MA, but ARO is not directly used in these two messages.
An example message exchange procedure of Address Registration is presented in . Since Address Registration is performed simultaneously with the multihop DAD, the specific procedure is together described with the DAD mechanism in .
Before it can exchange data, a node should determine whether its IP address is already used by another node or not. In the legacy IPv6 ND, hosts multicast NS messages to all nodes in the same on-link subnet for DAD. Instead of this, an optimized multihop DAD is designed to eliminate multicast messages for energy-saving purpose. For this multihop DAD, Neighbor Cache and DAD Table are maintained by each RSU and an MA, respectively, for the duplicate address inspection during the multihop DAD process.
That is, each RSU makes Neighbor Cache Entries (NCE) of all the on-link hosts in its Neighbor Cache. Similarly, the MA stores all the NCEs reported by the RSUs in its DAD Table.
With the multihop DAD, a vehicle can skip the multicast-based DAD in its current wireless link whenever it enters the coverage of another RSU in the same subset, leading to the reduction of traffic overhead in vehicular wireless links.
For the multihop DAD, two new ICMPv6 message types are defined in , such as Duplicate Address Request (DAR) and the Duplicate Address Confirmation (DAC).
Information carried by ARO options are copied into these two messages for the multihop DAD in the MA.
presents the procedure of Address Registration and multihop DAD. The detailed steps are explained as follows.
A vehicle sends an NS message to the current RSU in unicast, containing the ARO to RSU to register its address.
The RSU receives the NS message, and then inspects its Neighbor Cache to check whether it is duplicate or not.
If there is no duplicate NCE, a tentative NCE is created for this address, and then the RSU sends a DAR to the
MA for the multicast DAD.
When the MA receives a DAR from an RSU, it checks whether the register-requested address exists in its DAD Table or not. If an entry with the same address exists in the DAD Table, which means that the address is considered "Duplicate Address", then MA returns a DAC message to notify the RSU of the address duplication. If no entry with the same address exists in the DAD Table, which means that an entry for the address is created, then MA replies a DAC message to the RSU to confirm the uniqueness of the register-requested address to the RSU.
If the address duplication is notified by the MA, the RSU deletes the tentative NCE, and sends back an NS to the address-registration vehicle to notify the registration failure.
Otherwise, the RSU changes the tentative NCE into a registered NCE in its Neighbor Cache, and then send back an NS to the vehicle to notify the registration success.
Thus, the multihop DAD is processed simultaneously with the Address Registration. Note that the tentative address is not considered assigned to the vehicle until the MA confirms the uniqueness of the register-requested address in the multihop DAD.
Considering the privacy protection of a vehicle, a pseudonym mechanism for its link-layer address is requested.
This mechanism periodically modifies the link-layer address, leading to the update of the corresponding IP address. A random MAC Address Generation mechanism is proposed in Appendix F.4 of by generating the 46 remaining bits of MAC address using a random number generator. When it changes its MAC address, a vehicle should ask the serving RSU to update its own NCE, and to register its IP address into the MA again.
A mobility management is required for the seamless communication of vehicles moving between the RSUs.
When a vehicle moves into the coverage of another RSU, a different IP address is assigned to the vehicle, resulting in the reconfiguration of transport-layer session information (i.e., end-point IP address) to avoid service disruption. Considering this issue, this document proposes a handover mechanism for seamless communication.
In , the authors constructed a network-based mobility management scheme using Proxy Mobile IPv6 (PMIPv6) , which is highly suitable to vehicular networks. This document uses a mobility management procedure similar to PMIPv6 along with prefix discovery.
shows the binding update flow when a vehicle entered the subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined in . When it receives RS messages from a vehicle containing its mobility information (e.g., position, speed, and direction), an RSU sends its MA a Proxy Binding Update (PBU) message , which contains a Mobility Option for the vehicle's mobility information. The MA receives the PBU and sets up a Binding Cache Entry (BCE) as well as a bi-directional tunnel (denoted as Bi-Dir Tunnel in ) between the serving RSU and itself. Through this tunnel, all traffic packets to the vehicle are encapsulated toward the RSU. Simultaneously, the MA sends back a Proxy Binding Acknowledgment (PBA) message to the serving RSU. This serving RSU receives the PBA and sets up a bi-directional tunnel with the MA. After this binding update, the RSU sends back an RA message to the vehicle including its own prefix for the address autoconfiguration.
When the vehicle changes its location, the MA has to change the end-point of the tunnel for the vehicle into the new RSU's IP address. As shown in , when the MA receives a new PBU from the new RSU, it changes the tunnel's end-point from the current RSU (c-RSU) to the new RSU (n-RSU). If there is ongoing IP packets toward the vehicle, the MA encapsulates the packets and then forwards them towards the new RSU. Through this network-based mobility management, the vehicle is not aware of any changes at its network layer and can maintain its transport-layer sessions without any disruption.
This document shares all the security issues of the neighbor discovery
protocol and 6LoWPAN protocol. This document can get benefits from secure neighbor discovery
(SEND) in order to protect ND from possible
security attacks.
Key words for use in RFCs to Indicate Requirement LevelsInternet Protocol, Version 6 (IPv6) SpecificationNeighbor Discovery for IP Version 6 (IPv6)IPv6 Stateless Address AutoconfigurationIPv6 Router Advertisement Options for DNS ConfigurationNeighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) Proxy Mobile IPv6Mobility Support in IPv6SEcure Neighbor Discovery (SEND)IP Addressing Model in Ad Hoc NetworksDNS-Based Service DiscoveryMulticast DNSIP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use CasesDNS Name Autoconfiguration for Internet of Things DevicesNotes on DSRC & WAVE Standards Suite: Its Architecture, Design, and CharacteristicsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular EnvironmentsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) SpecificationsIEEE Guide for Wireless Access in Vehicular Environments (WAVE) - ArchitectureIEEE Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management MessagesIEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking ServicesIEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel OperationVIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks
The following changes are made from draft-jeong-ipwave-vehicular-neighbor-discovery-04:
This version includes the contents of the IPv6 vehicular neighbor discovery in
draft-xiang-ipwave-vehicular-neighbor-discovery-00 for IP-based vehicular networks.
In ,
a Vehicular Mobility Information (VMI) option is defined to report
the mobility information of a vehicle or an RSU.
This work was supported by Basic Science Research Program through the
National Research Foundation of Korea (NRF) funded by the Ministry of
Education (2017R1D1A1B03035885).
This work was supported in part by Global Research Laboratory Program
through the NRF funded by the Ministry of Science and
ICT (MSIT) (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program
of the MSIT (18-EE-01).