[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                             Bin Da
Internet Draft                                                    Huawei
Intended status: Informational                              Antonio Iera
Expires: April 28, 2018                                  Claudia Campolo
                                           University of Reggio Calabria
                                                        October 28, 2017

    Advanced Features for Vehicular Networks: Grouping and Socialization


   For future vehicular networks, some advanced features might be needed
   to facilitate 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",
   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

Da                     Expires April 28, 2018                 [Page 1]

Internet-Draft         Vehicular Advanced Features        October 2017

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 28, 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 ................................. 5
         2.2.1. Fully Socialized Vehicular Networks ............... 5
         2.2.2. Requirements ...................................... 6
   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 ........................10
      4.1. Socialization Sub-functions ........................... 10
      4.2. Socialization via Identifiers ......................... 11
      4.3. Socialized Services ................................... 12
   5. Security Considerations .................................... 13

Da                     Expires April 28, 2018                 [Page 2]

Internet-Draft         Vehicular Advanced Features        October 2017

   6. References ................................................. 13
      6.1. Normative References .................................. 13
      6.2. Informative References ................................ 14
   Authors' Addresses ............................................ 15

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, 5GAA), 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 identifiers for end-to-end
   communications, in network layer for packet delivery, while other
   types of identifiers in cross-layers also function independently
   [Wet2010]. For achieving advanced features for future vehicular
   networks, all 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 may 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 by some SDOs such as in [TR22.886]. Specifically,
   Platooning is a cooperative driving pattern for a group of vehicles

Da                     Expires April 28, 2018                 [Page 3]

Internet-Draft         Vehicular Advanced Features        October 2017

   which follow one another and maintain a small and nearly constant
   distance among them. Figure 1 illustrates this case on one road land
   while few cars are grouped together for platooning driving.

       LANE1        <<<Car1-Car2-Car3 [Platoon1]
       - - - - - - - - - - - - - - - - - - - - - - - - - -
       LANE4               [Platoon2] Car6-Car5-Car4>>>

                 Figure 1: Example of Platooning

2.1.2. Requirements of Grouping

   As shown in platooning [Jia2016], there exist some unique
   requirements, for instance: Initial platooning formulation; Dynamic
   joining or dismissing; Inter-vehicle distance control; Speed control;
   Security alerting. 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 happens 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 be elaborated.

Da                     Expires April 28, 2018                 [Page 4]

Internet-Draft         Vehicular Advanced Features        October 2017

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.

   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). Based 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 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
       LANE1                   <<<Car2
       LANE2           <<<Car1
       - - - - - - - - - - - - - - - - - - - - - - - - - - - -
       LANE3      Car5>>>                    Car3>>>
       LANE4                       Car4>>>
                       |           |  P4   P5         |
               BS2     |Gas Station|                 (|   BS3
                       |___________|                 (|

   Figure 2: Example of Socialized Environments for Vehicular Networks

Da                     Expires April 28, 2018                 [Page 5]

Internet-Draft         Vehicular Advanced Features        October 2017

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]. Among which, a lot of relevant functions should be
   developed 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 maintenance: Dynamic joining or dismissing of member
   cars should be reflected and group status information should be
   exchanged as well. This may contain more information such as average
   speed, driving direction, fuel consumption, etc.

Da                     Expires April 28, 2018                 [Page 6]

Internet-Draft         Vehicular Advanced Features        October 2017

   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

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. 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 [Fen2017]. 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).

Da                     Expires April 28, 2018                 [Page 7]

Internet-Draft         Vehicular Advanced Features        October 2017

   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.

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.

Da                     Expires April 28, 2018                 [Page 8]

Internet-Draft         Vehicular Advanced Features        October 2017

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.

   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

   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.

Da                     Expires April 28, 2018                 [Page 9]

Internet-Draft         Vehicular Advanced Features        October 2017

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.

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

   - 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

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

   - 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

Da                     Expires April 28, 2018                [Page 10]

Internet-Draft         Vehicular Advanced Features        October 2017

   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 performed according
   to some relationship-based policies. For instance, when one alerting
   event happens, the vehicle is able to automatically inform all nodes
   in direct relationship and optionally inform nodes in multiple-hop

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

   - 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

Da                     Expires April 28, 2018                [Page 11]

Internet-Draft         Vehicular Advanced Features        October 2017

   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
   socialization functions mentioned above. In addition, IBS (Identity-
   Based Signature) might be utilized 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

Da                     Expires April 28, 2018                [Page 12]

Internet-Draft         Vehicular Advanced Features        October 2017

   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
   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
   the 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.

Da                     Expires April 28, 2018                [Page 13]

Internet-Draft         Vehicular Advanced Features        October 2017

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.

   [Jia2016] D. Jia, K. Lu, J. Wang, X. Zhang, and X. Shen, "A Survey on
             Platoon-based Vehicular Cyber-physical Systems", IEEE
             Communications Surveys & Tutorials, 2016.

   [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.

   [Fen2017] B. Feng, H. Zhang, H. Zhou, and S. Yu, "Locator/Identifier
             Split Networking: A Promising Future Internet Architecture",
             IEEE Communications Surveys and Tutorials, in press, 2017.

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

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

Da                     Expires April 28, 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

   EMail: dabin@huawei.com

   Antonio Iera
   University of Reggio Calabria
   Salita Melissari, Reggio Calabria, 89124

   EMail: antonio.iera@unirc.it

   Claudia Campolo
   University of Reggio Calabria
   Salita Melissari, Reggio Calabria, 89124

   EMail: claudia.campolo@unirc.it

Da                     Expires April 28, 2018                [Page 15]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/