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

Versions: 00 01 02 03 04 05

Network Working Group                                   A. Petrescu, Ed.
Internet-Draft                                                 CEA, LIST
Intended status: Informational                                  J. Huang
Expires: March 24, 2016                              Huawei Technologies
                                                                T. Ernst
                                                         Mines ParisTech
                                                           R. Buddenberg
                                                                     " "
                                                      September 21, 2015

   Cooperative Adaptive Cruise Control and Platooning at SDOs and Gap


   This document describes the use-cases of Cooperative Adaptive Cruise
   Control, and Platooning, as defined by several Standards Development
   Organizations such as ETSI, IEEE P1609, SAE, 3GPP, ISO and FirstNet.

   C-ACC and Platooning involve concepts of direct vehicle-to-vehicle,
   and device-to-device communications, which are developped at least by
   3GPP and precursory by the METIS EU project.  They are illustrated
   very clearly in emergency settings such as FirstNet.

   IP messages - instead of link-layer messages - are pertinent for
   C-ACC and Platooning use-cases because applications for road safety
   such as WAZE, iRezQ and Coyote (currently involving infrastructure)
   are IP messages, and proved succesful in deployments.  Applications
   such as Sentinel are direct between vehicles but are not IP,

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

Petrescu, et al.         Expires March 24, 2016                 [Page 1]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

   This Internet-Draft will expire on March 24, 2016.

Copyright Notice

   Copyright (c) 2015 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  ETSI ITS C-ACC and Platooning use-case and reqs . . . . . . .   4
   4.  IEEE P1609 perspective on       communications for C-ACC and
       Platooning  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  SAE perspective on C-ACC and Platooning . . . . . . . . . . .   5
   6.  3GPP SDO and EU projects using LTE Device-to-Device concepts    5
     6.1.  3GPP  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  METIS . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  ISO perspective on V2V  . . . . . . . . . . . . . . . . . . .   7
   8.  FirstNet EMS use of LTE and IP           in V2I2V . . . . . .   8
   9.  Internet apps: WAZE, iRezQ, Coyote, Sentinel  . . . . . . . .   9
   10. Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Neighbor Discovery protocol  . . . . . . . . . . . . . .  10
     10.2.  Mobile IP protocol . . . . . . . . . . . . . . . . . . .  10
     10.3.  AODV protocol  . . . . . . . . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   13. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     14.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  ChangeLog  . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

Petrescu, et al.         Expires March 24, 2016                 [Page 2]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

1.  Introduction

   Cooperative Adaptive Cruise Control and Platooning are two use-cases
   described recently at particular Standards Development Organizations.
   C-ACC is understood as a formation of chains of automobiles following
   each other at constant speed, in an automated manner.  This is to
   offer more comfort for human drivers on long journeys on straight

   Simple 'cruise control' was the automation of speed maintenance at a
   single automobile (increase torque if uphill, smoothly brake
   downhill, such as to maintain constant speed).  The term "Adaptive
   Cruise Control" was used earlier in related ISO standards.  The
   concept of C-ACC aims at the same level of automation but in a
   cooperative manner between several vehicles: while in CC mode, when a
   vehicle in front slowly decelerates, this vehicle will also do, such
   as to maintain distance, and relieve driver from taking control over.

   Platooning is a concept related to larger vehicles following each
   other.  The goal in this case is more than just comfort - large gains
   are expected in terms of gas consumption: when large vehicles can
   follow each other at small distance the air-drag is much lower,
   reducing gas consumption, tyre use, and more.

   Both C-ACC and Platooning must rely on data packet exchanges between
   vehicles (in addition to more immediate indices like signal echoes -
   radars and cameras).  These exchanges may happen in a direct manner
   (direct vehicle to vehicle communications) or with assistance from a
   fixed communication infrastructure (vehicle-to-infrastructure-to-
   vehicle communications).

   This document presents the C-ACC and Platooning use-cases as
   described at ETSI, IEEE, SAE, ISO, 3GPP and more.  These use-cases
   are widely accepted as Vehicle-to-Vehicle applications.

   In emergency settings the concepts of direct vehicle-to-vehicle
   communications are of paramount importance.  FirstNet, an overarching
   example described later in this document, covers V2V, V2I and V2I2V
   communication needs, together with strong security requirements.

   In the market, several systems for vehicular communications have
   demonstrated a number of benefits in the context of vehicle-to-
   vehicle communications.  The Sentinel system is used between vehicles
   to warn each other about approach; the WAZE application on
   smartphones created a community where users influence others about
   the route choice; the iRezQ and Coyote applications communicate
   between vehicles, via infrastructure, about route risks.

Petrescu, et al.         Expires March 24, 2016                 [Page 3]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

   In [I-D.petrescu-ipv6-over-80211p] the use of IPv6 over 802.11p is
   described.  This link layer is potentially used in direct vehicle-to-
   vehicle communications.  It is obviously not the only link layer
   pertinent for V2V.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   C-ACC: Cooperative Adaptive Cruise Control.

   V2V: Vehicle-to-Vehicle communications.

3.  ETSI ITS C-ACC and Platooning use-case and reqs

   ETSI Technical Committee Intelligent Transportation Systems (ETSI TC
   ITS) is responsible for the development and maintenance of standards,
   specifications and other reports on the implementation of V2V
   communications in Cooperative ITS.  Its scope extends from the
   wireless access (excluding issues in radio frequency) to generic
   services and corresponding applications.  Security and tests
   specifications are also covered.  This responsibility is reflected in
   the organization with five working groups that make up the committee.
   Among them, WG1 is responsible of the facilities and applications

   Under the EU Mandate M/453, TC ITS has developed a minimum set of
   standards (Release 1) for systems interoperability during initial
   deployment.  The list of standards and specifications are provided in
   the publicly available report ETSI TR 101 607.  A second release of
   the standards is being prepared.  It should support more complex use
   case, possible integration with other technologies as well as a more
   elaborate consideration of access networks other than the ITS-G5
   (European profile of IEEE 802.11p).  The TC ITS WG1 is currently
   working on two separate work items for pre-standardization studies on
   C-ACC (DTR/ITS-00164) and Platooning (DTR/ITS-00156).  The scope of
   the target technical reports is to describe the relevant use cases
   that could be enabled by Cooperative ITS, to survey the existing
   related standards and to identify what new features and standards are
   needed to support these use cases.

4.  IEEE P1609 perspective on communications for C-ACC and Platooning

   One perspective from IEEE P1609 is that Cooperative Adaptive Cruise
   Control (CACC) represents an "application".  An application is
   typically software whose communication needs are situated at the

Petrescu, et al.         Expires March 24, 2016                 [Page 4]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

   upper layers of a communication stack - e.g. the Application Layer.
   As such it is little relevant to IEEE P1609; P1609 is concerned more
   with physical, data-link and network communication layers.  On
   another hand, a perspective well considered in IEEE P1609 is that
   C-ACC and Platooning may be more relevant to the Society of
   Automotive Engineers.

5.  SAE perspective on C-ACC and Platooning

   The Society of Automotive Engineers (SAE) concerns itself with data
   exchanges and host system requirements for applications.  The SAE
   DSRC Technical Committee (DSRC: Dedicated Short-Range Communications)
   is working on C-ACC within the Cooperative Vehicle Task Force.  In
   addition, the SAE On-Road Vehicle Automation Committee is working on
   a use-case relevant to C-ACC (under development) towards realization
   of a reference architecture.

   The SAE DSRC TC activities are in cooperative agreement to ETSI ITS
   WG1, as there are information exchanges between the two bodies.

6.  3GPP SDO and EU projects using LTE Device-to-Device concepts

6.1.  3GPP

   Proximity Service (ProSe) allows a UE to discover and communicate
   with other UEs that are in proximity directly or with the network
   assistance.  This may also be called as Device-to-Device (D2D)
   communication.  ProSe is intended for purposes such as public
   security, network offloading, etc [GPP-TR-22-803].

   The ProSe Communication path could use E-UTRAN or WLAN.  In the case
   of WLAN, only ProSe-assisted WLAN direct communication (i.e. when
   ProSe assists with connection establishment management and service
   continuity) is considered [GPP-TS-22-278].

   The work on ProSe is initiated in 3GPP Release 12.  Some enhancements
   are being added in Release 13, e.g.  Restricted ProSe Discovery.
   Some use cases are identified in [GPP-TR-22-803], but most of which
   are intended for common mobile users, e.g. walking people, not for
   vehicles moving at high speed, for example the latency in ProSe
   communication may be a problem for V2X.

   Although ProSe does not support V2X communication before Release 14,
   but it has some very good characteristics which makes it a good
   candidate for V2X besides DSRC.  ProSe communication does not have to
   go through the EPC, which will significantly reduce the latency.
   ProSe also support group and broadcast communication by means of a
   common communication path established between the UEs.

Petrescu, et al.         Expires March 24, 2016                 [Page 5]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

   There are some efforts at 3GPP Release 14, trying to address V2X
   communication.  The efforts are proposed by experts in the industry,
   and may be subject to change.  These efforts include the following:

   1.  To address the V2X use cases in 3GPP.  The use cases may have
       been defined by other SDOs, e.g.  ETSI ITS, 3GPP can reference to
       them.  Requirements for V2X communication should also be
       considered, for example network delay, packet loss rate, etc.
       [METIS-D1.1] already propose some requirements, but those are
       intended for future mobile network, which may be too critical for

   2.  To address V2X applications and messages.  The messages may
       include message defined in SAE J2735, ETSI Cooperative Awareness
       Message (CAM) and ETSI Decentralized Environmental Notification
       Message (DeNM).  The messages defined by different SDOs might be
       similar to each other.

   3.  Study of possibility to add enhancements to ProSe, and to make it
       able to support and enhance DSRC.

   4.  Study of using existing LTE technologies for unicast/multicast/
       broadcast communication.

   The above are just some examples, not an exhaustive list.

   [GPP-TR-22-885] studies many V2X services using LTE.  These services
   include V2V communication (e.g.  Cooperative Adaptive Cruise Control,
   Forwarding Collision Warning, etc), V2I/V2N communication (e.g.  Road
   Safety Services) and vehicle to pedestrian communication.  The
   services' pre-condition, service flow, post-condition, including some
   network communication requirements, such as delay, messages frequency
   and message size, are ayalyzed.

   In [GPP-TR-22-885], Cooperative Adaptive Cruise Control (CACC) allows
   a vehicle to join a group of CACC vehicles, and the benefits are to
   improve road congestion and fuel efficiency.  Member vehicles of CACC
   group should periodically broadcast messages including the CACC group
   information, such as speed and gap policies, etc.  If a vehicle
   outside the group wants to join, it should send a request to the
   group.  If a member of the CACC group accepts the request, it should
   send a confirm message and provide necessary distance gap; and
   members of the group will update their group information.  When a
   Member wants to leave the CACC group, it should broadcast a goodbye
   message, and the driver assumes control of the vehicle.

Petrescu, et al.         Expires March 24, 2016                 [Page 6]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

6.2.  METIS

   METIS is co-funded by the European Commission as an Integrated
   Project under the Seventh Framework Programme for research and
   development (FP7).

   METIS defines test cases and requirements of "Traffic safety and
   efficiency", as depicted in [METIS-D1.1], which is intended for 5G in
   2020 but may also be applicable for LTE and beyond.

   The use cases include:

   1.  Dangerous situation that can be avoided by means of V2V

   2.  Dangerous situation with vulnerable road users (i.e. pedestrians,
       cyclists,...) that can be avoided by means of V2D communications.
       "D" can denote any cellular device that the vulnerable road user
       may carry (e.g. smart phone, tablet, sensor tag).

   3.  Assistance services that can improve traffic efficiency by means
       of V2X communications, e.g. traffic sign recognition and green
       light assistance.

   4.  Platooning (or road trains) in an autonomous manner to increase
       traffic flows and reduce fuel consumption and emissions.

   5.  Highly automated vehicles.

   To support the above use cases, METIS works out the corresponding
   network requirements, such as E2E latency should be within 5ms,
   required data rates for various scenarios, service ranges in
   highway/rural/urban scenarios, etc.

7.  ISO perspective on V2V

   The International Standards Organization's Technical Committee 204
   "Intelligent transport systems" (ISO TC204, in short) has specified a
   communication architecture known as the "ITS station reference
   communication architecture" [ISO-21217].  This communication
   architecture covers all layers (access technologies, network,
   transport, facilities and applications) of a typical communications
   protocol stack.  It is designed to accommodate communications between
   ITS stations engaged in ITS services.  ITS stations can be deployed
   in vehicles of any type, roadside infrastructure (traffic lights,
   variable message signs, toll road gantries, etc.), urban
   infrastructure (parking gates, bus stops, etc.) nomadic devices
   (smartphones, tablets) and control centers (traffic control center,

Petrescu, et al.         Expires March 24, 2016                 [Page 7]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

   emergency call centers, data centers and services centers).  The ITS
   stations can be distributed in several nodes (e.g. an in-vehicle
   gateway and a set of hosts attached to the internal in-vehicle
   network).  The ITS station architecture is designed to support many
   kinds of wired and wireless access technologies (vehicular WiFi
   802.11p, urban WiFi 802.11b/g/n/ac/ad; cellular networks; satellite;
   infra-red, LiFi, millimeter wave, etc.)

   The ISO ITS station architecture can thus support both broadcast and
   unicast types of communication, vehicle-to-infrastructure
   communications (road infrastructure using e.g.  WiFi, or cellular
   infrastructure using e.g. 3G/4G) and, most notably, direct vehicle-
   to-vehicle communications.

   The architecture includes the possibility to communicate using IPv6
   [ISO-21210] or non-IP (ISO FNTP, currently being harmonized with IEEE

   The ISO TC204/WG14 (Work Group 14 "Vehicle/Roadway Warning and
   Control Systems") is developing a draft of international standard for
   C-ACC systems.  The focus is on vehicular system control, rather than
   on communication media.  The potential work item is in an early stage
   of development; it may describe performance requirements or
   validation through test procedures.  It is considered that "C-ACC" to
   be an expansion to the existing ACC concepts which have been
   previously described in the document ISO 15622 "Adaptive Cruise
   Control Systems".  The potential C-ACC work item may require the
   specific involvement of Vehicle-to-Vehicle communications and other
   types of communications (I2V and more), in addition to requiring
   active sensing involving radars and camera systems.

8.  FirstNet EMS use of LTE and IP in V2I2V

   FirstNet is a corporation housed inside the US Department of
   Commerce.  It gets capitalization budget from, among other sources,
   sale of spectrum by the US FCC.  It gets operating budget from sale
   of services to state emergency services entities.

   The specific use-cases for FirstNet include vehicle-to-vehicle,
   vehicle-to-infrastructure and vehicle-to-infrastructure-to-vehicle
   communications using in certain cases LTE and IP:

   1.  Emergency communications to vehicles from government entities
       conveying, for example: weather warnings, road conditions,
       evacuation orders.  The government entities might include PSAPs
       or mobile vehicles such as police cruisers.

Petrescu, et al.         Expires March 24, 2016                 [Page 8]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

   2.  Instrumented emergency services vehicles such as ambulances.  An
       example is the ability to telemeter casualty (patient) data from
       sensors attached to the casualty to a hospital emergency room.

   3.  Emergency communications from vehicles' occupants to government
       entities such as Public Safety Access Points (PSAPs, also known
       as 911 operators in US).

   The National Public Safety Telecommunications Council describes
   FirstNet as an emergency communications system (largely viewed
   through the prism of the familiar Land Mobile Radio systems most
   emergency services use.)  The cellular telephone industry views
   FirstNet as supplementary to an existing commercial cellphone system
   (e.g. reusing the same towers and backhaul).  Perhaps a better view
   of FirstNet is as an extension of the Internet to emergency services
   vehicles (including foot-borne).

   It is clear that FirstNet overlaps to a large extent to the concepts
   that have been discussed in vehicle-to-vehicle communications for
   other purposes.

   FirstNet has not been clear about its communication technology
   choices to date.  But LTE has been discussed as the most likely layer
   2 protocol.  A segregated segment of spectrum in the 700MHz band has
   been set aside by Congressional action for emergency services and
   control of that spectrum has been passed to FirstNet.  There appear
   to be no new protocols, development of which is fostered by FirstNet.
   Several Internet applications would need rework to handle high
   availability, security and assured access needs of emergency

9.  Internet apps: WAZE, iRezQ, Coyote, Sentinel

   Applications using the Internet have been developped in the
   particular context of vehicular communications.  These applications
   are designed for parties situated in vehicles.  Their profile is less
   of client-server kind, but more of peer-to-peer kind (vehicle to

   Some use vehicle-to-infrastructure-to-vehicle IP paths, whereas
   others involve direct vehicle-to-vehicle paths (without

   These applications are described in more detail in draft-liu-its-
   scenario-00.txt issued on March 9th, 2015, authored by Dapeng Liu.

Petrescu, et al.         Expires March 24, 2016                 [Page 9]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

10.  Gap Analysis

   It is generally agreed that an entire IP network is embedded in an
   automobile.  The embedded network is formed by at least two (and
   generally up to 5) distinct IP subnets.  In each of the subnets
   several IP-addressable computers are currently enabled with IP

   The realization of V2V communications can happen by connecting
   together two such embedded networks, each carried by a distinct
   vehicle.  With a direct connection, an IP Router in one vehicle
   connects to an IP Router in another vehicle nearby.  The maximum
   distance between two such vehicles is dictated by the link layer
   technology (e.g., with IEEE 802.11p OCB mode the distance may be up
   to 800 metres).  On another hand, an indirect connection may involve
   the use of a Road-Side Unit fixed along the road, or a longer IP path
   through a cellular network.  It is expected that the shortest
   latencies to be obtained with the most straightforward (direct)
   connections rather than through-fixed-RSU through-cellular.

   When two vehicles are connected to each other in this way, an IP
   subnet is formed between the egress interfaces of Router embedded in
   vehicles.  There are several ways in which the IP path can be
   established across this 1-hop subnet.

10.1.  Neighbor Discovery protocol

   Routers exchange Router Advertisement messages.  An RA message
   contains prefixes announced to be valid on one link.  On another
   hand, the prefix announced by an RA can not be equal to the prefix of
   a same router but of one of its other interfaces.  And this
   represents the gap of the ND protocol - it can not realize V2V

10.2.  Mobile IP protocol

   There are two modes of operation of a V2V topology.  With a link
   technology like IEEE 802.11b it is possible that one vehicle attaches
   to another vehicle in "Access Point" mode, or alternatively in "ad-
   hoc" mode.  In "Access Point" mode (or Client-Server), the first
   vehicle allocates an address, and potentially a prefix, to the second
   vehicle.  This latter may then use the Mobile IP protocol to inform
   the first vehicle about is in-car prefix (use a Binding Update
   message as if the Access Point vehicle were a Correspondent Node).
   The gap is in that currently the Mobile IP protocol is not fully
   specified to send BUs in that way.

Petrescu, et al.         Expires March 24, 2016                [Page 10]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

10.3.  AODV protocol

   The AODV protocol is a routing protocol used to build and find IP
   paths in a MANET network.  However, this protocol does not take into
   account default routes.  Default routes are extensively used in
   current networks carried in vehicles.  The good administration of
   these routes simplify to a large extent the routing in such networks.
   This represents a gap.

11.  Security Considerations

   All government-to-vehicle and vehicle-to-government communications
   require authenticity; there will be no exceptions.

   Some, but not all, communications from government-to-vehicle and
   vehicle-to-government require confidentiality (some of these
   requirements, such as medical data, have the force of law, many have
   custom or respect as the requirements base).

   These requirements pertain to the content.

12.  IANA Considerations


13.  Contributors

   Jim Misener (Qualcomm, SAE DSRC TC Chair), Masanori Misumi (Mazda,
   ISO TC204/WG14 Convenor), Michelle Wetterwald (FBConsulting, ETSI
   active member).

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

14.2.  Informative References

              3GPP, "Feasibility study for Proximity Services (ProSe)",
              June 2013.

              3GPP, "Study on LTE Support for V2X Services", April 2015.

Petrescu, et al.         Expires March 24, 2016                [Page 11]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

              3GPP, "Service requirements for the Evolved Packet System
              (EPS)", December 2014.

              Petrescu, A., Pfister, P., Benamar, N., and T.
              Leinmueller, "Transmission of IPv6 Packets over IEEE
              802.11p Networks", draft-petrescu-ipv6-over-80211p-02
              (work in progress), June 2014.

              ISO, "21210: TC ITS - WG CALM - IPv6 Networking -
              International Standard", 2014.

              ISO, "21217: TC ITS - WG CALM - Architecture -
              International Standard", 2014.

              Fallgren, M. and B. Timus, "Scenarios, requirements and
              KPIs for 5G mobile and wireless system", April 2013.

Appendix A.  ChangeLog

   The changes are listed in reverse chronological order, most recent
   changes appearing at the top of the list.

   From -01 to -02:

   o  Added perspectives on C-ACC and Platooning from ETSI, SAE, and
      IEEE P1609.  Updated the perspective from ISO.

   o  Added Gap Analysis: what are the gaps between what existing
      protocols ND, Mobile IP and AODV can do and what is needed to
      realize a C-ACC and Platooning use-case with a V2V topology?

   From nil to draft-petrescu-its-cacc-sdo-00.xml:

   o  initial version

Authors' Addresses

Petrescu, et al.         Expires March 24, 2016                [Page 12]

Internet-Draft      C-ACC at SDOs and IP Gap Analysis     September 2015

   Alexandre Petrescu (editor)
   CEA Saclay
   Gif-sur-Yvette , Ile-de-France   91190

   Phone: +33169089223
   Email: Alexandre.Petrescu@cea.fr

   James Huang
   Huawei Technologies

   Email: james.huang@huawei.com

   Thierry Ernst
   Mines ParisTech
   Paris   75006

   Email: Thierry.Ernst@mines-paristech.fr

   Rex Buddenberg
   " "

   Email: buddenbergr@gmail.com

Petrescu, et al.         Expires March 24, 2016                [Page 13]

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