Skip to main content

Advanced Features for Vehicular Networks: Grouping and Socialization
draft-da-ipwave-advanced-features-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Bin Da
Last updated 2017-10-26
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-da-ipwave-advanced-features-00
Network Working Group                                            Bin Da
Internet Draft                                                   Huawei
Intended status: Informational                         October 27, 2017
Expires: April 27, 2018

    Advanced Features for Vehicular Networks: Grouping and Socialization
                 draft-da-ipwave-advanced-features-00.txt

Abstract

   For future vehicular networks, some advanced features might be needed
   to facilitate the use cases as platooning, proximity service
   awareness, autonomous driving and so forth. Thus, this draft intends
   to present two functions, known as vehicular grouping and
   socialization, for enabling some future-oriented use cases. These two
   functions could be built upon cross-layer identifiers, such as MAC,
   IP, and ID, which also have potential to formulate more value-added
   services for future vehicular networks.

Requirements Language

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Da                     Expires April 27, 2018                 [Page 1]
Internet-Draft         Vehicular Advanced Features        October 2017

   This Internet-Draft will expire on April 27, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents carefully,
   as they describe your rights and restrictions with respect to this
   document. Code Components extracted from this document must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions and are provided without warranty as described in
   the Simplified BSD License.

Table of Contents

   1. Introduction ................................................ 3
   2. Requirements of Future Use Cases for Vehicular Networks ..... 3
      2.1. Grouping Use Case ...................................... 3
         2.1.1. Platooning ........................................ 3
         2.1.2. Requirements ...................................... 4
         2.1.3. More Possibilities ................................ 4
      2.2. Socialization Use Case ................................. 4
         2.2.1. Fully Socialized Vehicular Networks ............... 4
         2.2.2. Requirements ...................................... 5
   3. Grouping for Vehicular Networks ............................. 6
      3.1. Grouping Sub-functions ................................. 6
      3.2. Grouping via Cross-Layer Identifiers ................... 7
         3.2.1. MAC as Identifier ................................. 7
         3.2.2. IP as Identifier .................................. 7
         3.2.3. Application-Level Identifier ...................... 7
         3.2.4. Independent Identifier Layer ...................... 7
         3.2.5. An Overview of Cross-Layer Identifiers for Grouping.8
      3.3. Grouping Management .................................... 8
         3.3.1. Dynamic Grouping Management ....................... 9
         3.3.2. Pseudonymity and Batch Update of Identifiers ...... 9
   4. Socialization for Vehicular Networks ........................ 9
      4.1. Socialization Sub-functions ........................... 10
      4.2. Socialization via Identifiers ......................... 11
      4.3. Socialized Services ................................... 12
   5. Security Considerations .................................... 13

Da                     Expires April 27, 2018                 [Page 2]
Internet-Draft         Vehicular Advanced Features        October 2017

   6. References ................................................. 13
      6.1. Normative References .................................. 13
      6.2. Informative References ................................ 13

1. Introduction

   Nowadays, vehicular networks are under active development by
   different standard organizations (e.g., IEEE, IETF, ITU, ISO, 3GPP,
   ETSI, etc.), many industry alliances (e.g., Car2Car CC, OCF
   Automotive), and research institutes (e.g., NTU-SMP). As is well
   known, future networks demand high-throughput or massive low data-
   rate connections, low latency or deterministic delay, high mobility
   support with seamless communications, and inherent security built-in
   networks. Thus, vehicular networks become a typical use case
   satisfying all these future-oriented demands, and formulate one key
   scenario for future networks.

   IP address plays an important role, as communications identifiers, in
   network layer for end-to-end packet delivery, while other types of
   identifiers in cross-layers also function independently [Wet2010].
   For achieving advanced features for future vehicular networks, these
   identifiers could be properly grouped or even socialized to
   facilitate platooning, proximity service awareness, autonomous
   driving, and so forth. The following sections of this draft will
   elaborate vehicular grouping and socialization functions in more
   detail, for potential advanced features of vehicular networks, which
   could serve as partial requirement inputs for IETF IPWAVE WG with
   further investigations on more future-oriented features.

2. Requirements of Future Use Cases for Vehicular Networks

   In this section, two typical scenarios for elaborating the functions
   of grouping and socialization are provided. Note that, for vehicular
   networks, there might exist more use cases to be developed.

2.1. Grouping Use Case

2.1.1. Platooning

   One typical use case for orderly grouping is platooning, which has
   been described some SDOs such as in [TR22.886]. Figure 1 illustrates
   this case on one road land while few cars are grouped together for
   platooning driving.

Da                     Expires April 27, 2018                 [Page 3]
Internet-Draft         Vehicular Advanced Features        October 2017

       +++++++++RSU+++++++++++++++++++++++++++RSU+++++++++
       LANE1        <<<Car1-Car2-Car3 [Platoon1]
       LANE2
       - - - - - - - - - - - - - - - - - - - - - - - - - -
       LANE3
       LANE4               [Platoon2] Car6-Car5-Car4>>>
       +++++++++RSU+++++++++++++++++++++++++++RSU+++++++++

                 Figure 1: Example of Platooning

2.1.2. Requirements of Grouping

   As shown in platooning, there exist some unique requirements, for
   instances: Initial platooning formulation; Dynamic joining or
   dismissing; Inter-vehicle distance control; Speed control; Security
   alerting; and the like. To realize these requirements, an integrated
   solution should be developed, which may exceed the scope of this
   draft focusing on requirements of advanced features for future
   networks. In particular, part of these platooning requirements will
   be discussed in Section III, with the discussion of dynamic grouping
   using cross-layer identifiers.

2.1.3. More Possibilities

   In a smaller scale, the grouping normally happen among vehicles in
   tandem (as in above platooning case), or could be possibly operated
   among RSUs (Road-Side Units) and vehicles in parallel lanes towards
   the same driving direction. However, this case is much more dynamic
   and complicated than the former one, for which, we think, grouping in
   small scale cannot assume this function and thus a further discussion
   on socialization will elaborated.

2.2. Socialization Use Case

2.2.1. Fully Socialized Vehicular Networks

   The Thing-to-Thing socialization was initially proposed as SIoT
   (Social IoT) in [Atz2012], which serves as a paradigm to describe the
   relationships among heterogeneous IoT terminals.

Da                     Expires April 27, 2018                 [Page 4]
Internet-Draft         Vehicular Advanced Features        October 2017

   More specifically, in terms of vehicular networks, the focused
   entities are different types of vehicles (e.g., sedan, ambulance,
   police wagon, etc.) on the road, which generally have high mobility
   and have frequent interconnections with surrounding vehicles,
   infrastructures (e.g., traffic lights, monitors, road-side sensors,
   etc.), pedestrians with handheld devices, UAVs, and road-side service
   points (e.g., gas station, restaurants). Base on this observation,
   there exists a potential for future vehicles to setup a variety of
   relationships with all the surrounding terminals with communications
   capabilities, for a broader value-added functions. Figure 2 shows one
   possible scenario regarding this socialization among heterogeneous
   terminals. One more specific embodiment is also provided in [Far2015].

            |)     |^^^^^^^^^^|            BS1
            |)     |Restaurant|
            |      |          |  P1   P2              P3
       +++++++++++RSU+++++++++++++++++++++++++++RSU+++++++++++
       LANE1                   <<<Car2
       LANE2           <<<Car1
       - - - - - - - - - - - - - - - - - - - - - - - - - - - -
       LANE3      Car5>>>                    Car3>>>
       LANE4                       Car4>>>
       +++++++++++RSU+++++++++++++++++++++++++++RSU+++++++++++
                       |           |  P4   P5         |
               BS2     |Gas Station|                 (|   BS3
                       |___________|                 (|

   Figure 2: Example of Socialized Environments for Vehicular Networks

2.2.2. Requirements of Socialization

   To properly model the social relationships among vehicles and
   surrounding fixed or mobile terminals, some researches have been
   carried out recently [Ala2015] and more functions need to be explored
   as well [Atz2012]. In line with these fundamental requirements, it

Da                     Expires April 27, 2018                 [Page 5]
Internet-Draft         Vehicular Advanced Features        October 2017

   should develop lots of relevant functions such as: relationship
   management (establish, update, dismiss, etc.), relation-based
   services (proximity, data delivery, etc.), mapping, lifecycle, access
   control and so forth.

3. Grouping for Vehicular Networks

   This section is aimed to elaborate the grouping and its sub-functions,
   along with some key issues regarding to identifier-based dynamic
   grouping method. Some lower layer technical details (e.g., PHY layer)
   and specific upper layer implementations are currently beyond the
   scope of this draft.

3.1. Grouping Sub-functions

   Grouping is not a trivial function, which should include multiple
   sub-functions, which are listed below:

   - Group establishment: This could be carried out in both distributed
   or centralized manner, while one group head (e.g., Platoon head car)
   can take in charge of grouping, or alternatively, one central control
   node is responsible for grouping (RSU, or BS).

   - Group head selection: In distributed manner, there should be a head
   car in one group who manages the group proactively. Thus, this head
   car should be selected at the beginning.

   - Group member management (join or dismiss): Subsequent cars can join
   an existing group, or dismiss from the group.

   - Group head delegation: With distributed grouping, the head may
   leave the group at certain moment. Thus, it should delegate its role
   to another member in the group.

   - Group status update: Dynamic joining or dismissing of member cars
   should be reflected and group status information. This may contain
   more information such as average speed, driving direction, fuel
   consumption, etc.

   All the above functions are demanded for realizing proper grouping in
   vehicular networks. This draft focuses on networking identifiers for
   grouping, while other aspects are briefly discussed for future
   investigations.

Da                     Expires April 27, 2018                 [Page 6]
Internet-Draft         Vehicular Advanced Features        October 2017

3.2. Grouping via Cross-Layer Identifiers

   In above listed functions of grouping, there must have certain type
   of identifiers to be used for labeling group members and make
   associated management.

3.2.1. MAC as Identifier

   The MAC address (48 bits) is a typical identifier for grouping at MAC
   layer, while one typical use case is Bluetooth cluster (one Master
   with several Slaves, being associated by MAC addressed in a group).

3.2.2. IP as Identifier

   The IP address is used at network layer for packet delivery, which
   could be locally valid or globally reachable. Both IPv4 and IPv6 can
   be used for identifying communications endpoints at network layer, so
   as to function as grouping identifiers. IP over WAVE is well studied
   in [Ces2013].

3.2.3. Application-Level Identifier

   As proposed in [Wet2010], a set of dedicated application-level
   identifiers are formulated for vehicular networks. Even though these
   identifiers have a IPv4-like length, which could be extended further
   in a IPv6-like manner to better uniquely identify objects in a global
   scale.

3.2.4. Independent Identifier Layer

   Traditionally, IP address assumes an overloaded semantics, which
   serves both as endpoint identifier and routing locator
   [RFC6830][RFC7401]. Thus, many ILS (Identifier/Locator Split) schemes
   have been studied in the past decades, for the purpose of future
   network evolution. Based on the same principle, it is possible to
   have an independent identifier layer above IP layer and below
   application layer, to serve for the intention of endpoints'
   communications or other purposes. This ILS paradigm also supports
   native mobility of moving nodes regardless of locator changes
   [Ces2015], so as to support vehicle mobility.

   It is worth noting that vehicular networks normally require to
   uniquely identify individual vehicles, known as VID (Vehicle ID).
   Based on previous descriptions, this VID could be derived from MAC
   address or other types of identifiers, as suggested in ETSI or IEEE.
   However, it might formulate VID in the independent identifier layer
   proposed here.

Da                     Expires April 27, 2018                 [Page 7]
Internet-Draft         Vehicular Advanced Features        October 2017

3.2.5. An Overview of Cross-Layer Identifiers for Grouping

   Collectively, the following Figure 3 shows all potential layered
   identifiers for grouping.

       +---------------------------------+
       |  Application Layer Identifier   |
       +---------------------------------+
       |   TCP/UDP for Transport Layer   |
       +---------------------------------+
       |  Independent Identifier Layer   | --> Vehicle ID
       +---------------------------------+
       |  Internet Protocol Identifier   |
       +---------------------------------+
       |  Data-Link Layer MAC Identifier |
       +---------------------------------+
       |         Physical Layer          |
       +---------------------------------+
   Figure 3: An Overview of Cross-Layer Identifiers for Grouping

3.3. Grouping Management

   Due to the nature of high mobility and desired pseudonymity for
   privacy protection, grouping in vehicular networks has many
   challenges ahead [Pet2015]. This sub-section discusses two important
   aspects on grouping management, which should be of importance for
   further studies.

3.3.1. Dynamic Grouping Management

   As described in Section 3.1, there exist few sub-functions for
   appropriately managing grouping, while the highly dynamic nature of
   vehicle networks requires all the relevant functions to be
   implemented quickly whenever a grouping event occurs.

Da                     Expires April 27, 2018                 [Page 8]
Internet-Draft         Vehicular Advanced Features        October 2017

   In a distributed manner, the group head should be promptly aware of
   any change in its group. Such as in platooning case, the group head
   should control overall speed of all group member with their relative
   distance between each other. Additionally, the group head should
   manage the change of members (joining or dismissing), and delegate
   its role to another vehicle if it cannot serve as the group head any
   more.

   In a centralized manner, one central controller/node should manage
   the formation of group and member changes.

3.3.2. Pseudonymity and Batch Update of Identifiers

   The pseudonymity is a prominent feature that should be well
   considered in future IoT networks in general, for protecting any
   specific moving node from being tracked, so as to achieve location
   privacy with other associated private and sensitive information.
   Particularly, under the circumstance of vehicular networks,
   pseudonymity requires frequent updates of communications identifiers
   (e.g., MAC, or IP address). This also presents a challenge for
   grouping, which may be built upon multiple cross-layer identifiers.

   Different layers utilize their respective identifiers to label
   vehicles, which may result in dynamically changing higher-layer
   identifiers dependent on varying lower-layer identifiers. For
   instance, IP addresses may be adopted by a central node to maintain a
   group of vehicles, while these IP addresses are associated with
   lower-layer MAC addresses. When MAC addresses are updated, the
   corresponding IP addresses may need to be modified as well.

   One possible solution is that, using persistent VID (Vehicle ID) that
   may reside on the independent identifier layer (or defined in other
   layers) to build a vehicular group, and further make a dynamic
   binding between VIDs and underlying identifiers (e.g., IP, or MAC).
   In such case, the paradigm of ILS could be well suited, once the VIDs
   are not often exposed in the networks with proper protection.

4. Socialization for Vehicular Networks

   This section intends to introduce an additional novel feature for
   future vehicular networks, which originates from SIoT concept
   [Atz2012]. Note that the distinction of socialization as compared to
   previously introduced grouping is that socialization is actually a
   social-link graph for all inter-linked objects, while grouping is
   simply a set of objects.

Da                     Expires April 27, 2018                 [Page 9]
Internet-Draft         Vehicular Advanced Features        October 2017

4.1. Socialization Sub-functions

   As depicted in Figure 2, when vehicles are moving, they interact with
   all available surrounding environments and capable sensors or devices,
   which should be very practical in future if all infrastructures are
   deployed with intelligent IoT sensors or devices. In such scenario,
   the main entity i.e., the vehicle in vehicular networks, should have
   differentiated relationships with surrounding devices that may happen
   to encounter, often see each other on the road, always follow similar
   routine, bound with same services, or sharing similar applications,
   and so forth. Thus, it needs to realize a set of functions for
   socialized vehicular networks, which are stated below (not limited
   to):

   - Relationship type definition: The vehicle-to-thing relationship is
   heuristic, since there does not have a standardized way to perfectly
   define this novel relationship at present. Previous SIoT studies show
   some typical relationship as given [Atz2012]. For vehicular networks,
   some useful relationships could be parental (same vehicular brand or
   manufacturer), co-location (co-geolocation), ownership (same owner),
   and social relationship (vehicle-to-thing friendship due to frequent
   interactions).

   - Relationship management (establish, update, dismiss, etc.):
   Individual relation between any pair of vehicular objects should be
   properly managed, including relationship establishment, update and
   dismiss.

   - Relationship storage: All relationships should be stored, mostly in
   a distributed manner, while some static relationships could be stored
   in a central server.

   - Scalable query: Each vehicle may only store relationships from its
   own perspective, thus vehicle-to-vehicle relationship query should
   resort to some scalable query methodology.

   - Relationship-based services: Based on vehicle-to-anything
   relationship, some advanced services could be enabled, such as
   proximity service (e.g., road-side discount information), and
   alerting service (e.g., alert is sent by the traffic light that this
   vehicle passing through every day).

   - Data delivery: Based on one-hop and multiple-hop relationships from
   one specific vehicle, the data delivery could be sent according to
   some relationship-based policies. For instance, when one alerting
   event happens, the vehicle is able to automatically inform all nodes

Da                     Expires April 27, 2018                [Page 10]
Internet-Draft         Vehicular Advanced Features        October 2017

   in direct relationship and optionally inform nodes in multiple-hop
   relationship.

   - Access control: Relationship may provide an additional dimension
   for access control, while limited relationships can be granted access
   rights.

   - Trustworthiness: Different relationships should have differentiated
   trustworthiness, which shall support privacy protection over
   sensitive information.

4.2. Socialization via Identifiers

   Similarly, as stated in Section 3.2, there exist multiple types of
   identifiers which could be used to label two endpoints of one
   relationship link. However, due to different characteristics of
   socialization, a self-certifying and privacy-protected identifier is
   wanted to serve for the purpose of socialization for vehicles and
   surrounding environmental sensor or devices. Thus, as indicated in
   Figure 3, VID defined in an independent identifier layer, could be a
   promising candidate.

   With the considerations of massive IoT terminals and upper-layer
   support, one IPv6-like VID (same length with IPv6, but have distinct
   connotation) is recommended below, as shown in Figure 4.

         28 bits        4 bits         96 bits
       +-------------------------------------------+
       | VID Flag |  Vehicle Type | PKI-Hashed VID |
       +-------------------------------------------+
              Figure 4: One embodiment of VID

   In Figure 4, VID Flag is 28-bit length, which resembles the function
   of HIP Orchid (Overlay Routable Cryptographic Hash IDentifiers)
   [RFC7401], and Vehicle Type serves the purpose of ITS Station Type
   defined in [Wet2010] with broader options. The last 96 bits adopt CGA
   (Cryptographically Generated Address) principle, which is actually a
   cryptographic hash of the public key of one particular vehicle. Note
   that this embodiment of VID can be regarded as pseudo-persistent
   identifier for vehicular networks, once it is well protected in the
   network (e.g., encryption via transmission). Thus, the frequency of
   reconstructing such VID becomes low, which potentially supports

Da                     Expires April 27, 2018                [Page 11]
Internet-Draft         Vehicular Advanced Features        October 2017

   socialization functions mentioned above. In addition, IBS (Identity-
   Based Signature) might be utilize to construct such VID as well.

   Particularly, for Vehicle Type segment shown in Figure 4, it could be
   defined as follows, in line with [Wet2010]:

   - 0000: Central ITS Station

   - 0100: Roadside ITS Station

   - 1000: Vehicle ITS Station

   - 1100: Personal ITS Sation

   The additional two bits are open for future definitions, which could
   be that 0101 means traffic light and 1011 indicates ambulance.

4.3. Socialized Services

   Once the vehicles and surrounding environmental sensors or devices
   are socialized, there may develop lots of innovative future vehicular
   services. Some of potential services are provided below:

   - Proximity service: When co-location (co-geolocation) relationship
   is detected, the services attached by VID could be delivered, such as
   upper-layer application coupon information.

   - Socialized vehicular status sharing: When two vehicles happen to
   see each other on the road, and their VID indicates same brand, they
   may activate the service of concerned information sharing, such as
   oil consumption, most vulnerable component, etc.

   - Social relationship based alerting service: When emergency event
   happens, it normally resorts to human social relation to broadcast
   the information, if this service is previously subscribed by vehicle
   owners. However, in future vehicular networks, individual vehicles
   and other surrounding devices are equipped with intelligence inside,
   so they may actively exchange some useful information or even build
   their own machine-type social networks. In this case, when emergency
   occurs, the corresponding vehicle could search its own social graph
   to find the closest devices to inform emergent events.

   - Socialized Autonomous Driving: Fully autonomous driving will come
   true in the next decade, while an integrated solution with in-vehicle
   interconnections, intra-vehicle communications, fast data processing,
   intelligent planning should be developed. Then, socialization could
   be one enabler for this vision as well, which could support not only

Da                     Expires April 27, 2018                [Page 12]
Internet-Draft         Vehicular Advanced Features        October 2017

   long-term relationship and also can support ephemeral relationship
   for cooperative autonomous driving.

   Furthermore, given this new socialization feature, there should have
   more services available for further investigations, such as the
   socialized vehicular navigation studied in [Far2015].

5. Security Considerations

   For the two features discussed previously in this draft, there exist
   lots of security issues that need to be well considered in near
   future. First of all, for dynamic group or social relationship
   management, it must ensure credible nodes to join, while preventing
   any malicious node. Then, the identifiers used at cross-layers should
   be securely managed and updated, such as VID is long-term used and
   should not be transmitted explicitly to unwanted targets. Furthermore,
   some low-latency and sensitive information should be explored along
   social graph when all vehicles are socialized, which introduces
   trustworthiness problem as well. In addition, VID-attached data or
   some aforementioned services must be genuine, so that individual
   vehicles can utilize them in a secure manner.

6. References

6.1. Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", March 1997.

   [TR22.886] Study on enhancement of 3GPP Support for 5G V2X Services
             (Release 15), 3GPP TR 22.886, March 2017.

   [RFC6830] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "The
             Locator/ID Separation Protocol (LISP)", Jan. 2013.

   [RFC7401] Ed. R. Moskowitz, T. Heer, P. Jokela, and T. Henderson,
             "Host Identity Protocol Version 2 (HIPv2)", April 2015.

6.2. Informative References

   [Wet2010] M. Wetterwald, F. Hrizi, and P. Cataldi, "Cross-layer
             Identities Management in ITS Stations", The 10th
             International Conference on ITS Telecommunications,
             November 2010.

Da                     Expires April 27, 2018                [Page 13]
Internet-Draft         Vehicular Advanced Features        October 2017

   [Atz2012] L. Atzori, A. Iera, G. Morabito, M. Nitti, "The Social
             Internet of Things (SIoT) - When social networks meet the
             Internet of Things: Concept, architecture and network
             characterization", Computer Networks, Nov. 2012.

   [Far2015] I. Farris, R. Girau, L. Militano, M. Nitti, and L. Atzori,
             "Social Virtual Objects in the Edge Cloud", IEEE Cloud
             Computing, 2015.

   [Ala2015] K.M. Alam, M. Saini, A. El Saddik, "Toward Social Internet
             of Vehicles: Concept, Architecture, and Applications", IEEE
             Access, March 2015.

   [Ces2013] S. Cespedes, N. Lu, and X. Shen, "VIP-WAVE: On the
             Feasibility of IP Communications in 802.11p Vehicular
             Networks", IEEE Transactions on Intelligent Transportation
             Systems, March 2013.

   [Ces2015] S. Cespedes, and X. Shen, "On Achieving Seamless IP
             Communications in Heterogeneous Vehicular Networks", IEEE
             Transactions on Intelligent Transportation Systems, Dec.
             2015.

   [Pet2015] J. Petit, F. Schaub, M. Feiri, and F. Kargl, "Pseudonym
             Schemes in Vehicular Networks", IEEE Communications Surveys
             & Tutorials, 2015.

Da                     Expires April 27, 2018                [Page 14]
Internet-Draft         Vehicular Advanced Features        October 2017

   Authors' Addresses

   Bin Da
   Huawei Technologies Co., Ltd.
   No.156, Beiqing Road, Zhongguancun, Haidian District
   Beijing 100095
   China

   EMail: dabin@huawei.com

Da                     Expires April 27, 2018                [Page 15]