Enhancing the 3GPP V2X Architecture with Information-Centric Networking

Abstract

Vehicle-to-everything (V2X) communications allow a vehicle to interact with other vehicles and with communication parties in its vicinity (e.g., road-side units, pedestrian users, etc.) with the primary goal of making the driving and traveling experience safer, smarter and more comfortable. A wide set of V2X-tailored specifications have been identified by the Third Generation Partnership Project (3GPP) with focus on the design of architecture enhancements and a flexible air interface to ensure ultra-low latency, highly reliable and high-throughput connectivity as the ultimate aim. This paper discusses the potential of leveraging Information-Centric Networking (ICN) principles in the 3GPP architecture for V2X communications. We consider Named Data Networking (NDN) as reference ICN architecture and elaborate on the specific design aspects, required changes and enhancements in the 3GPP V2X architecture to enable NDN-based data exchange as an alternative/complementary solution to traditional IP networking, which barely matches the dynamics of vehicular environments. Results are provided to showcase the performance improvements of the NDN-based proposal in disseminating content requests over the cellular network against a traditional networking solution.

1. Introduction

Future automotive services will require a high level of connectivity of vehicles with other vehicles and with communication parties located in the surrounding environment (i.e., pedestrians and road-side infrastructure) and also farther away (e.g., edge/cloud servers and Internet facilities). Such services call for a flexible and high-performing air interface and for other architectural and protocol workarounds that can enable timely and reliable vehicle-to-everything (V2X) data exchange under a paradigm also referred to as Internet of Vehicles (IoV) [1].

The Third Generation Partnership Project (3GPP), after releasing the Long Term Evolution (LTE) specifications for V2X in Releases 14 and 15, is currently discussing further enhancements for Release 16, in order to meet the most demanding V2X performance requirements in alignment with the fifth-generation (5G) system specifications. 3GPP has adopted Cellular-V2X (C-V2X) as a general term covering all interfaces and release enhancements for V2X communications. C-V2X relies on two air interfaces [2]: (i) the LTE-Uu interface, the conventional LTE uplink/downlink air interface; and (ii) the PC5 interface, also known as the sidelink, which supports direct communications among V2X nodes. The LTE-Uu interface can be useful to interconnect a vehicle to a cloud/edge server; the PC5 interface bypasses the cellular infrastructure and supports communications among vehicles in proximity exchanging, for example, road context information.

Similarly to what is happening in other V2X relevant Standard Developing Organizations (SDOs), such as the European Telecommunications Standards Institute (ETSI) and the Institute of Electrical and Electronics Engineers (IEEE), 3GPP is open to consider networking solutions that replace and/or work alongside the traditional Internet Protocol (IP), on top of the mentioned radio access interfaces [2]. The motivation is twofold. First, IP poorly supports one-to-many communications such as multicast and broadcast, which are expected to be the dominant communication mode in the V2X ecosystem. For example, road traffic information or an accident notification are to be delivered to all vehicles located in a relevant geographical area. Second, IP barely matches scenarios where the identity of the communication end-points is either not known in advance or may change. For example, when a vehicle addresses other vehicles in its neighborhood for cooperative driving purposes, it does not know the identity of its neighbors, and the neighbors dynamically change due to mobility.

Among non-IP protocols, in the last decade Information-Centric Networking (ICN) [3] has catalyzed the interest of the vehicular networking community, and not only, as a complementary/alternative solution to IP [4]. ICN turns the traditional IP host-centric philosophy into an approach with the information at the center of attention. This means that while an IP consumer needs the IP address of the host to connect with it and have access to the hosted data content; with ICN the content can be directly retrieved using its (unique) name without referring to the identity of the node generating or holding it. ICN and, in particular, its instantiation Named Data Networking (NDN) (www.named-data.net), well fits the vehicular applications context, which privileges the information to gather (e.g., road traffic conditions in a relevant area and parking lot availability in the city center) rather than the identity of the information provider (e.g., the advertising car). The connectionless transport model of NDN, which does not require the simultaneous connection of consumer and provider to retrieve data, meets the dynamics of the vehicular environment. NDN is based on the exchange of Interest and Data packets, respectively, used (by the consumer) to request and (by the provider) to deliver a named piece of information (i.e., content). Other NDN features that clearly favor mobile communications include in-network caching that enables each node storing the content to be a provider, and security at a packet-level based on the signature on each piece of content [4].

Plenty of literature solutions [4] have investigated the application of NDN principles to IEEE 802.11p-based (please notice that the 802.11 p amendment has been superseded and has become part of the IEEE 802.11 standard; hence, in the following, we simply refer to 802.11) vehicular networks. Conversely, NDN has not been neatly advocated thus far for the C-V2X technology; this would entail further investigation due to the peculiarities of the 3GPP cellular system architecture and operation, which are radically different from IEEE 802.11. First, the radio resource assignment for localized direct communications among vehicles over the PC5 interface can be orchestrated in a centralized manner by the cellular network infrastructure (i.e., the eNodeB). This is a clear departure from 802.11-based solutions characterized by a distributed access to radio resources. Second, the cellular infrastructure may enlarge the scope of communications beyond localized single-hop interactions with no need to rely on multi-hop forwarding mechanisms, as IEEE 802.11 does, but resorting to broadcast/multicast over a single cell or multiple cells. Indeed, the cellular technology is very versatile in supporting different communication primitives as required by V2X services.

Such facts motivated our study, aimed at filling the current gap and presenting our vision about the role of NDN as a key networking technology for 3GPP V2X communications. To the best of our knowledge, this is the first work that clearly advocates the NDN usage for C-V2X communications while being aligned with ongoing 3GPP specifications. The main original contributions of this work can be summarized as follows:

• We advocate NDN as a feasible network-layer option to be included within the purpose-built C-V2X architecture specified by the 3GPP. NDN can: (i) work alongside the legacy IP; and/or (ii) complement other non-IP based solutions conceived so far for V2X safety data delivery.
• We propose a set of design changes and enhancements to the 3GPP C-V2X architecture to fully enable NDN among the other non-IP networking solutions already supported. Such changes mainly encompass new functionalities in the V2X entities and other 3GPP network elements, new packet processing and resource allocation algorithms, novel packet fields. The viability of such modifications is also discussed and the performance is evaluated to unveil the benefits compared to a baseline non-NDN approach.

The remainder of this paper is organized as follows. Section 2 presents some basics of the 3GPP specifications for V2X communications. NDN pillars are discussed in Section 3, where the NDN literature for vehicular communications is also scanned. The contributions of the works are summarized in Section 4, where the design features for the integration of NDN in the 3GPP V2X architecture are also discussed. The NDN forwarding strategy for 3GPP V2X communications is presented in Section 5. The evaluation methodology and the simulation settings are presented in Section 6. The results are reported in Section 7, which showcases the benefits of the proposed framework when compared against a baseline (non-NDN) approach. Conclusions are summarized in Section 8 with hints on future works.

2. V2X Communications in 3GPP

The role of 3GPP cellular networks in supporting V2X communications has been rapidly and steadily growing. Motivations for such an acceleration are manifold.

Available ubiquitous network infrastructure. Unlike IEEE 802.11, the cellular technology can rely on an already deployed ubiquitous network infrastructure, which eases the implementation of C-V2X and may accelerate its deployment on a large scale. This makes C-V2X a cost-effective solution that will incur a little-to-none time-to-market, with Mobile Network Operators (MNOs) taking the lion’s share.

5G-native ultra-low latency and high reliability support. 3GPP has a clear roadmap to provide ultra reliable and ultra-low latency communication (URLLC) in high-mobility environments through the 5G technology. URLLC is crucial for many V2X applications (e.g., fully autonomous driving, remote driving, and high-density vehicle platooning), which makes the automotive vertical an undoubted key driver for 5G systems.

Reuse of existing upper-layer protocols. Since upper-layer protocols, such as message sets, and service and application layers, by ETSI, Society of Automotive Engineers (SAE) and other SDOs, have been specified to be media-agnostic, they can be easily reused by 3GPP, whose main duty is then to focus on the access interface and network architecture specifications.

2.1. V2X Communication Modes and Entities

Four V2X communication modes are identified by 3GPP [5], with different scope and encompassing different communication end-points, as illustrated in Figure 1 and summarized in

Table 1. Main features of V2X communication modes.

Communication Modes	V2V, V2P, V2I	V2N
Radio interface	PC5	LTE-Uu
Spectrum	5.9 GHz	3.5 GHz
Traffic primitive	Multicast/Broadcast	Unicast, Multicast (eMBMS)
Traffic type	IPv6, non-IP	IPv6
Access mode	Newly added Scheduled and Autonomous modes	Legacy mode

.

Vehicle-to-vehicle (V2V) and vehicle-to-pedestrian (V2P), respectively, cover direct communication between vehicular user equipments (VUEs) and between VUEs (for the sake of simplicity, in the following, we refer to VUEs as UEs only) and vulnerable road users (VRUs), such as pedestrians, bikers, and motorcyclists. Vehicle-to-infrastructure (V2I) refers to communications between vehicles and the roadside infrastructure, e.g., a road-side unit (RSU). Vehicle-to-network (V2N) allows UEs to interact with a server specifically introduced in the 3GPP architecture to support V2X applications. Such a server is referred to as V2X Application Server (AS) and gathers information about the road and traffic conditions from several sources (UEs, RSUs, infrastructure modes such as traffic lights, etc.). The V2X AS could be deployed outside the 3GPP network (e.g., by the transportation authority) or at the Radio Access Network (RAN) premises, according to the Multi-Access Edge Computing (MEC) paradigm [6].

In the 3GPP V2X architecture, a central role is undertaken by the V2X Control Function, implemented in the core network, which is responsible for enforcing V2X network-related actions. In particular, it provides the UEs with specific configuration parameters that allow them using V2X communications in a given network, under coverage of the eNodeB as well as when they are not served by the cellular infrastructure, i.e., in out-of- coverage scenarios.

2.2. V2X Communications over the PC5 Interface

In 3GPP Release 14 [7], the PC5 interface has been initially customized to handle V2X communications, as discussed in the following.

Operation modes. The access layer of the PC5 interface has been optimized to work in environments with high node mobility and under high-density conditions. Two schemes for the allocation of radio resources have been specified:

• Mode 3 (or scheduled), according to which resource scheduling and interference management on the sidelink are assisted by the eNodeB, via control signaling over the LTE-Uu interface.
• Mode 4 (or autonomous), according to which resource scheduling and interference management on the sidelink are based on distributed algorithms implemented in vehicles. It is the only option for out-of-coverage conditions.

Broadcast communications. V2X communications over the PC5 interface are inherently broadcast, typically targeting multiple (either unknown) nodes with a single transmission. They are also connectionless: no signalling for connection establishment and neighbor discovery procedures is required on the sidelink [2]. This is to ensure that critical data (e.g., safety alerts) are promptly exchanged in a dynamic environment, where the topology rapidly changes and, consequently, connectivity is short lived.

Multiple networking protocols. Both IP-based (IPv6) and non-IP based V2X messages are allowed in the 3GPP V2X architecture [2]. The major case for non-IP protocol support is the IEEE 1609 WAVE Short Message Protocol (WSMP) [8] specified for V2X safety communications, which can run directly on top of layer 2 without the burden of the IP overhead.

2.3. V2X Communications over the LTE-Uu Interface

The LTE-Uu interface supports unicast and multicast connections.

Unicast communications. Unicast connections allow data exchange between one UE and the eNodeB, in both uplink (UL) and downlink (DL) directions. If a UE does not have pre-allocated radio resources, it has to request them to the eNodeB via dynamic scheduling. The UE sends its request for a transmission grant once a packet arrives at its buffer (UEs are in connected mode to avoid the initial access delay due to the random access procedure). Specifically, it sends a buffer status report (BSR) to notify the eNodeB about the amount of buffered data and its priority. Then, the UE waits for a Scheduling Request (SR) period to send an SR message to the eNodeB. On the basis of the received request, the eNodeB will schedule the resources to be allocated and send this configuration information back to the requesting UE. Eventually, the UE will transmit the packet over the resources allocated by the eNodeB.

Multicast communications. V2X messages can be efficiently disseminated to multiple UEs in DL through the evolved Multimedia Broadcast Multicast Service (eMBMS) specified by 3GPP [9]. The V2X AS is responsible for the reception of UL unicast data from the UEs and for the identification of the target reception area (a cell or multiple cells) to be covered by the eMBMS transmission.

3. NDN for V2X Communications

Several ICN architectures have been proposed thus far that share the same principles at the network layer but differ in the implementation details [3]. Among them, NDN [10] has been mainly considered as the reference architecture for vehicular environments, thanks to its effective data delivery mechanism and robust security support [11]. Research works have been dealing with NDN-based V2X networks, mainly focused on name-based forwarding strategies. In the following, after summarizing the basics of the NDN architecture, we give an overview of the current state of the art about NDN for V2X networking.

3.1. NDN Basics

In NDN, the original content is segmented into chunks, which are individually named and secured. The resulting unit may be transmitted in a single Data packet or further fragmented and transferred over the channel in more than one packet of smaller size. NDN follows a receiver-driven approach: an Interest is used to request a given named Data packet.

NDN names are application-specific and hierarchically structured. For instance, a video produced in a classroom during the maths lecture at the university of Reggio Calabria (UNIRC) may have the name /unirc/videos/classrooms/maths.mpg, where “/” delineates name components in text representations, similar to Uniform Resource Locators (URLs).

An NDN consumer, i.e., an end device interested in a given content, includes the content name in an Interest packet and sends it to the network without specifying a destination address. The network nodes apply a forwarding-by-name mechanism to move the request toward the source(s) generating or owning that content. The node(s) will return a Data packet that contains the content with the addressed name. Data packets are signed by the content source with its key so that the consumer and any network node can check the packets authentication and integrity. As a result, NDN natively overcomes many conventional security attacks [11] and represents a valid alternative to other security frameworks (e.g., [12]).

The Interest processing at each NDN node involves three tables: (i) the Content Store (CS) that is used to cache incoming Data packets; (ii) the Pending Interest Table (PIT) that keeps track of all incoming unsatisfied Interests with the related incoming node’s interfaces (named faces in NDN terminology); and (iii) the Forwarding Information Base (FIB) that records, per each name prefix, one or more outgoing faces for the Interest packets forwarding. The FIB can be dynamically populated by a routing protocol [13].

Specifically, at the Interest reception, a node N first looks up in its CS for a matching content. If it is found, then the cached Data packet is returned to the consumer. Conversely, N looks up in the PIT for the same pending request. If a PIT entry for the same content already exists, then it is updated with the new incoming face and the Interest is discarded; otherwise, a FIB look-up is performed. If a matching is found in the FIB, then the Interest is forwarded towards the next hop(s) through the face(s) stored in the FIB, otherwise it is discarded. As soon as a node owning the content is reached, the Data packets follow the chain of PIT entries back to the consumer(s). Data packets can be cached by en-route nodes and made available for future requests.

Two main decision engines are implemented at the NDN forwarding plane that may affect the data retrieval performance:

• The forwarding strategy permits each NDN node to take actions related to the Interest forwarding, specifically to decide if, when and where forwarding the packet. Depending on the application requirements, the strategy may prioritize the delivery of certain packets or even transmit them in parallel over multiple interfaces. In the case of transmission over a wireless medium with access procedures managed in a distributed manner, the node may defer the packets in order to limit the collision probability with other potentially transmitting nodes. In the case that no route is available in the FIB, it may issue a negative acknowledgement (NACK) message indicating the error type toward the previous node.
• The content caching/replacement strategy permits each NDN node to decide whether to cache the incoming Data packet(s) and which buffered packets to replace in the case the CS is full. The simplest and most intuitive cache-and-replacement strategy implemented in NDN is cache-everything-everywhere with Least Frequently Used (LFU) replacement. This means that all nodes cache all Data packets and replace the least requested ones. More advanced policies have been proposed for data caching and replacement [14], with decisions performed according to a variety of parameters such as content popularity, freshness, and geographical validity of information.

3.2. NDN-Based Content Delivery for V2X: An Overview

Related work on vehicular NDN mainly focused on effective and low-overhead forwarding strategies for the IEEE 802.11 access technology, with only a few works [15,16] analyzing hybrid cellular-IEEE 802.11 V2X deployments.

When considering Interest/Data forwarding, the following main aspects have been explored thus far: (i) the design of content retrieval schemes over the shared IEEE 802.11 wireless medium; (ii) the design of reliable transport services; (iii) the design of prioritized transmission schemes that distinguish contents with different requirements, e.g., in terms of latency; and (iv) the definition of transmission schemes over hybrid network access (i.e., cellular/802.11).

Content retrieval schemes. After receiving an Interest and performing CS and PIT lookup without finding a matching, vehicles have to apply a forwarding logic to decide if they can further forward the packet or not, based on the FIB content.

The forwarding schemes available in the literature can be distinguished into (i) pure broadcast-based schemes, where only broadcast transmissions are enforced with a controlled-flooding mechanism used during Interest forwarding; and (ii) unicast-based schemes, where after an initial content discovery phase based on broadcasting, Interests are forwarded in unicast mode from node to node (this type of forwarding is possible in NDN provided that the identifier of the next-hop, e.g., the IP address [17] or the MAC address [18], is tracked in the FIB).

Unicast-based schemes reduce the adverse broadcast storm effect due to multi-hop Interest broadcasting (in multi-hop wireless networks, broadcast storm is defined as a condition in which, due to a high number of broadcasted packets, nodes may experiment a high level of contention and collisions at the link layer [19]), as demonstrated in [17,18]. However, these schemes may suffer from connectivity breakages due to node mobility and harsh propagation conditions, and may limit the data sharing capability of the wireless medium, enabled by packets overhearing and distributed in-network caching. This is why, thus far, the majority of the works on vehicular NDN have preferred broadcast-based schemes enhanced with proper broadcast storm mitigation mechanisms and/or self-eligibility forwarding decisions that nodes can implement during the data retrieval. In particular, in [20], a vehicle is considered an eligible forwarder only if it is in the path towards the data source, which has been discovered during a preliminary flooding stage. In [21], the authors presented the Distributed Interest Forwarder Selection (DIFS) algorithm, where eligible forwarders are only the vehicles that have maximum connectivity time and good link quality with the consumer. In [22], instead, eligible forwarding vehicles are selected based on the neighbor distance, node density, and the closeness to the consumer.

Forwarding metrics can be carried in the Interest and/or Data packets and can be considered to further improve the forwarding decision. For instance, in [23], to maximize the packet dissemination scope, Interests carry the geographical position of the sender, and the best forwarder is identified as the farthest away node from the sender. In [24], such position-based forwarding strategy is further extended with information about the vehicle trajectory, while, in [25], vehicles consider both their distance from the previous sender and from the target data source.

The forwarding decision is usually coupled with a channel overhearing mechanism to further limit packet collisions and redundancy. A defer time is calculated before each Interest transmission: if the same packet or the related Data is overheard during the waiting time, the Interest packet is dropped. To further control the Interests propagation, time-to-live (TTL) information, such as the hop count, can be included in the packet [26].

Reliable transport. Although the above-mentioned schemes can be very effective in limiting packet collisions, the percentage of packet losses in vehicular environments can still be huge, due to adverse propagation effects and mobility. It is therefore crucial to design robust packet retransmission schemes to quickly recover from losses. Being a content usually composed of multiple Data packets, the authors of [27] proposed to extend the Interest header with a bitmap field indicating the missing packets of a content chunk. A retransmission time-out (RTO), estimated as a moving average of round-trip-time samples, is maintained by the consumer. When the RTO expires, the Interest is retransmitted with the bitmap set to request selected (missing) Data packets.

Bouk et al. [28] observed that frequent Interest/Data loss over the wireless channel may cause adverse effects on the PIT size. Indeed, each Interest is maintained in the PIT until it is consumed by the Data or the PIT Entry Lifetime (PEL) expires. A PEL of 4 s is usually considered in the vanilla NDN implementation, but such a static value can be too high in the vehicular scenario. The authors of [28], instead, proposed a hop limit based adaptive PIT Entry Lifetime (LAPEL) scheme, which adaptively estimates the PEL at each Interest forwarding vehicle. By doing so, the PIT scalability and a more reliable transport service are achieved.

Prioritized transmissions. Vehicular applications may have different requirements in terms of latency, throughput and reliability. These requirements can be codified into well-defined name prefixes and translated into differentiated treatments at the NDN layer. For instance, the work in [29] uses two main name prefixes, /high and /low, to identify the content priority and to set accordingly the logic for the defer time calculation before (re-)broadcasting the packet. Similarly, in [30], content priorities are used by vehicles to compute the defer time, but they are codified with integer values and included as an additional header field in the Interest packet. For instance, value 1 is assigned to road conditions information that have the highest priority, value 2 is assigned to vehicle status information, value 10 to social media information and so on.

Hybrid cellular-IEEE 802.11 forwarding. To improve the delivery performance and reduce the network congestion, the work in [15] proposes to forward Interest and Data packets over different network interfaces. Instead of using IEEE 802.11 to convey all messages, signaling information (i.e., Interest packets) are transmitted over the cellular network, while Data are transmitted over ad hoc contacts. This solution offloads the cellular network of Data exchange, and guarantees that content requests reach the interested nodes with a high probability. In [16], instead, vehicles can use the cellular and the IEEE 802.11 interfaces in parallel, if the application requires high reliability and low latency.

4. Including NDN in the 3GPP V2X Architecture

4.1. Gap Analysis and Contribution of This Paper

Thanks to its built-in name-based data delivery and in-network caching features, ICN has been recognized by 3GPP and big industrial telco players, such as Intel, Cisco, and Huawei, as a key enabler for latency reduction and bandwidth savings in the core transport and backhaul segments of 5G systems [31]. Recently, an interesting discussion about the ICN deployment in cellular networks has started within some Internet Research Task Force (IRTF) groups. In [32], the authors preliminarily proposed to leverage the non-IP protocol capabilities included in 3GPP LTE Release 13 and onward specifications, to deploy the ICN protocol stack in all involved nodes, such as UEs, eNodeBs, and core network gateways. The authors of [32] argued that deploying ICN in the eNodeB is crucial for an efficient data transfer between the eNodeB and the mobile gateways in the core network. In [33], a proof of concept is presented to showcase an ICN-based RAN for 4G networks. Such works legitimate the viability of our proposal targeting the NDN deployment in UEs and eNodeBs.

In [34], the potential of ICN in 5G systems and, specifically, in the 5G core network (5GC) is discussed, by specifying extensions to the 5GC’s control plane (CP) and user plane (UP) to support ICN traffic. Unlike the aforementioned work, our proposal mainly focuses on the RAN segment and specifically considers the NDN architecture.

Overall, despite the aforementioned efforts, to the best of our knowledge, a thorough study is missing which dissects the benefits of coupling NDN with the 3GPP mechanisms, entities, and routines specifically devised for V2X communications. This is a neat novelty compared to the scanned literature. This work aims at treasuring the aforementioned recent achievements to enforce NDN in 3GPP domains and going beyond them to address the challenging and unique V2X use cases in the 5G realm. To this purpose, in this paper, a set of changes and enhancements are designed for an effective inclusion of NDN into the 3GPP V2X architecture. They mainly encompass: (i) new functionalities in the V2X entities and other 3GPP network elements; (ii) new (NDN) packet processing and resource allocation algorithms; and (iii) novel packet fields.

Being the V2X technology still at an early deployment stage, we believe that introducing now NDN by design can be a viable solution. In the following, we first identify the targeted V2X application scenarios and then point out the proposed extension to the protocol stacks of the main involved 3GPP entities.

4.2. Application Scenarios

The focus of this study is on a class of V2X applications that show non-safety requirements, i.e., they do not have the URLLC constraints of the class of road-safety applications. The applications of interest are delivered via NDN over the PC5 and/or the LTE-Uu radio interfaces of the LTE and beyond cellular system. Examples of non-safety applications include the retrieval of space/time-relevant traffic efficiency and convenience information, e.g., a road congestion status, the pollution level in an urban area, and the high-definition map used by an autonomous vehicle.

On the contrary, safety message dissemination, such as cooperative awareness message (CAM) and event-triggered warning message, relies on other well-established non-IP protocols defined by other SDOs such as ETSI and IEEE (e.g., WSMP).

4.3. Protocol Stack

Figure 2 shows the proposed reference protocol stack for the V2X entities (i.e., vehicles, pedestrians, etc.) and the eNodeB.

V2X entities. To support applications running on mature IP-based solutions and other V2X applications running on top of non-IP protocols, we envision a general protocol stack for UEs, which are provided with multiple networking solutions (e.g., IPv6, NDN, and WSMP) on top of the 3GPP radio interfaces. Of course, some UEs in the V2X ecosystem (e.g., VRUs) may run just a subset of the aforementioned network layers, according to their capabilities.

eNodeB. The NDN layer is deployed also at the eNodeB. Several works claimed the importance of augmenting the eNodeB with caching capabilities (not necessarily related to an ICN approach) to speed up data retrieval (e.g., [33,35]). NDN offers caching natively and additional features that can help in optimizing the network resource allocation and limit the traffic volume, as detailed in the next Section. In [36], the eNodeB is enhanced with a forwarding table to take local forwarding decisions. The beauty of NDN is that a forwarding table can be natively included, and the relevant forwarding fabric and routines can be inherited with no need to rethink them from scratch.

A further unique strength of our proposal and a clear departure from the existing literature is that the NDN forwarding fabric at the eNodeB is coupled with radio resource allocation procedures, which become name-aware, thus saving precious resources, as clarified in the following.

5. 3GPP V2X-NDN Forwarding Strategy

5.1. Content Naming Scheme

NDN naming schemes are not standardized yet. Granted the proposed architecture, we expect that 3GPP can play a crucial role in pushing the specifications of NDN naming conventions, in liaison with actors in the automotive vertical (e.g., road transportation authorities and car manufacturers).

We assume that V2X applications can rely on semantic-rich hierarchical NDN naming schemes, which reflect the geographical and temporal scopes of the contents, similarly to the work in [37,38]. The V2X Control function can be responsible for naming parameters configuration in UEs, as it does for other V2X related parameters (e.g., the radio resources pool for out-of-coverage operation). Specifically, the V2X Control function pre-configures the UEs, or configures them on-the-fly through eMBMS signaling, with some well-known name prefixes and structures. Without loss of generality, as in [37], we propose a V2X namespace for non-safety content retrieval composed of the following elements: (i) application type (e.g., infomobility and convenience); (ii) the data type to be collected (e.g., average speed, high-definition map, charging station availability, fees and locations); (iii) geo-location, concerning a specific geographical area (e.g., a road segment within a highway) from where a UE requests data; and (iv) timestamp, which specifies the time range within which the requested data must be generated. For instance, the name /infomobility/highwaySA-RC/north/avgspeed/11-12-09112019 is used to request average speed conditions on the Salerno-Reggio Calabria highway in the north direction between 11:00 and 12:00 on 6 July 2019. The high volatility of V2X data makes vehicular traffic information to vary from instant to instant, while the freshest data are requested.

5.2. Interest Processing at the Transmitting UE

A consumer, i.e., a UE wishing to retrieve a content, creates an Interest packet, including the content name built as specified above, and sends it to its local NDN forwarding engine. The forwarding strategy at the consumer has to select the outgoing face(s) over which sending the Interest. The decision consists in selecting either the PC5 or the LTE-Uu interface.

Since the content name captures information about the application type and the associated data features (e.g., the geographical scope), specific forwarding policies can be designed according to the name components. We assume that Interests for retrieving locally-available information are sent over the PC5 interface, because this information can be very likely provided by neighboring vehicles. For example, information concerning the status of the road segment where the consumer is traveling (this can be inferred from its on board positioning system) are sent on the PC5. Conversely, Interests related to information available far away from the current UE position—e.g., fees of charging stations for electric vehicles and traffic conditions along the road of a pre-planned journey—are transmitted over the LTE-Uu interface to more likely reach the far away provider(s). The latter can be located in the same cell where the consumer is located or not.

Once the outgoing interface and the corresponding mode (only for PC5) have been selected, the UE acts as follows. It marks the packet in order to be treated as non-IP traffic by the 3GPP interfaces. To this aim, the Type field of the 3GPP frame header is set to the legacy non-IP value when passed to layer 2. We propose adding a value for the one-byte legacy Message Family field to identify NDN traffic (e.g., value 5), besides the already specified IEEE 1609 (value 1), ISO (value 2), and ETSI-ITS (value 4) in [39]. Then, if the Interest must be sent over the PC5 interface through Mode 4, the consumer simply broadcasts the Interest on the sidelink. In the other cases (PC5 Mode 3 and LTE-Uu), the consumer has to send a resource grant request to the eNodeB, prior to packet transmission. We assume that such request piggybacks additional information to allow the eNodeB to efficiently allocate resources, as detailed in the following.

5.3. Interest and Data Processing at the eNodeB

Resource allocation in the legacy eNodeB is typically data-agnostic: there is no way for the eNodeB to know whether grant requests by different UEs are for the transmission of the same packets. Our proposal, instead, is to make resource allocation at the eNodeB name-aware by embedding the NDN packets processing in the resource allocation procedures. To this aim, we extend the scope of the grant request so that it carries information about the packet to be transmitted. More in detail, a portion of such a packet’s header, i.e., only the content name and the NDN packet type (Interest or Data), is conveyed in the BSR sent by the UE.

When receiving a grant request for an Interest packet by a consumer UE, the eNodeB acts as follows (see Figure 3). First, it checks its CS to verify if it caches a copy of the named content requested by the Interest. If the check succeeds, it directly replies with the related Data to the UE. If the CS matching fails, it checks the PIT. In the case of a matching, the eNodeB rejects the request, because it infers that it has already allocated resources for the same named Interest, and notifies the consumer. If the PIT matching fails, it allocates resources to the requesting UE for the Interest transmission and updates the PIT accordingly. The Interest packet will then be transmitted over the corresponding interface on the resource blocks (RBs) allocated by the eNodeB. If the Interest is transmitted over the LTE-Uu interface, the eNodeB has also to enforce its treatment over the downlink direction, selecting unicast or multicast transmission. Multicast can efficiently disseminate the Interest in a large area. In particular, according to rules in the FIB, depending on their turn on the content name, the eNodeB decides to which and how many cells the Interest should be forwarded. It is the V2X AS that fills in the FIB of the eNodeB.

A slightly different processing holds if the eNodeB receives a grant request for a Data packet by a provider UE. First, the eNodeB checks the PIT. In the case of matching, the eNodeB allocates resources to the requesting UE and deletes the corresponding PIT entry. Conversely, if there is no matching in the PIT, the grant request for the Data packet is discarded, being considered as an unsolicited transmission.

If the Data is transmitted over the LTE-Uu interface in UL, the eNodeB has to decide how to forward it in DL, according to the number of received requests for the same Data. An approach similar to the one proposed in [17] for mobile ad hoc environments can be pursued. In this approach, if a provider realizes that the same content is simultaneously requested by a number of consumers (appropriately tracked) greater than a given threshold, then it switches from unicast to broadcast. Here, the decision is whether sending Data through (multiple) unicast connections or to save radio resources by leveraging eMBMS facilities. Smarter strategies may also account for the position in the cell of requesting UE(s) and their advertised channel quality indicators (CQIs).

5.4. Interest Processing at the Receiving UE

When the UE receives an Interest on a 3GPP network interface, the following processing is performed.

-

The UE first looks in the CS. If a matching is found, it will answer with a Data packet over the same interface it has received the request. Specifically:

• If the outgoing interface is PC5 Mode 4, the UE directly broadcasts the Data packet. To avoid collisions with other provider UEs, smart deferral schemes can be implemented similarly to those deployed for NDN-IEEE 802.11 networks, as described in Section 3.2.
• If the outgoing interface is PC5 Mode 3 or LTE-Uu, the UE sends a grant request for Data transmission to the eNodeB. In both cases, the request piggybacks the name of the Data and, therefore, the eNodeB decides if granting resources according to the name-aware resource allocation scheme previously described.

-

If the CS matching fails, then the UE looks in the PIT. If a matching is found, it updates the entry by recording the incoming interface and discards the Interest.

-

If the PIT matching also fails, the UE has to decide whether to further relay the Interest or not and, therefore, it looks in the FIB. If a name matching is found, the Interest is forwarded accordingly, otherwise it is discarded. Depending on the outgoing interface, the UE may broadcast the Interest over the PC5 while implementing smart deferral schemes to avoid collisions in Mode 4, or it may send a named grant request to the eNodeB for the Interest transmission over PC5 Mode 3 or LTE-Uu. Again, the eNodeB may grant or refuse the transmission according to the name-aware resource allocation scheme.

6. Evaluation Methodology

The objective of the conducted evaluation study was to assess the performance of the proposal and measure the benefits that can be achieved against a legacy non-NDN-based solution, considered as a benchmark. To this purpose, a simulation study was conducted which enables the evaluation of the proposed framework under different workload settings.

6.1. Simulation Tools and Settings

A 3GPP-calibrated simulator was developed in MATLAB®, which closely models the content requests generation pattern and the transmission procedures over the cellular interfaces for both the proposed and the benchmark solutions.

Packet dissemination over the cellular infrastructure. We focused on a single cell with an eNodeB receiving grant requests for Interest transmissions (over the LTE-Uu interface) from a set of UEs in coverage. The eNodeB forwards the packets in DL via multicast to potential providers that are supposed to be located in the same cell. In particular, MBMS Single Frequency Networks (MBSFN) is considered as a multicasting scheme. A pattern of subframes is periodically reserved for MBSFN in the physical layer with periodicity equal to the Multicast CHannel (MCH) Scheduling Period ($T_{MSP}$) that is set equal to 10 ms, in agreement with recent enhancements for MBSFN in the V2X context [9].

Two hops were assumed to be traveled, in the worst case (i.e., in the case of a missing PIT entry in the eNodeB), by each request (in the following, we use the term Interest when referring both to content request packets generated in the baseline solution and for the genuine NDN packets) generated by a consumer: from the consumer UE to the eNodeB and from the eNodeB to other UEs in the cell. For simplicity, we assumed that, in the eNodeB, there is no cached content for the Interests issued by consumers, thus the Data packets travel two hops.

NDN settings. Different Interest packet sizes were considered (from 100 to 1000 bytes). Smaller sizes were considered to resemble short (unsigned) Interests, whereas larger sizes were for signed Interests with long names and additional attributes. Unlike our proposal (labeled as NDN in plots), the considered benchmark solution, referred to as baseline, does not allow Interest aggregation at the eNodeB; hence, requests by different UEs for the same content are treated as distinct requests. Moreover, the decision about the DL forwarding are taken at the V2X AS; instead, our solution allows the decision to be taken at the eNodeB, which is enhanced with the NDN forwarding fabric and, specifically, with the name-aware resource allocation strategy.

Content settings. We assumed a varying number of Interests (i.e., 50 and 300) for contents belonging to a catalog of size 1000. To consider multiple UEs in the same cell that may request the same content, we modeled the content popularity according to the Zipf’s law, when the parameter characterizing the distribution, i.e., $\alpha$, is equal to 0.8 and 1.2.

The results were averaged over 100 runs and reported with 95% confidence intervals.

6.2. Performance Metrics

The total number of transmitted Interest packets in the network was derived to account for the original Interests generated by the consumers and transmitted in the uplink direction towards the eNodeB, as well as the Interests forwarded in downlink by the eNodeB for a cell-wide dissemination.

To get more insights into the allocated radio resources for the aforementioned Interest packets, the number of RBs per Interest was also quantified, representing the total number of RBs needed to accommodate the Interest packets transmitted by all consumers and sent over the LTE-Uu interface, in UL and DL directions separately. The number of RBs for carrying an Interest was derived according to the packet size and the modulation and coding scheme (MCS) index, as reported in [7]. Longer packets and more robust MCS indexes require a higher number of RBs. The number of RBs required for UL and DL directions are different, since different MCS indexes apply to unicast and multicast transmission, respectively. An MCS index equal to 11 was assumed on the UL to achieve a good trade-off between reliability and RB usage. Multicasting in the DL direction needs a more robust MCS, hence an MCS index equal to 8 was assumed, similar to the study in [36].

The average Interest dissemination latency was computed as the time since a UE issues an Interest packet until the packet is received by the UEs in the cell, after the DL multicasting by the eNodeB. More in detail, for our proposal, the metric was derived accounting for the following contributions (see

Table 2. Simulation settings.

Parameter	Notation	Value
Transmission processing delay	$T_{tx,p}$	1 ms
Scheduling procedure delay	$T_{sched}$	8 ms
Waiting time for the SR opportunity	$T_{SR}$	Varying
Interest transmission time in both UL/DL	$T_{tx,I}$	1 ms
Decoding delay at the eNodeB	$T_{dec,eNB}$	1 ms
MCH Scheduling Period	$T_{MSP}$	10 ms
Decoding delay at the receiver UE	$T_{dec,UE}$	1.5 ms
Application-layer receiver processing	$T_{rx,p}$	3 ms
Processing time at the V2X AS	$T_{edge}$	Varying

): (i) the processing delay ($T_{tx,p}$) at the transmitter UE for the Interest generation; (ii) the time to undergo the dynamic scheduling procedure for an UL transmission grant ($T_{sched}$), which also includes the waiting time for the SR opportunity ($T_{SR}$) that is a varying parameter in our simulations ($T_{SR}$ depends on the network load; it tends to be longer if the eNodeB has many connected UEs to schedule on the Physical Uplink Control Channel (PUCCH) [40]); (iii) the Interest transmission time over the LTE-Uu interface in the UL direction ($T_{tx,I}$); (iv) the decoding latency ($T_{dec,eNB}$) and the buffering delay that considers the $T_{MSP}$ periodicity, at the eNodeB; (v) the Interest transmission time in the DL direction ($T_{tx,I}$); and (vi) the decoding ($T_{dec,UE}$) and processing delays ($T_{rx,p}$) at the upper layer at receiving UEs. For the baseline solution, instead, the processing time at the V2X AS to trigger multicast procedures was added to the above parameters and named $T_{edge}$. It is a varying parameter in our simulations.

7. Results

The total number of Interest packets transmitted in the network (both in uplink and downlink) is reported in

Table 3. Total number of transmitted Interests in the network.

Zipf’s Parameter	Baseline		Legacy NDN		Our Proposal
	Requests = 50	Requests = 300	Requests = 50	Requests = 300	Requests = 50	Requests = 300
$\mathbf{\alpha }$ = 0.8	100	600	93.13	492.15	86.26	384.3
$\mathbf{\alpha }$ = 1.2	100	600	78.27	403.86	56.54	205.72

. For the non-NDN case, the number of Interest packets transmitted by the consumers is exactly equal to the number of content requests, namely 50 and 300, according to the considered settings. Such a number is kept lower for the proposal when compared to both the baseline and the legacy NDN solutions. The former does not perform requests aggregation in the eNodeB, hence the Interests are all forwarded in the downlink direction, although they are requesting the same content. The eNodeB is agnostic about the traffic to which it grants radio resources. The latter aggregates requests at the eNodeB, thus an Interest for an already requested content is not further forwarded in DL, since there is a pending request in the PIT for the same content.

In our proposal, thanks to the proposed name-aware resource allocation performed at the eNodeB, the radio resources are not allocated for the uplink transmission of the Interest, with significant saving of radio resources. This is confirmed by results reported in Figure 4a, which shows the number of RBs required for the Interest transmissions in the UL direction, when varying the Interest packet size, the number of content requests issued by the consumers, and the Zipf’s parameter. The metric reasonably increases with the packet size and the number of Interests. Benefits of the proposal get more remarkable as the parameter $\alpha$ increases, since more Interests by different UEs are issued to request the same content. The eNodeB checks whether the same Interest has been forwarded before and has not been satisfied yet; if it is the case, there is no need to forward it in DL and allocate UL resources to the requesting UE.

Under the assumption of multicast dissemination in the DL direction (i.e., a single Interest reaching multiple potential content providers within the cell with a single transmission), the number of Interests forwarded by the eNodeB is equal to the number of content requests for the non-NDN case. It achieves a lower number, which depends on the content popularity settings, for the NDN-based schemes.

Gains are particularly significant as both $\alpha$ and the number of content requests increase. For instance, the total number of transmitted Interests passes from 600 for the baseline solution, when 300 content requests are considered, to around 200 for the proposal, when considering $\alpha$ = 1.2.

The results in terms of number of RBs per Interest for the DL are plotted in Figure 4b. The same trends already discussed for the UL are observed, with the main difference that a higher number of RBs is required due to the more robust MCS used for the Interest multicasting.

Figure 5 reports the average Interest dissemination latency for different values of parameters $T_{SR}$ and $T_{edge}$, spanning different cell load and eNodeB-V2X AS distance settings, respectively. The advantage of our proposal is that the eNodeB, augmented with the FIB, can decide about the Interest forwarding with no need to contact the V2X AS and, consequently, the experienced latency is lower. In particular, achieved latency values are bounded by the necessary processing time contributions at UE and eNodeB. Instead, the baseline solution requires to contact the V2X AS, hence, it is particularly sensitive to its deployment, whether close to the eNodeB or not. Latency values can even double compared to the proposed solution (see, e.g., for $T_{SR}$ = 5 ms and $T_{edge}$ = 30 ms).

8. Conclusions

This paper incentivizes the debate about the adoption of NDN as a networking solution for 3GPP V2X communications and discusses a set of extensions to make the best of the proposed integration, as summarized in

Table 4. Proposed changes and enhancements in the 3GPP V2X architecture.

Entity	Proposed Change(s)
UE	- Addition of the NDN layer and relevant data structures and routines
	- Name-driven outgoing interface(s) selection
eNodeB	- Addition of the NDN layer and relevant data structures and routines
	- Name-aware resource allocation
V2X Control Function	Advertisement/pre-configuration of naming conventions and main prefix names for an easier convergence
V2X AS	eNodeB’s FIB population

. In addition to some straightforward enhancements needed to include NDN capabilities in the V2X entities, we propose to augment the eNodeB with the NDN forwarding fabric and data structures, and to extend the radio resources allocation of the eNodeB and make it name-aware.

The results clearly show that, by letting the eNodeB take local forwarding decisions, the Interest dissemination latency can be significantly reduced. Moreover, the proposed name-based resource allocation succeeds in limiting the redundancy of Interest packets requesting the same named content, with inherent savings in terms of allocated radio resources. The 3GPP V2X specifications are under progress at the time of writing and are expected to embrace upcoming 5G enhancements. Hence, we strongly argue about the adoption of NDN as a more general networking solution for 3GPP-based 5G domains, especially in the presence of heterogeneous access technologies, e.g., IEEE 802.11 and cellular interfaces.