IEEE Std 1609.0 2013, Guide For Wireless Access In Vehicular Environments (WAVE)—Architecture （2004）IEEE (WAVE) Architecture
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 78
| Download | |
| Open PDF In Browser | View PDF |
IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture IEEE Vehicular Technology Society Sponsored by the Intelligent Transportation Systems Committee IEEE 3 Park Avenue New York, NY 10016-5997 USA IEEE Std 1609.0™-2013 Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0™-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Sponsor Intelligent Transportation Systems Committee of the IEEE Vehicular Technology Society Approved 11 December 2013 IEEE-SA Standards Board Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Abstract: The wireless access in vehicular environments (WAVE) architecture and services necessary for WAVE devices to communicate in a mobile vehicular environment are described in this guide. It is meant to be used in conjunction with the family of IEEE 1609 standards as of its publication date. These include IEEE Std 1609.2™, IEEE Standard Security Services for Applications and Management Messages, IEEE Std 1609.3 Networking Services, IEEE Std 1609.4 Multi-Channel Operation, IEEE Std 1609.11 Over-the-Air Electronic Payment Data Exchange Protocol for Intelligent Transportation Systems (ITS), IEEE Std 1609.12 Identifier Allocations, and IEEE Std 802.11 in operation outside the context of a basic service set. Keywords: dedicated short range communications, DSRC, IEEE 1609.0™, OBU, onboard unit, Provider Service Identifier (PSID), roadside unit (RSU), WAVE, WAVE service advertisement, WAVE Short Message, WAVE Short Message Protocol, wireless access in vehicular environments, WSA, WSM, WSMP • The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2014 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 5 March 2014. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Incorporated. PDF: ISBN 978-0-7381-8756-3 STD98459 Print: ISBN 978-0-7381-8757-0 STDPD98459 IEEE prohibits discrimination, harassment, and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. ii Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Important Notices and Disclaimers Concerning IEEE Standards Documents IEEE documents are made available for use subject to important notices and legal disclaimers. These notices and disclaimers, or a reference to this page, appear in all standards and may be found under the heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Standards Documents.” Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Documents IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a consensus development process, approved by the American National Standards Institute (“ANSI”), which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and participate without compensation from IEEE. While IEEE administers the process and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards. IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly disclaims all warranties (express, implied and statutory) not included in this or any other document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort. IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.” Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard. IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE. Translations The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard. iii Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Official statements A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position of IEEE. Comments on standards Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that any responses to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to comments or questions except in those cases where the matter has previously been addressed. For the same reason, IEEE does not respond to interpretation requests. Any person who would like to participate in revisions to an IEEE standard is welcome to join the relevant IEEE working group. Comments on standards should be submitted to the following address: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA Laws and regulations Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so. Copyrights IEEE draft and approved standards are copyrighted by IEEE under U. S. and international copyright laws. They are made available by IEEE and are adopted for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making these documents available for use and adoption by public authorities and private users, IEEE does not waive any rights in copyright to the documents. Photocopies Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy portions of any individual standard for company or organizational internal use or individual, non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. iv Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Updating of IEEE Standards documents Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE standard. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at http://ieeexplore.ieee.org/xpl/standards.jsp or contact IEEE at the address listed previously. For more information about the IEEE SA or IEEE’s standards development process, visit the IEEE-SA Website at http://standards.ieee.org. Errata Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL: http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically. Patents Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association. v Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Participants At the time this guide was completed, the Wireless Access in Vehicular Environments (WAVE) Working Group had the following membership: Thomas M. Kurihara, Chair John Moring, Vice Chair William Whyte, Vice Chair Scott Andrews Lee Armstrong Jerome Chiu Hans-Joachim Fischer Wayne Fisher Ramez Gerges Ali Ghandour Refi-Tugrul Güner Gloria Gwynne Ron Hochnadel Carl Kain Doug Kavner David Kelley John Kenney Jerry Landt Mike Lin Julius Madey Alastair Malarky Justin McNew Gary Pruitt Robert Rausch Randy Roebuck Richard Roy Steve Sill François Simon Ramesh Siripurapu Jason Tran Huei-Ru Tseng George Vlantis The following members of the individual balloting committee voted on this guide. Balloters may have voted for approval, disapproval, or abstention. Lee Armstrong Harry Bims Bill Brown William Byrd Scott Cadzow Keith Chow Michael Coop Patrick Diamond Susan Dickey Sourav Dutta Richard Edgar Marc Emmelmann Andre Fournier Avraham Freedman H. Glickenstein Randall Groves Tugrul Guener Gloria Gwynne Ron Hochnadel Werner Hoelzl Chung-Hsien Hsu Noriyuki Ikeuchi Piotr Karocki John Kenney Stuart Kerry Stanley Klein Thomas M. Kurihara Paul Lambert Jeremy Landt Hsia-Hsin Li William Lumpkins Julius Madey Alastair Malarky Justin McNew John Moring Ronald Murias Michael Newman Satoshi Obara Satoshi Oyama Markus Riederer Robert Robinson Jeff Rockower Richard Roy Randall Safier Bartien Sayogo Gil Shultz Thomas Starai Eugene Stoudenmire Walter Struppler Jasja Tijink John Vergis George Vlantis Stephen Webb Hung-Yu Wei William Whyte Oren Yuen Daidi Zhong vi Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. When the IEEE-SA Standards Board approved this guide on 11 December 2013 it had the following membership: John Kulick, Chair David J. Law, Vice Chair Richard H. Hulett, Past Chair Konstantinos Karachalios, Secretary Masayuki Ariyoshi Peter Balma Farooq Bari Ted Burse Stephen Dukes Jean-Philippe Faure Alexander Gelman Mark Halpin Gary Hoffman Paul Houzé Jim Hughes Michael Janezic Joseph L. Koepfinger* Oleg Logvinov Ron Petersen Gary Robinson Jon Walter Rosdahl Adrian Stephens Peter Sutherland Yatin Trivedi Phil Winston Yu Yuan *Member Emeritus Also included are the following nonvoting IEEE-SA Standards Board liaisons: Richard DeBlasio, DOE Representative Michael Janezic, NIST Representative Catherine Berger Senior Program Manager, IEEE-SA Content Publishing Michael Kipness Program Manager, IEEE-SA Technical Community vii Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Contents 1. Overview .................................................................................................................................................... 1 1.1 Scope ................................................................................................................................................... 2 1.2 Aspects of a WAVE system ................................................................................................................ 2 2. Normative references.................................................................................................................................. 3 3. Definitions, abbreviation, and acronyms .................................................................................................... 3 3.1 Definitions ........................................................................................................................................... 3 3.2 Abbreviations and acronyms ............................................................................................................... 6 4. Relevant standards ...................................................................................................................................... 7 4.1 Overview of Intelligent Transportation Systems and the National ITS architecture ........................... 7 4.2 ASTM and the Federal Communications Commission (FCC) ............................................................ 8 4.3 IEEE standards .................................................................................................................................... 8 4.4 SAE DSRC standards ........................................................................................................................ 12 4.5 Related standards and organizations .................................................................................................. 13 5. WAVE system overview .......................................................................................................................... 15 5.1 General .............................................................................................................................................. 15 5.2 System components and connectivity ................................................................................................ 15 5.3 Protocols ............................................................................................................................................ 16 5.4 Interfaces ........................................................................................................................................... 18 5.5 The 5.9 GHz spectrum allocation ...................................................................................................... 19 5.6 Channel types .................................................................................................................................... 20 5.7 Communication services.................................................................................................................... 21 5.8 WAVE Service Advertisement .......................................................................................................... 25 5.9 Addresses and identifiers ................................................................................................................... 28 5.10 Priorities .......................................................................................................................................... 30 5.11 Channel coordination and time synchronization .............................................................................. 30 5.12 Other features .................................................................................................................................. 32 5.13 Security considerations .................................................................................................................... 34 Annex A (informative) Example system configuration ................................................................................ 53 Annex B (informative) Certification ............................................................................................................ 54 B.1 Scope ................................................................................................................................................. 54 B.2 Process .............................................................................................................................................. 55 Annex C (informative) Representative use cases ......................................................................................... 56 C.1 Vehicle communication for collision avoidance ............................................................................... 56 C.2 Electronic fee collection.................................................................................................................... 57 Annex D (informative) International ITS documents ................................................................................... 63 Annex E (informative) Mapping PSID values to a contiguous set of integers ............................................. 64 Annex F (informative) Deployment history ................................................................................................. 65 Annex G (informative) Bibliography ........................................................................................................... 67 viii Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, health, or environmental protection, or ensure against interference with or from other devices or networks. Implementers of IEEE Standards documents are responsible for determining and complying with all appropriate safety, security, environmental, health, and interference protection practices and all applicable laws and regulations. This IEEE document is made available for use subject to important notices and legal disclaimers. These notices and disclaimers appear in all publications containing this document and may be found under the heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html. 1. Overview A wireless access in vehicular environments (WAVE) system is a radio communication system intended to provide seamless, interoperable services to transportation. These services include those recognized by the U. S. National Intelligent Transportation Systems (ITS) architecture and many others contemplated by the automotive and transportation infrastructure industries around the world, such as communications between vehicles and infrastructure, and communications among vehicles. This guide provides an overview of the system, its components, and its operation. It is intended to provide a context within which to better understand the content of the related IEEE WAVE standards documents, which include IEEE Std 1609.2™-2013, IEEE Std 1609.3™-2010, IEEE Std 1609.4™-2010, IEEE P1609.6™ [B19],1, 2 IEEE Std 1609.11™-2010, and IEEE Std 1609.12™, as well as IEEE Std 802.11™-2012 [stations communicating outside the context of a Basic Service Set (BSS), or OCB].3 The term dedicated short range communications (DSRC) is sometimes used in the U. S. to refer to radio spectrum or technologies associated with WAVE. For example, U. S. Federal Communications Commission (FCC) documents [B6] allocate spectrum to “mobile service for use by DSRC systems operating in the Intelligent Transportation System (ITS) radio service,” and the Society of Automotive Engineers (SAE) has specified messages in SAE J2735 “for use by applications intended to utilize the 5.9 GHz dedicated short range communications for wireless access in vehicular environments.” Outside the 1 The numbers in brackets correspond to those of the bibliography in Annex G. Numbers preceded by P are IEEE authorized standards projects that were not approved by the IEEE-SA Standards Board at the time this publication went to press. 3 Information on references can be found in Clause 2. 2 1 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture U. S., DSRC may refer to a distinct radio technology operating at 5.8 GHz, used, e.g., for electronic fee collection. 1.1 Scope This guide describes the architecture and operation of a WAVE system based on IEEE 1609 standards and IEEE Std 802.11-2012. 1.2 Aspects of a WAVE system 1.2.1 Introduction ISO/IEC 42010:2007 [B28] is a recommended practice for architectural description of software-intensive systems, and defines several aspects of any system: an environment or context, stakeholders who typically have interest in or concerns relative to the system, and one or more missions. These aspects are addressed in 1.2.2 through 1.2.5. 1.2.2 Environment As its name suggests, the WAVE system as presently envisaged is designed to meet the communication needs of mobile elements in the transportation sector. While in many of the usage scenarios at least one of the devices engaged in WAVE communications is expected to be associated with a vehicle, other devices, both fixed and portable (e.g., roadside and pedestrian) are envisaged as well. 1.2.3 Stakeholders This document is intended to be a useful reference for any of the direct stakeholders including the following: ⎯ Government agencies, e.g., national and state road operators. ⎯ Vehicle designers and original equipment manufacturers. ⎯ Aftermarket equipment makers. ⎯ Developers of applications and related standards. Indirect stakeholders include anyone who uses or is otherwise affected by the intelligent transportation systems built using the WAVE standards. 1.2.4 Mission The WAVE standards enable the development of interoperable low-latency, low overhead WAVE devices that can provide communications in support of transportation safety, efficiency and sustainability, and that can enhance user comfort and convenience. 2 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 1.2.5 Views This document presents several architectural representations, or views. These include a device view (see, e.g., 4.3.3.2 and 4.3.3.3), a protocol view (see, e.g., 5.3.1), and a standards view (see, e.g., 4.3.3.1). 2. Normative references The following referenced documents are indispensable for the application of this document (i.e., they must be understood and used, so each referenced document is cited in text and its relationship to this document is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies. Additional, non-essential references may be found in the bibliography in Annex G. IEEE Std 802.11-2012, IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications.4, 5 IEEE Std 1609.2-2013, IEEE Standard for Wireless Access in Vehicular Environments (WAVE)—Security Services for Applications and Management Messages. IEEE Std 1609.3-2010, IEEE Standard for Wireless Access in Vehicular Environments (WAVE)— Networking Services. IEEE Std 1609.4-2010, IEEE Standard for Wireless Access in Vehicular Environments (WAVE)—MultiChannel Operation. IEEE Std 1609.11-2010, IEEE Standard for Wireless Access in Vehicular Environments (WAVE)—Overthe-Air Electronic Payment Data Exchange Protocol for Intelligent Transportation Systems (ITS). IEEE Std 1609.12, IEEE Standard for Wireless Access in Vehicular Environments (WAVE)—Identifier Allocations. SAE J2735-2009, Dedicated Short Range Communications (DSRC) Message Set Dictionary.6 3. Definitions, abbreviation, and acronyms 3.1 Definitions For the purposes of this document, the following terms and definitions apply. The IEEE Standards Dictionary Online or IEEE Std 802.11-2012 should be consulted for terms not defined in this clause.7 advertised application-service opportunity: A resource consisting of a service channel (SCH) within geographic and temporal bounds, intended for support of an application-service as indicated by the 4 IEEE publications are available from the Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/). 5 The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc. 6 SAE publications are available from the Society of Automotive Engineers, 400 Commonwealth Drive, Warrendale, PA 15096, USA (http://www.sae.org/). 7 IEEE Standards Dictionary Online subscription is available at: http://www.ieee.org/portal/innovate/products/standard/standards_dictionary.html. 3 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture transmission of a WAVE Service Advertisement (WSA) with Service Info and Channel Info referring to that application-service and SCH. application: A higher layer entity that may make use of WAVE communication facilities. application-service: A service, involving an exchange of data, generally provided by a higher layer entity on one WAVE device to a similar entity on another WAVE device, using WAVE communications. certificate authority (CA): An authority trusted to issue digital certificates. certificate chain: A top-to-bottom ordered list of digital certificates such that each certificate other than the top one is issued by the one above it in the chain. control channel (CCH): A radio channel limited by the WAVE standards to the exchange of management frames and WAVE Short Messages. cryptomaterial handle (CMH): A reference used by entities outside WAVE Security Services to refer to private keys and associated public key material stored within WAVE Security Services. data plane: A set of communication protocols defined to carry application and management data. The data plane provides protocol stack(s) for the transfer of data through a device for transfer over-the-air. digital certificate: An electronic document that binds information about an entity to a public key owned by the entity (i.e., a key to which the entity knows the corresponding private key), along with a cryptographic proof that the binding statement is made by a trusted authority (known as the issuer). ethertype: The Ethernet Type field defined in IETF RFC 1042, used to identify the higher layer protocol above logical link control. higher layer entity: An entity, such as an application, that resides above the WAVE protocols in the protocol stack and may make use of WAVE communication services. management plane: A collection of functions performed in support of the communication functions provided by the data plane, but not directly involved in passing application data. The management plane may employ lower layers of the data plane to transfer management information between devices. networking services: A collection of management plane and data plane functions at the network layer and transport layer, as specified in IEEE Std 1609.3, supporting WAVE communications. onboard equipment (OBE): A collection of vehicle-mounted equipment including an onboard unit (OBU). onboard unit (OBU): A WAVE device that can operate when in motion and supports the information exchange with roadside units or other OBUs. participant: A WAVE device that is tuned to a channel for the purpose accessing an (advertised or unadvertised) application-service opportunity. Provider: A WAVE device that transmits a WAVE Service Advertisement (WSA) containing Service Info indicating an advertised application-service opportunity, and is a participant in that advertised applicationservice opportunity. See also: User. Provider Service Context (PSC): A field within the WAVE Service Advertisement (WSA), associated with a Provider Service Identifier (PSID), containing supplementary information related to the applicationservice. The internal format of the PSC is dependent on the PSID value with which it is associated. 4 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Provider Service Identifier (PSID): An identifier of an application-service provided by a higher layer entity. roadside equipment (RSE): A collection of roadside equipment including a roadside unit (RSU). roadside unit (RSU): A WAVE device that operates only when stationary and supports information exchange with onboard units (OBUs). root certificate: A digital certificate that is issued by itself, i.e., that is verified using the public key contained in the certificate rather than a public key contained in a different certificate. root certificate authority: A certificate authority that holds a root certificate. secure data exchange entity (SDEE): A higher layer entity, such as an application, that originates or receives secured data-plane protocol data units (PDUs.) service channel (SCH): Any channel that is not the control channel. trust anchor: Any digital certificate which can be trusted on its own merits, i.e., without ensuring that it is part of a certificate chain up to an already-trusted issuer. unadvertised application-service opportunity: A resource consisting of a channel within geographic and temporal bounds, intended for support of an application-service, where no WSA with Service Info and Channel Info referring to that application-service and channel is transmitted. User: A WAVE device that monitors received WAVE Service Advertisements (WSAs) for an advertised application-service opportunity of interest. See also: Provider. user priority: A priority level assigned to a packet that is ready for transmission, which determines its treatment at the medium access control (MAC) layer. WAVE device: A device that is compliant to IEEE Std 1609.3, IEEE Std 1609.4, and IEEE Std 802.11, operating outside the context of a basic service set [outside the context of a(n IEEE 802.11) basic service set (OCB)]. WAVE management entity (WME): A set of management functions providing WAVE Networking Services. WAVE Routing Advertisement (WRA): IPv6 network configuration information broadcast as part of a WAVE Service Advertisement. WAVE Service Advertisement (WSA): A management message type, containing information including the announcement of the availability of an application-service. WAVE Short Message (WSM): A packet consisting of WSM data and a WAVE Short Message Protocol (WSMP) header. WAVE Short Message Protocol (WSMP): A protocol for rapid exchange of messages in a rapidly varying radio frequency (RF) environment where low latency may also be an important objective. 5 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 3.2 Abbreviations and acronyms AASHTO AES BSS CA CALM CCH CEN CMH CRL CV DNS DOT DSRC EDCA ETSI FCC GPS ICMPv6 IETF IP IPv6 ISO ITS LLC LSAP LSI-S MAC MIB MLME MLMEX MTU OBE OBU OCB OFDM OID OSI PDU PHY PLME PSC PSID PSSME QC RF RFC RSE RSU American Association of State Highway and Transportation Officials Advanced Encryption Standard basic service set certificate authority communications access for land mobiles control channel Comité Européen de Normalisation, European Committee for Standardization cryptomaterial handle certificate revocation list connected vehicle domain name system Department of Transportation dedicated short range communications Enhanced Distributed Channel Access European Telecommunications Standards Institute Federal Communications Commission Global Positioning System Internet Control Message Protocol for IPv6 Internet Engineering Task Force Internet Protocol Internet Protocol version 6 International Organization for Standardization Intelligent Transportation Systems logical link control link service access point local service indicator for security medium access control management information base MAC sublayer management entity MLME extension maximum transmission unit onboard equipment onboard unit outside the context of a(n IEEE 802.11) basic service set orthogonal frequency division multiplexing object identifier open systems interconnect protocol data unit physical layer physical layer management entity Provider Service Context Provider Service Identifier Provider Service Security Management Entity quality control radio frequency Request for Comments roadside equipment roadside unit 6 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture SAP SCH SDEE SME SNAP TCP TLS UDP U. S. UTC V2I V2V VII WAVE WME WRA WSA WSM WSMP service access point service channel secure data exchange entity Station Management Entity Subnetwork Access Protocol Transmission Control Protocol Transport Layer Security User Datagram Protocol United States of America Coordinated Universal Time vehicle-to-infrastructure vehicle-to-vehicle vehicle infrastructure integration Wireless Access in Vehicular Environments WAVE Management Entity WAVE Routing Advertisement WAVE Service Advertisement WAVE Short Message WAVE Short Message Protocol 4. Relevant standards 4.1 Overview of Intelligent Transportation Systems and the National ITS architecture This subclause provides a brief context for the WAVE standards, and includes information on related activities. Intelligent Transportation Systems (ITS) are being developed throughout the world. The United States ITS program was created by Congress in the Intermodal Surface Transportation Efficiency Act of 1991, and is administered by the U. S. Department of Transportation (DOT). The program uses advanced electronics to improve traveler safety, decrease traffic congestion, facilitate the reduction of air pollution, and conserve vital fossil fuels. ITS improve transportation safety and mobility and enhances productivity through the use of advanced communications and information systems technologies. ITS encompass a broad range of fixed and mobile communications-based information and electronics technologies. When integrated into the transportation system’s infrastructure, and into vehicles themselves, these technologies relieve congestion, improve safety, and enhance productivity. One of the key initiatives within the U. S. ITS program is the National ITS Architecture. The National ITS Architecture is the definitive framework that will guide deployment of intelligent transportation systems in the U.S. for the next 20 years or more. The latest version of the National ITS Architecture is Version 7, the details of which can be found at: http://www.its.dot.gov/arch. The National ITS Architecture provides a common framework for planning, defining, and integrating intelligent transportation systems. The architecture defines the following: ⎯ Functions (e.g., gather traffic information or request a route) that are required for ITS. ⎯ Physical entities or subsystems where these functions reside (e.g., the field or the vehicle). 7 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ Information flows and data flows that connect these functions and physical subsystems together into an integrated subsystem. This architecture guide focuses on the physical entities or subsystems of an ITS architecture, for example the U. S. National ITS Architecture. The National ITS Architecture describes a physical representation (though not a detailed design) of how the system provides the required functionality. Four categories of subsystems are identified: Travelers (e.g., Remote Traveler Support, Personal Information Access), Centers (e.g., Traffic Management, Emergency Management), Vehicles, and Field (e.g., Roadway Payment, Parking Management). The roadside unit (RSU) exists in the “Field” area, and the onboard unit (OBU) exists in the “Vehicle” area. The WAVE communications provide vehicle-vehicle communications and field-vehicle communications. 4.2 ASTM and the Federal Communications Commission (FCC) Pursuant to the Transportation Equity Act for the 21st Century, the U. S. FCC, in consultation with the U. S. DOT, allocated the 5.850–5.925 GHz band to DSRC in October 1999. (See 5.6.) On November 7, 2002, the FCC adopted a Notice of Proposed Rule Making (NPRM) seeking comment on proposed DSRC service rules in the 5.9 GHz band, and on December 17, 2003, it adopted the DSRC service rules. To promote the widespread use and evaluation of intelligent vehicle-highway systems technology, the Commission in the DSRC Report and Order FCC 03-0324 [B7] adopted the ASTM E2213-03 Standard (ASTM-DSRC) [B1], which was supported by most commenters and which had been developed under an accredited standard setting process. To achieve interoperability, allow open eligibility, and encourage the development of a market for equipment that will meet the needs of public safety DSRC licensees, the rules adopted by the FCC require all DSRC operations in the 5.9 GHz band to comply with the ASTM-DSRC standard. DSRC Roadside Units (i.e., communication units that are fixed along the roadside) are licensed under Part 90 Subpart M of the FCC rules (“Intelligent Transportation Systems Radio Service”). RSU licensees receive non-exclusive geographic-area licenses authorizing operation on seventy of the seventyfive megahertz of the 5.9 GHz band. OBUs are licensed by rule under new Subpart L of Part 95 of the FCC rules; OBU operation is not geographically restricted by FCC license. Since 2003, work has continued on IEEE standards for the 5.9 GHz band, making the FCC reference to the ASTM-DSRC standard obsolete. It is currently expected that equipment deployed in the 5.9 GHz band in the U. S. will be compliant to the IEEE 1609 family of standards and IEEE Std 802.11-2012. 4.3 IEEE standards 4.3.1 Trial-use WAVE standards—historical In 2006 and 2007, a set of IEEE 1609 standards were adopted for trial-use. The trial-use standards were used to demonstrate and prove the WAVE architecture and protocols, with the resulting lessons learned fed back into full-use standards published in 2010 and beyond (see Annex F for an overview of field trials, and 4.3.3 for a description of subsequent standards). These IEEE 1609 trial-use standards, which were developed for use with IEEE Std 802.11p (now IEEE Std 802.11-2012; see 4.3.2), are depicted in Figure 1 and described following. 8 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure 1 ―Trial-use standards IEEE Std 1609.4-2006 [B18] specified extensions to the IEEE Std 802.11-2012 MAC layer for multichannel operations, e.g., operating alternately on the control channel and one of several service channels. It has been superseded by IEEE Std 1609.4-2010. IEEE Std 1609.3-2007 [B17] specified networking services required for operation of a WAVE system. It employs the standard IPv6 protocol, introduces a WAVE Short Message Protocol (WSMP), and provides a collection of management functions supporting WAVE services. It has been superseded by IEEE Std 1609.3-2010. IEEE Std 1609.2-2006 [B16] collected the security processing requirements necessary for WAVE system operation. It has been superseded by IEEE Std 1609.2-2013. IEEE Std 1609.1-2006 [B15] was found unnecessary for WAVE system operation; it has been withdrawn and no revision is planned. 4.3.2 IEEE Std 802.11 IEEE Std 802.11-2012 specifies one medium access control (MAC) sublayer and several physical layers (PHYs) to provide wireless connectivity among fixed, portable, and moving stations (STAs) within a local area. IEEE Std 802.11p-2010 [B12], now incorporated in IEEE Std 802.11-2012, standardized a small number of extensions to IEEE Std 802.11-2012 for operating outside the context of a basic service set (OCB, i.e., with the dot11OCBActivated parameter set to true), that is, supporting the types of vehicular scenarios required for WAVE system operation. IEEE Std 802.11p-2010 [B12] also standardized the 5.9 GHz OFDM PHY (5.850–5.925 GHz in the U. S., 5.855–5.925 GHz in Europe), channel bandwidths, operating classes, transmit power classification, transmission masks, and the alternate channel and alternate adjacent channel rejection requirements. 9 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 4.3.3 Full-use WAVE standards 4.3.3.1 IEEE 1609 standards 1609.3 802.11 1609.4 Management Security Full-use WAVE standards are in the process of being published as illustrated in Figure 2 and are described in the following subclauses. These are the standards that are reflected in the descriptions throughout this document. Differences between trial-use and full-use standards are summarized in Annex F. Figure 2 ― Full-use standards IEEE Std 1609.4-2010 (Multi-Channel Operations) specifies extensions to the IEEE 802.11 MAC layer protocol and includes the following features: ⎯ Channel timing and switching ⎯ Use of IEEE 802.11 facilities [e.g., channel access, Enhanced Distributed Channel Access (EDCA)] outside the context of a BSS ⎯ Use of IEEE 802.11 Vendor Specific Action and Timing Advertisement frames in a WAVE system ⎯ MAC-layer readdressing in support of pseudonymity IEEE Std 1609.3-2010 (Networking Services) includes the following features: ⎯ WAVE Service Advertisements and channel scheduling ⎯ WAVE Short Message Protocol 10 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ Use of existing protocols, e.g., LLC and IPv6, including streamlined IPv6 configuration ⎯ Delivery of general management information over the air interface IEEE Std 1609.2-2013 (Security Services for Applications and Management Messages) specifies communications security for WAVE Service Advertisements and WAVE Short Messages and additional security services that may be provided to higher layers. IEEE P1609.5 (Communication Manager) is an open project for addressing network management requirements. IEEE P1609.6 (Remote Management Services), in development, includes over-the-air management and alias features. IEEE Std 1609.11-2010 (Over-the-Air Electronic Payment Data Exchange Protocol for ITS) is the first application-level IEEE 1609 standard and specifies a payment protocol referencing ISO standards. An example use case illustrating electronic fee collection is provided in C.2. IEEE Std 1609.12-2012 (Identifier Allocations) records the Provider Service Identifier (PSID) allocation decisions made by the IEEE 1609 working group, and other identifiers used by the WAVE standards, including Object Identifier (OID), Ethertype, and Management ID. Other WAVE standards may be developed to specify higher layer, or application, features. 4.3.3.2 “WAVE device” and standards conformance The IEEE 1609 standards include the concept of a WAVE device, which is defined as a device that is conformant to the following: ⎯ IEEE Std 1609.3-2010. ⎯ IEEE Std 1609.4-2010. ⎯ IEEE Std 802.11-2012, operating outside the context of a basic service set. For IEEE 1609.3 conformance, a device implements at least the following high-level features: ⎯ LLC and Subnetwork Access Protocol (SNAP)—see 5.3. ⎯ IPv6 or WSMP or both. A conformant device is able to at least send or receive over one of the protocols. For IEEE 1609.4 conformance, a device implements at least the following: ⎯ Transmit or receive or both. ⎯ EDCA and user priority when transmitting. Each WAVE protocol standard (including IEEE Std 1609.3-2010, IEEE Std 1609.4-2010, and IEEE Std 1609.11-2010) includes an annex containing a Protocol Implementation Conformance Statement (PICS). The PICS references each major feature specified in the standard, with an indication of whether the feature is mandatory, optional, or conditional on the presence of some other feature. An implementer of WAVE devices may use the PICS to indicate which features are supported by an implementation; a procurer of WAVE devices may employ the PICS to indicate the features required for a particular deployment. A tester 11 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture may use the PICS as a checklist against which to verify conformance. See Annex B for a discussion of certification. 4.3.3.3 WAVE device configuration Figure 3 illustrates an example of a device with two radios, running four applications operating above the WAVE communication protocols. Higher layer (four examples shown) Proprietary Application Proprietary Application TCP UDP Safety Applications using SAE J2735 Fee Collection using IEEE Std 1609.11 WSMP IPv6 LLC MAC MAC PHY PHY Figure 3 — Example WAVE device configuration 4.4 SAE DSRC standards SAE J2735 Dedicated Short Range Communications (DSRC) Message Set Dictionary comprises a set of messages, data frames, and data elements intended for both vehicle-to-vehicle (V2V) and vehicle-toinfrastructure (the roadside) (V2I) safety exchanges. It includes specifications of each message, as well as explanatory usage text required to properly understand and implement that message. Informative annexes explain the operational concepts of several of the safety applications. SAE is also developing J2945 DSRC Minimum Performance Standards to specify the minimum communication performance requirements of the SAE J2735 DSRC message sets and associated data frames and data elements. IEEE 1609 WAVE and SAE DSRC standards are developed cooperatively; several PSID values have been allocated for use with DSRC messages. WAVE systems deployed in the U. S. are expected to use the SAE J2735 message set for safety applications. See C.1 for a use case for collision avoidance using this message set. 12 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 4.5 Related standards and organizations 4.5.1 Organizations and projects Each organization listed below includes some aspect of ITS or communications in its charter, and may be of interest to WAVE stakeholders. Annex D has a link to a list of international ITS standards. American Association of State Highway and Transportation Officials (AASHTO). AASHTO is a nonprofit, nonpartisan association representing highway and transportation departments in the 50 United States, the District of Columbia, and Puerto Rico. It represents five transportation modes: air, highways, public transportation, rail, and water. Its primary goal is to foster the development, operation, and maintenance of an integrated national transportation system. ASTM International. ASTM International, formerly the American Society for Testing and Materials, develops and delivers test methods, specifications, guides, and practices that support industries and governments worldwide. European Committee for Standardization (CEN). CEN is a major provider of European Standards and technical specifications. These standards have a unique status since they also are national standards in each of its member countries. European Telecommunications Standards Institute (ETSI). ETSI produces globally applicable standards for information and communications technologies including fixed, mobile, radio, broadcast, Internet, aeronautical, and other areas. International Organization for Standardization (ISO). ISO is a network of the national standards institutes of countries throughout the world, one member per country, with a Central Secretariat in Geneva, Switzerland, that coordinates the system. Internet Engineering Task Force (IETF). The IETF is an international group that develops and maintains Internet-related standards, including those for IPv6, TCP, and UDP. Institute of Transportation Engineers (ITE). The ITE is an international educational and scientific association of transportation professionals who are responsible for meeting mobility and safety needs. ITE facilitates the application of technology and scientific principles to research, planning, functional design, implementation, operation, policy development, and management for any mode of ground transportation. National Electrical Manufacturers Association (NEMA). NEMA is a trade association for the electrical manufacturing industry. Its member companies manufacture products used in the generation, transmission and distribution, control, and end-use of electricity. SAE International. SAE International, formerly the Society of Automotive Engineers, is a global association of more than 128,000 engineers and related technical experts in the aerospace, automotive and commercial-vehicle industries. Among other publications, SAE generated the SAE J2735 message set dictionary for use in WAVE systems, for which a usage case is presented in C.1. National Transportation Communications for ITS Protocol (NTCIP). The NTCIP is a joint standardization project of AASHTO, ITE, and NEMA. OmniAir Consortium, Inc. OmniAir Consortium advances standards-based wireless ground transportation systems through testing and certification programs. 13 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 4.5.2 ITS station reference architecture in ETSI and ISO International developments concerning communications in the area of ITS have centered on the concept of abstracting applications from all of the lower OSI communication layers (Communications Access for Land Mobiles, CALM). The CALM concept has been embodied in an architecture that allows ITS communication devices to communicate on a peer-to-peer basis. One of the important developments was the creation of the concept of an ITS station as a bounded secure managed domain. This has led to the development of a large number of International Standards; see Annex D. ISO 21217 (ETSI EN 302 665 [B5]) describes the ITS station reference architecture, which is derived from the OSI layered model for communications. The ITS station reference architecture and its relationship to the OSI Reference Model and to the IEEE 1609 protocol stack are shown in Figure 4. For example, in the ITS station reference architecture, Road Safety is an application above the OSI Application layer; IPv6 and messaging protocols reside in the Networking & Transport layer; and IEEE 802.x, 3G cellular, and Bluetooth reside in the Access layer. Security Management Security Management An example of a Facilities layer function is the Local Dynamic Map (LDM), which among other things keeps track of nearby objects including vehicles. As a Facilities layer service, the LDM can accept information from, and provide information to, both applications and other protocol entities. Figure 4 ― Relationship among protocol models One important difference between the ISO ITS station communication protocols and IEEE WAVE protocols is that the ISO protocols specified in documents referenced in Annex D use port numbers for data delivery to entities above the Networking & Transport layer. While WAVE communications use standard port numbers for IPv6-based protocols (e.g., TCP, UDP), they use PSID as an identifier in the context of WSMP as described in 5.9.4. The Service Advertisement Message used in the ISO Fast Service Advertisement Protocol (FSAP) specified in ISO 24102-5 is similar to the WSA, but designed to support advertising ITS services offered over multiple media. 14 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture An international harmonization effort in 2012 identified differences among ITS standards produced by ETSI, IEEE, and ISO, and suggested actions to more closely align the standards. These differences and suggested actions have been collected in a series of ITS Task Force reports [B9], [B10], and [B35]. 5. WAVE system overview 5.1 General A WAVE system provides connectivity in support of stationary and mobile (e.g., pedestrian and in-vehicle) applications offering safety and convenience to their users, and provides confidentiality, authentication, integrity, non-repudiation, and privacy features. (See 5.13.1 for definition of these terms.) A WAVE system supports applications that offer vehicle systems and drivers greater situational awareness of events, potential threats, and imminent hazards, toward the end of enhancing the safety, mobility, and convenience of everyday transportation. Example use cases are described in Annex C. WAVE standards (see 4.3) are intended to support a networked environment with low latency transactions among vehicles (V2V), and between vehicles and infrastructure components (V2I) or hand-held devices (V2D), to enable safety and mobility applications. In support of reliable low-latency communications, dedicated spectrum has been allocated for this use (see 5.5) and a unique short message protocol has been developed (see 5.3). 5.2 System components and connectivity IEEE 1609 standards typically do not distinguish among different device types, but are flexible enough to support multiple device types including the RSU and OBU as illustrated in Figure 5. An RSU is stationary while in operation and is usually permanently mounted. An OBU may operate while mobile and is typically mounted or installed in a vehicle. Other envisioned devices include portable units (e.g., smart safety cones) and pedestrian units (e.g., for roadside workers). An application-service is a service involving an exchange of data, generally provided by a higher layer entity (e.g., an application) on one WAVE device to a similar entity on another WAVE device, using WAVE communications. WAVE protocols are designed to allow applications to exchange data in a consistent, interoperable, and timely manner. The WAVE standards specify the device role of Provider that transmits advertisements of available application-services, and the device role of User that has the option to participate in the advertised application-service opportunities. The Provider and User roles are not tied to the RSU and OBU device types, though in many cases an RSU will be the Provider. Communication security services may be accessed by the applications, or from within the data or management plane. Subclause 5.13 describes the communications security services provided by the WAVE protocol stack. 15 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Wireline Stack Wireline Stack Wireline Stack Wireline Stack WAVE Protocols WAVE Stack WAVE Stack WAVE Protocols Wireline Stack Wireline Stack IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure 5 ―Example WAVE system components 5.3 Protocols 5.3.1 General The components of the WAVE protocol stack are illustrated in Figure 6. A data plane is defined for protocols carrying higher layer information; a management plane is defined for security and management functions that indirectly support information transfer. A common set of physical (PHY), medium access control (MAC), and logical link control (LLC) layer protocols are specified. Above LLC, dual protocol stacks are specified. The mapping of these protocol elements to standards is described in 4.3.3. IEEE Std 1609.3 specifies two data plane protocol stacks (sharing a common lower stack at the data link and physical layers)—the standard Internet Protocol Version 6 (IPv6) and the WAVE Short Message Protocol (WSMP) designed for optimized operation in a wireless vehicular environment (see Figure 6). WAVE Short Messages (WSM) may be sent on any channel. IP traffic is only allowed on service channels (SCHs), so as to offload high-volume IP traffic from the control channel (CCH). The protocol stack distinguishes between the two upper stacks by the Ethertype field. Ethertype is a 2-octet field in the LLC header, used to identify the networking protocol to be employed above the LLC protocol. The Ethertype field is specified in IEEE Std 802.3 (as used in the Length/Type field) and its use in WAVE devices is specified in IEEE Std 1609.3 and IETF RFC 1042 (cf., SNAP encoding). In particular, IEEE Std 1609.3 specifies the use of two Ethertype values (i.e., two networking protocols), IPv6 and WSMP. The hexadecimal values indicating IPv6 and WSMP are 0x86DD and 0x88DC, respectively. A WAVE device may support additional Ethertypes, but the WAVE standards do not describe the use of these Ethertypes and their associated protocols. 16 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. Air Interface Management Security IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure 6 —WAVE protocols 5.3.2 WAVE Short Message Protocol WSMP allows applications to directly control physical characteristics, e.g., channel number and transmitter power, used in transmitting the messages. The source application also provides a PSID and the MAC address of the destination device, including the possibility of a group address. WSMs are delivered to the correct receiving entity (e.g., an application or applications) at a destination based on the PSID. If the PSID value in a received message header represents an application-service that is not of local interest, the corresponding message can be ignored. WSMs are designed to consume minimal channel capacity; thus, they are allowed on both CCH and SCHs. An example of a WAVE short message exchange follows. A source application composes WSM data for transmission, and addresses it to the broadcast MAC address. Based on its configuration, the application selects appropriate radio channel information (power level, data rate) to control the transmission, and invokes the resulting WSM request primitive (WSM-WaveShortMessage.request) to request that WSMP delivers the data to the lower layers for subsequent transmission on the current channel of operation. A receiving device accepts the packet and passes it up the communication stack. WSMP delivers it to receiving entities based on PSID. At this point, the receiving application knows the existence and address of the originating device, and can continue the exchange if desired, using either unicast or broadcast MAC addresses as appropriate. WSMP is well-suited to message-based applications, and applications subject to intermittent radio connectivity. Examples of WSMP used in safety and fee collection scenarios are found in Annex C. 17 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.3.3 Internet Protocol The WAVE standards support Internet Protocol (IP) version 6 (v6) [B22]. IPv6 was selected over IPv4 because IPv6 is expected to be a viable protocol into the foreseeable future, whereas the long term future of IPv4 is less certain. (Although not described in the WAVE standards, IPv4 has been tunneled over IPv6 in WAVE trials.) WAVE standards do not specify what transport and higher layer protocols may be used over IPv6. IP is appropriate for applications requiring the features provided by the Internet protocol suite, such as routing packets to a remote Internet host. IPv6 provides a fragmentation and reassembly feature. Two popular transport protocols running over IP are the User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP). UDP [B20] provides port number addressing and a checksum not offered by WSMP. TCP [B21] provides port number addressing and end-to-end reliability through acknowledgements and selective retransmissions. NOTE—TCP has been successfully used in field trials; however, in a WAVE scenario where packet losses/errors may be high or connectivity durations may be short, the suitability of TCP should be considered. IEEE Std 1609.3 specifies a feature of the WAVE Service Advertisement (WSA) to support IP-based application-services. An RSU (for example) can broadcast all the information necessary for an OBU to access an application-service available over IPv6 through the RSU router, in the WAVE Routing Advertisement portion of its WSA. (See 5.8.) 5.3.4 Management plane Management services are associated with the various data plane entities to provide layer-specific functions necessary for system operation. These functions include time synchronization for channel coordination and processing service requests and advertisements. In particular, IEEE Std 1609.4-2010 specifies extensions to the IEEE 802.11 MAC sublayer management entity (MLME) and IEEE Std 1609.3-2010 specifies a WAVE Management Entity (WME). The security services described in 5.13 also reside in the management plane, and may be invoked by the WME or higher layer entities. 5.4 Interfaces See Figure 5 for a device view of a WAVE system; see Figure 7 for a protocol view showing inter-layer interfaces. The air interface, specified in IEEE Std 802.11-2012, allows WAVE devices to communicate with each other over the wireless medium. Interfaces between protocol components are accomplished via service access points (SAPs). SAPs are specified in the appropriate standards and are illustrated in Figure 7, where white shading indicates SAPs specified in IEEE 1609 standards; black shading indicates SAPs specified elsewhere; hatched shading indicates SAPs specified elsewhere but extended by IEEE Std 1609.3-2010. The details of the multiple security SAPs are described in 5.13.3. SAPs describe information exchanged, but do not specify the interface implementation. SAPs are comprised of “primitives,” each of which is a logical message structure, generally containing a set of data elements for accomplishing a particular function. Each SAP is defined and named by the layer or entity providing the services. In the data plane SAPs are only accessible by adjacent entities. In the management plane, layering is less structured, and SAPs may be accessible by other entities, whether or not they are depicted as immediately adjacent. 18 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture From the perspective of IEEE Std 802.11-2012, the WME and the MLME extension (MLMEX) specified in IEEE 1609 standards may be considered aspects of the IEEE 802.11 station management entity (SME). For example, the source of the MLME-TIMING_ADVERTISEMENT.request primitive delivered to the MLME is described as the SME in IEEE Std 802.11-2012 and is described as the MLME Extension in IEEE Std 1609.4-2010. Management Plane Data Plane TSAP WSM SAP UDP / TCP / other WME SAP SEC SAP WSMP IPv6 WAVE Management Entity (WME) LSAP LSAP LLC WAVE Security Services MLMEX SAP MLME Extension MLME SAP MAC Sublayer Management Entity (MLME) PLME SAP MAC SAP PHY Sublayer Management Entity (PLME) WAVE MAC (including channel coordination) PHY SAP Air Interface PHY Figure 7 — Service access points WAVE protocols support interfaces to higher layer entities, e.g., applications, which are considered for the purposes of this discussion to be external to the WAVE protocols themselves. These applications may interface with the WAVE protocol stack via the SAPs mentioned above, or via implementation-specific mechanisms. There are no application program interfaces specified in the WAVE standards. Other interfaces external to the WAVE device may be accommodated by a WAVE system, but are not specified in the WAVE standards. For example, within a vehicle, an interface may provide vehicle-based systems access to communications services provided by the WAVE device over a local communication link. Likewise, an RSU may be connected to a wide area network to allow communications between WAVE devices and systems such as application servers and management entities. 5.5 The 5.9 GHz spectrum allocation Figure 8 shows the radio channels defined for use by DSRC in the U. S. by the FCC in [B6], [B7], and [B8]. It is expected that WAVE systems deployed in the U. S. will use these channels, or a subset thereof. (Other regions may have other channel plans that could be used for WAVE systems.) ⎯ 5.850 GHz to 5.855 GHz is held in reserve. 19 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.925 5.920 GHz 5.915 5.910 GHz 5.905 5.900 GHz 5.895 5.885 5.890 GHz Channels 172 and 184 are designated for public safety applications involving safety of life and property. Specifically, per FCC 06-110 [B8], channel 172 is for “vehicle-to-vehicle safety communications for accident avoidance and mitigation, and safety of life and property applications;” Channel 184 is for “high-power, longer distance communications to be used for public safety applications involving safety of life and property, including road intersection collision mitigation.” 5.880 GHz ⎯ 5.875 Channels 174 and 176 and channels 180 and 182 could be combined to produce two twentymegahertz channels, channels 175 and 181, respectively. 5.870 GHz ⎯ 5.865 Channels 172, 174, 176, 180, 182, and 184 are service channels (SCH). 5.860 GHz ⎯ 5.855 Channel 178 is the control channel (CCH, see 5.6). 5.850 GHz ⎯ Figure 8 — FCC channel allocation The radio channels available for use by a WAVE device are set in its IEEE 1609.4 Management Information Base (MIB). The WAVE protocols distinguish between control and service channels (see 5.6), but do not enforce different rules on different service channels based on the FCC designations. 5.6 Channel types WAVE standards specify two classes of radio channel: a single control channel, and multiple service channels. The CCH is reserved for WSMP messages and for system management messages such as WSAs. SCH use is intended for general-purpose application data transfers, and may be coordinated via a WSA as described in 5.7.3.2. Alternately, SCH usage may be arranged through external means, e.g., regulation or other standards, without advertisements (see 5.7.3.1). The WAVE standards allow IPv6 traffic, as well as WSMP and management traffic, on SCHs. WAVE standards specify use of the CCH for WSA broadcast, and preclude IP traffic on the CCH, but otherwise do not specify how the various channels are used. For example, no separate “safety channel” is specified in the IEEE 1609 standards; any of the control or service channels could be configured for use as a safety channel. Certain channels may be designated for safety use by regulations; see for example 5.5. As currently envisioned, channel 172 will be treated as a dedicated safety channel in U. S. deployments; from the point of view of the WAVE protocols, it is still a SCH. See C.1 for a use case description using this dedicated safety channel. 20 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.7 Communication services 5.7.1 General WAVE communication services support the delivery of information from a higher layer entity (e.g., an application) on one device to a higher layer entity on another device, using WAVE communication protocols over the air interface. Applications may request services from the WAVE protocol or management entities through service primitives via Service Access Points (SAPs). Applications may provide application-services to other applications over the WAVE communications, e.g., in the context of a client-server information exchange of map information between WAVE devices. Higher layer (e.g., application) information may be exchanged on either control or service channels. WSMP traffic may use any channel, whereas IPv6 traffic is only allowed on SCHs. Three communication scenarios are described in the following subclauses, one using the CCH and two using SCHs. SCH application-service opportunities may be advertised or unadvertised. (Note the terms “unadvertised application-service opportunity” and “advertised application-service opportunity” are defined for clarity of discussion in this guide, but are not used in the published WAVE standards.) 5.7.2 CCH communications The first scenario involves CCH communication. No over-the-air coordination is specified for this scenario. Only WSMP and management traffic is allowed on the CCH. The WSMs may be unicast or multicast/broadcast, and may be received by any nearby WAVE device tuned to the CCH at the time of transmission. CCH communication could be used, for example, to solicit timing information from any nearby WAVE device. In this example, the soliciting device would broadcast a request message via WSMP, and a responding device would return timing information via a management frame, either unicast or broadcast. 5.7.3 SCH communications Multiple application-service opportunities, advertised or unadvertised, can use the same SCH in the same area at the same time. Operation on one SCH consumes the resources of one device PHY, i.e., a radio PHY operates on one radio channel at a time. 5.7.3.1 Unadvertised application-service opportunity In the second communication scenario, an unadvertised application-service opportunity, applications may communicate on a predefined SCH. The use of an SCH for a specific purpose may be pre-configured, or determined through some other out-of-band mechanism. Any WAVE devices available for communications (e.g., tuned to the correct channel) are participants in this unadvertised application-service opportunity. The fact that a device is a participant does not imply any particular role (e.g., client, server, sender, receiver) on the part of the application. Safety communications on channel 172 is an example of this type of exchange. In this example, channel 172 is preconfigured as the safety channel in all participating devices. Application protocols define what messages (e.g., Basic Safety Message) are broadcast periodically or on an eventdriven basis. See C.1 for a description of this use case. 21 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.7.3.2 Advertised application-service opportunity In the third communication scenario, WAVE provides the option for advertised application-service opportunities. In this scenario, one WAVE device takes the role of Provider. The Provider transmits WAVE Service Advertisement (WSA) messages identifying and describing the advertised applicationservice and the SCH on which it is accessible, as described in 5.8. The Provider WAVE device is available on the indicated SCH in support of information exchanges associated with the advertised applicationservice and is by definition a participant in the advertised application-service opportunity. Other WAVE devices may take the role of User and are potential participants in the advertised application-service opportunity. Upon receipt of a WSA with an advertised application-service opportunity, Users may choose to join the Provider on the indicated SCH, thus participating in the advertised application-service opportunity. At this point, the Provider and Users may exchange communication traffic associated with the application-service. See 5.7.3.3 for a more extensive discussion of the Provider and User roles. An example of an advertised application-service opportunity is as follows. A fixed roadside Provider device transmits a WSA containing Service Info with a PSID that has been allocated for a traffic advisory application-service. The associated WSA Channel Info indicates SCH 182. The Provider traffic advisory application broadcasts local traffic warnings over WSMP on channel 182, and also responds via IPv6 to requests for more general traffic information. Vehicular User devices entering the coverage area of the RSU receive and evaluate the WSA’s Service Info on the CCH. Those interested in travel advisory recognize the broadcast PSID value and tune to channel 182, where they have access to the advertised traffic advisory application-service. Note that the message exchange used to establish an advertised application-service opportunity consists only of the WSA; any other messages exchanged are the responsibility of the application. The choice of data-plane protocol(s) to support a particular application-service is at the discretion of the participants. The following describes a hierarchy of factors that may be used during operation to determine the appropriate protocol. a) There may be some knowledge of protocol, e.g., based on PSID or Provider Service Context (PSC) (see 5.9.4). b) An IP address in the WSA Service Info indicates an IP service. (The protocol above IP is not indicated.) c) Otherwise, WSMP may be assumed. 5.7.3.3 Device roles in an advertised application-service opportunity In the context of an advertised application-service opportunity, a WAVE device may take on one of two roles, Provider or User. As described in 5.7.3.2 and 5.8, a Provider transmits the WSA containing information about the advertised application-service. The User monitors for the WSA, with the potential to participate in the advertised application-service opportunity. This is illustrated in Figure 9. To start, the support for the application-service has not been requested from the WAVE device. In step 1a, the application at the Provider device sends a Provider Service request primitive to the WME. The request indicates the characteristics of the services, such as the PSID to be advertised, the service priority, the advertisement repetition rate, and the SCH to use. The WME could reject the request, e.g., if its radio resources were consumed in servicing other requests. If not rejected, the WME proceeds to fulfill the request. The service parameters are included in one of a variable number of Service Info segments in the WSA; channel parameters are included in one of a variable number of Channel Info segments. If indicated by the request, the WME will interact with Security Processing Services (not shown) to sign the WSA at step 1b; see 5.13.5. Subsequently, the WME interacts with the MLME at step 1c to coordinate the correct SCH access and the periodic transmission of the WSA on the CCH. The WSA is transmitted 22 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture within an IEEE 802.11 management frame as described in 5.8 and specified in IEEE Std 1609.4-2010. Details of the WSA format are specified in IEEE Std 1609.3-2010. In step 1c, the Provider device also tunes to the SCH, at which time it is a participant in the advertised application-service opportunity. Another WAVE device takes the role of User. An application sends a User service request to the WME in step 2a. Upon successful processing of the request, the WAVE device awaits receipt of a WSA. In step 2b, the User WME receives and processes a WSA. If the WSA is signed, and security validation is required per the User service request, the WME interacts with Security Processing Services (not shown) in step 2c. If the security check is successful (or not needed), the WME checks for an application-service, indicated by the PSID value in the WSA’s Service Info, matching the one in the User service request. If no match is found, or the security check fails, the WSA is ignored and the device continues to monitor the CCH. If the check results in a match, the WME notifies the application in step 2d. At this point, assuming other conditions such as radio resource availability are met, there are several options, described in detail in Annex D of IEEE Std 1609.3-2010. Per the User service request, the WME may automatically begin participation in the advertised application-service opportunity in step 2e, or may await confirmation by the application before participation. Upon the decision to participate, the device begins accessing the correct SCH (e.g., on a continuous or alternating basis). Now both devices are participants, accessing the same SCH, and ready for application data transfer in support of the application-service. Other WAVE devices may also participate in the advertised application-service opportunity as Users. A WAVE device may accept multiple Provider and User service requests, thus simultaneously taking the roles of Provider and User on multiple application-service opportunities. Figure 9 — Device roles in an advertised application-service opportunity 23 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.7.3.4 Ending participation in an application-service opportunity Once a device is a participant in an application-service opportunity, it remains so until participation is locally terminated. WAVE standards specify no over-the-air message exchange to confirm this termination. Within a device, the WME communicates the termination decision to the MLME so that it can take action, e.g., stop channel access, stop advertising the application-service availability in the WSA. The WME also notifies the affected applications. The WME terminates participation for any of several reasons. For example, completion of the application activity could cause the application to request termination, or the WME might need to reallocate local communication resources in the service of higher-priority requests. 5.7.3.5 IPv6 services A WAVE system may support general IPv6-based applications as illustrated by the following example. An RSU has a connection to the Internet. It is configured as a Provider to transmit a WSA advertising (via a PSID value in the Service Info) a general Internet access service. The WSA optionally includes a WAVE Routing Advertisement (WRA), as well as Service Info and Channel Info. The WRA contains the information needed by an OBU to access the Internet, and removes the need for an ICMPv6 Router Advertisement message. Wireline Stack Wireline Stack WAVE Stack WAVE Stack WAVE WAVE Protocols Protocols IPv6 protocols Based on the information received in the WRA, the OBU configures its IPv6 stack and is capable of accessing the Internet, using the RSU facilities as its gateway router as illustrated in Figure 10. Figure 10 — Internet access example If the IPv6 application is hosted at the RSU, there is no need for Internet connectivity or the WRA. The local Service Info and Channel Info are included in the RSU’s transmitted WSA. WAVE devices, e.g., OBUs, may also participate in an IPv6 local network without an RSU. In this scenario, an OBU could transmit the pertinent Service Info and Channel Info in a WSA. IPv6 has provisions for neighbor discovery in which a Neighbor Cache is populated with IP addresses and associated MAC addresses of devices within communications range. This is accomplished via a multicastresponse mechanism, as specified in RFC 2461, and generates a substantial amount of traffic on the 24 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture channel. In some WAVE systems, it may be desirable to keep traffic on the channel to a minimum, suggesting that the Neighbor Cache be populated via alternate methods such as passive monitoring of overthe-air transmissions. Note that neighbor discovery per IETF RFC 2461 is not precluded by the IEEE 1609 standards. In a WAVE system, the population of the Neighbor Cache may be accomplished based on the information in received packets that contain both MAC and IP addresses. Upon accessing a service channel, a host participating in non-routed communications (e.g., one where packets to the server do not transit a router) adds an entry to its Neighbor Cache for the server, if possible. If the communications are routed, the client host adds an entry to its Neighbor Cache for the gateway router, if possible. In addition, a WAVE device learns Neighbor Cache associations from ICMPv6 and IPv6 PDUs received from a link-local IPv6 address by associating the source IP address with the Source (MAC) Address from the MAC header. 5.8 WAVE Service Advertisement 5.8.1 General operation Advertised application-service opportunities (see 5.7.3.2) are announced on the air interface via a WSA inside an IEEE 802.11 management frame. The WSA is composed as shown in Figure 11 and described in the following text. 25 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Higher layer Service request A WMEProviderService.req WME WSA Header B Service Info Channel Info WAVE Routing Advert. SEC-SignWSA.req Security Services Security Header C WaveService Advertisement Security Trailer SEC-SignWSA.cfm WME Unsecured WSA or Secured WSA D MLMEX-WSA.req MLME extension OUI Content descr. MLMEVSPECIFIC.req WSA MLME Cate gory OUI Vendor Specific Content MAC MAC Header Vendor Specific Action frame MAC Trailer PHY PHY Header Air interface Figure 11 — Building the WSA The process of creating a WSA and transmitting it is initiated when an application requests an advertised application-service opportunity. On acceptance of the request from the higher layer entity, the Provider WME builds a request to the MAC sublayer management entity (MLME) extension specified in IEEE Std 1609.4-2010, to start advertising the application-service. The information flow between layers is illustrated in Figure 11 and described in this subclause. Additional details are found in IEEE Std 1609.3-2010, IEEE Std 1609.4-2010, and IEEE Std 802.11-2012. A description of the Provider and User roles is found in 5.7.3.3. Prior to operation (e.g., at network configuration), system parameters are loaded into the Provider MIB, including operational channels and their characteristics, and (if applicable) a WAVE Routing Advertisement (WRA) containing IP network configuration info. Applications may request services through the WME (step A in the figure); the WME enters the parameters into the WME MIB. 26 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture The Provider WME generates a WSA, which will be transmitted to potential application-service Users. The Provider WME collects the application information describing the application-services being offered, previously registered in its MIB, and channel characteristics, also from the MIB, and inserts them into the WSA as Service Info. In addition, if the application-service is IP-oriented the IP network configuration information (WRA) from the MIB is included. If any of the applications have requested it, the WSA is signed, indicating its authenticity, with security header and trailer added, per IEEE Std 1609.2-2013 as described in 5.13.5. The result is a Secured WSA (steps B and C in the figure). The WSA is provided to Provider MLME (step D in the figure). Following this, over-the-air headers are added by the lower layers and the frame is ready for transmission as a Vendor Specific Action management frame specified in IEEE Std 802.11-2012. It has been suggested that under certain conditions, a Provider might desire to concurrently transmit more than one WSA. For example, as an alternative to including two different application-services in one WSA, one application-service might be advertised in a WSA transmitted at a higher repetition rate with security invoked, with a second application-service advertised in a WSA transmitted at a lower rate with no security. The mechanisms for sending and receiving such multiple WSAs are neither described nor precluded in IEEE Std 1609.3-2010. 5.8.2 WSA extensibility Each section of the WSA (header, Service Info, Channel Info, WRA) optionally may be extended by including predefined extension fields specified in IEEE Std 1609.3-2010. An example is the option to include the transmitter’s location in the WSA header. Each extension field is preceded by an identifier (WAVE Element ID) and length indicator. This allows additional extensions to be added in the future, while maintaining compatibility between versions. 5.8.3 Other uses of the WSA The WSA is not limited to carrying application-service information. Other information could include an identification of the regulatory domain of operation and non-service-related channel parameters. There is a WSA header extension field Country String that indicates the regulatory domain (e.g., country) in which the system is operating. Since different channel characteristics may be associated with different countries, as specified in IEEE Std 802.11-2012, this field could be used by the receiving device to configure itself for operation in the correct domain. How this field would be processed has not been specified. The WSA associates channel information with each advertised application-service in the Channel Info. Channel Info may include such parameters as DataRate and Transmit Power Level, and may include EDCA parameters, in case non-default parameters are used on a particular service channel. (EDCA is the priority-based channel access mechanism specified in IEEE Std 802.11-2012 and mandated by IEEE Std 1609.4-2010.) A separate instance of Channel Info could be included in the WSA and used to convey parameters for the CCH. 5.8.4 Repeat rate considerations IEEE Std 1609.3-2010 describes how each Provider service request includes a Repeat Rate requesting the associated WSA to be transmitted at that rate. Rates that may be requested range from about 5 transmissions per 100 ms to 1 per 5 seconds. An implementation of the WME may be guided by the requested repeat rates when selecting the transmission rate, but is not bound by them. 27 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Consider a WSA built in response to two Provider service requests with different latency requirements, and therefore difference requested repeat rates. The WME could choose to transmit the WSA at the higher rate, since this would satisfy both requests. Though not described in the WAVE standards, a WME implementation might find it desirable to adapt the WSA transmission rate to the current conditions. An example of a situation that would encourage this adaptability is when the CCH becomes congested. In this case, the rate of WSAs could be reduced to allow more of other traffic. The transmission of the Timing Advertisement described in 5.11 could likewise be adapted. 5.8.5 Advertisement termination Once a device is a participant in an advertised application-service opportunity, as either Provider or User, it remains so until participation is locally terminated. WAVE standards specify no over-the-air message exchange to confirm this termination. Within a device, the WME communicates the termination decision to MLME so that it can take action, e.g., stop channel access, and also to the affected applications through a notification. The WME terminates participation for any of several reasons. For example, completion of the application activity could cause the application to request termination, or the WME might need to reallocate local communication resources in the service of higher-priority requests. 5.8.6 Adding and subtracting applications from an advertisement A Provider MLME extension typically generates regular WSA transmissions for the duration of an advertised application-service opportunity. Different application-services may be advertised over time on the same SCH, i.e., the contents of the Service Info may change in subsequent WSAs. To support this feature, the WSA destination MAC address is defaulted to be the broadcast address. If the destination is a unicast address, the advertisement is not repeated by the IEEE 1609 protocols, since lower-layer reliable delivery is invoked. The WSA header features a two-bit Change Count field that is incremented (modulo-4) when the contents of the WSA change. The User can use the value in this field, compared to the value in the previous WSA, to quickly determine if the WSA has changed. The User WME will update the information in the MLME MIB when the received WSA information changes (including when updated security credentials are generated), indicating a change in applicationservice parameters. The WME ends participation in the advertised application-service opportunity under the conditions described in 5.7.3.4. 5.9 Addresses and identifiers 5.9.1 MAC address Each device operating in an IEEE 802® network, such as IEEE 802.11-2012, is assigned a MAC (layer 2) address that is used in transferring packets across a data link. Distinct physical interfaces on a device have distinct MAC addresses, e.g., a device with both WAVE and Ethernet physical interfaces will have a MAC address for each. The MAC address is 48 bits. Per IEEE Std 802.11-2012, the source and destination MAC addresses are included in the MAC header of each transmitted frame. Besides unicast addresses, a broadcast MAC destination address is supported. Use of multicast MAC addressing is permitted, but not required by IEEE 1609 standards. 28 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture IEEE 1609 standards provide primitives to change local WAVE MAC addresses to protect the privacy of the device operator. The process by which a decision is made to change the WAVE MAC address is not addressed in the IEEE 1609 standards. See 5.13.8 for further discussion. 5.9.2 IPv6 address Each device operating as an IP host or router has one or more IP (layer 3) addresses. IPv6 distinguishes between the global address type and the link-local address type. A given device can have both. Global addresses are assumed globally unique and share a prefix with the network to which they are attached, and thus may be used to route packets across multiple interconnected networks. A link-local address is derived by the device and is not assumed to be globally unique, and thus can only identify a host to other hosts on the same network (i.e., is not routable). IPv6 also supports special multicast addresses. The IP address of the service provider device may be included in the WSA if an application-service uses IP-based communications. 5.9.3 Protocol/port IEEE Std 1609.3-2010 supports the standard use of port numbers within protocols such as TCP and UDP. When an IP packet is received with UDP or TCP as the transport layer protocol, the UDP or TCP destination port number is used to deliver the packet payload to the appropriate higher layer entity. The port number of the service provider application may be included in the WSA if the application-service uses IP-based communications. 5.9.4 PSID and PSC Unlike other identifiers described in 5.8, the PSID and PSC are defined in WAVE standards. From the point of view of networking services, a PSID identifies an application service that may pertain to one or more applications. A PSID value is allocated to an organization that is expected to specify how the PSID is used, e.g., whether the PSID is used in a WSMP or WSA context and what message set is to be employed for communications associated with that PSID. Allocated PSID values are listed in IEEE Std 1609.12. The PSID may be from one to four octets in length, with the leading bits indicating the length as specified in IEEE Std 1609.32010, and further described in Annex E. The PSID is allocated from the same numbering space as the ITS Application Identifier (ITS-AID)8 used in other ITS standards. An eventual common registration service for the PSID and ITS-AID is foreseen. In the context of WSMP, the PSID is used by the receiving device to deliver received WSMs to the appropriate higher layer entity or entities. In the context of service advertisements, the PSID, and optionally the PSC, of service provider applications are included in the WSAs. PSID values received in a WSA at a User are compared by the WME to those PSIDs previously received from local applications in User service requests, to determine whether one or more of the represented application-services are of interest. 8 ITS-AID allocations are currently available at http://aid.its-standards.info/ITS-AID%20Registry/ITSaidRegistrationIndex.html. 29 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture For both signed data (e.g., in WSMs) and signed WSAs, the PSID value is included in the accompanying security certificate (see 5.13) to indicate that the sending entity has authorization to carry out activities associated with that PSID value. The PSC, if present in the WSA, contains supplementary information, e.g., version number, specific to the advertised application-service. It may be used by the User application to determine if the applicationservice is of interest. The PSC is up to 31 octets in length and could contain text or encoded information. The PSC format is specific to the associated PSID value and is expected to be defined by the organization to which the PSID value is allocated, so interpretation of the PSC by the receiving higher layer entity is based on the associated PSID. For example, the PSC field associated with one PSID might be used to carry an 8-bit version number identifying the latest data available. 5.10 Priorities There are two types of priorities discussed in WAVE standards. An IEEE 1609.3 “service priority” level may be associated with an application-service request; this may be used by the WME to help decide which applications have first access to the communication services, e.g., which application-services to advertise in case of conflict at the Provider, or which advertised applicationservice to participate in the case of conflict at the User. The Provider-assigned service priority is included in the Service Info of the WSA, where it may be used by the User in deciding whether to participate in the advertised application-service opportunity. (An example of a conflict at the Provider would be where multiple applications request that their application-service access opportunities be offered on more channels than can be accommodated by the WAVE device.) The IEEE 802.11 lower layers use a separate MAC transmission “user priority” for packet transmission on the wireless medium. An IP packet is assigned the user priority associated with the traffic class of the generating application. A WSMP packet is assigned its user priority by the generating application on a packet-by-packet basis. User priority is used by the EDCA mechanism specified in IEEE Std 802.11-2012. 5.11 Channel coordination and time synchronization When using WAVE communications, time and frequency resources are segmented to provide a range of communications options. CCH and SCH usage is described in 5.6. WAVE devices may have the ability to access one or more channels on an alternating basis. An example usage scenario is a single-radio device that is required to exchange information on an SCH while still monitoring the CCH. To this end, channel intervals are specified, as illustrated in Figure 12. Other options for channel coordination are described later in this subclause. Alternating radio channel access is coordinated based on intervals that are synchronized relative to a common time base. A sync interval is composed of a CCH interval followed by a SCH interval. During the CCH interval, traffic is exchanged on the CCH. Single-radio devices participating in an application-service opportunity may switch to the designated SCH during the SCH interval. A guard interval begins each CCH interval and SCH interval; during a guard interval a device that is switching channels is assumed to be unable to receive packets. IEEE Std 1609.4-2010 specifies channel intervals of 50 ms and a guard interval of 4 ms. 30 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure 12 ― Channel intervals The standards accommodate the possibility of making the intervals of variable length, but do not specify a mechanism for accomplishing this. Channel coordination is specified in IEEE Std 1609.4-2010. A single-radio device using alternating channel access synchronizes to a standard time base. Channel timing is defined such that a sync interval begins at the start of a second in Coordinated Universal Time (UTC). UTC or an equivalent is commonly provided by GPS. Once synchronized, devices can tune to the intended channel during the correct interval. The Timing Advertisement frame specified in IEEE Std 802.11-2012 may also be used to convey an estimate of absolute time from one device to another for the purpose of synchronization. Note that synchronization is not required to make data exchanges except during alternating channel access. For the purpose of channel coordination, only the one-second boundary is needed, but absolute timing may be required for security purposes (see 5.13.6.3 and IEEE Std 1609.2-2013). In addition to continuous (CCH or SCH) and alternating (CCH and SCH) channel access, WAVE standards allow immediate and extended access as illustrated in Figure 13. Immediate access allows a User device to switch to the SCH immediately on recognizing a desirable application-service in a WSA. Extended access allows a User device, normally in alternating mode, to access the SCH for an extended period. Immediate and extended access may be combined, and are provided to support a User device that needs to perform a transaction during the limited time during which it is in range of a roadside service provider. The device providing the service would be expected to have a radio in SCH continuous access to support the extended transaction, as described in the use case in C.2. The Provider may indicate in the WSA Channel Info whether it supports continuous or alternating access on the SCH, or this information could be known a priori by the User. 31 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture CCH Interval SCH Interval CCH Interval SCH Interval Time (a) CCH or SCH (b) CCH SCH (c) CCH SCH (d) CCH SCH Figure 13 — Channel access options; (a) continuous, (b) alternating, (c) immediate, and (d) extended 5.12 Other features 5.12.1 Delivery of management messages WAVE standards provide for the delivery of general management information between WAVE devices using the Vendor Specific Action management frame type (also used to deliver WSAs) specified in IEEE Std 802.11-2012. The information flow supporting this service is illustrated in Figure 14 and Figure 15 and described immediately below. Numbers in the text refer to those in the figures. 1) Except for the case where the management information is a WAVE Service Advertisement (see 5.8), a management entity – either IEEE 1609 or other – generates a request to the WME for delivery of management information via the WME-ManagementDataService.request. 2) If appropriate, WME provides a supporting channel access assignment. WME generates an MLMEX-VSA.request. 3) The MLME extension generates an MLME-VSPECIFIC.request… 4) … which results in queuing of the Action frame, and eventual transmission. 5) On receipt, the frame is processed by the MAC. 6) Vendor Specific Action frames with Organization Identifier values that do not indicate WAVE data are passed to the appropriate entity directly. 7) Vendor Specific Action frames with Organization Identifier values that indicate WAVE data are passed to the IEEE 1609 MLME extension. 32 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 8) The information is then passed to the WME, which proceeds based on the Management ID value. One Management ID value indicates IEEE 1609.3, which indicates the presence of a WSA, and is processed by the WME. MLME SAP 9) Other Management ID values may be allocated for use by other IEEE 1609 entities. (Allocated Management ID values documented in IEEE Std 1609.12.) On receipt of information associated with one of these Management ID values, the WME delivers the information to the appropriate management entity. Figure 14 — SAPs used for delivering general management information Figure 15 —Information flow for management data distribution 33 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.12.2 Channel-specific IEEE 802.11 primitives IEEE Std 802.11-2012 assumes single-channel operation. The WAVE standards add multi-channel operation. There may be IEEE 802.11 features, accessible via primitives specified in that standard, that are of interest to WAVE devices. These primitives may be ambiguous in a WAVE device because they do not account for the possibility that the device may be operating on multiple channels. IEEE 1609.4 MLMEXSendPrimitive primitives extend the IEEE 802.11 primitives for multi-channel operation. A management entity may invoke IEEE 802.11 via the MLME SAP. For channel-specific primitives, the management entity would instead send the MLMEX-SendPrimitive request, containing an IEEE 802.11 MLME primitive plus a channel identifier. For primitives that entail transmissions, the management entity may also indicate in which channel interval the transmission is to occur. This feature is illustrated in Figure 16, where the dashed arrows represent IEEE 802.11 functionality and the solid arrow represents IEEE 1609 functionality. No IEEE 802.11 primitives are currently identified as candidates for this IEEE 1609 feature. Management Plane Data Plane MLMEX SAP IEEE Std 1609.4 MLME Extension MLME SAP WAVE MAC (including channel coordination) IEEE Std 802.11 MAC Sublayer Management Entity PLME SAP IEEE Std 802.11 PHY Sublayer Management Entity PHY SAP PHY Figure 16 — Channel-specific primitives 5.13 Security considerations 5.13.1 Background A communication system may provide the following generic security services to its users: ⎯ Confidentiality: Only legitimate entities can observe the contents of a communication. ⎯ Authenticity: The recipient of a communication can determine that it originated from a valid sender. ⎯ Integrity: The recipient of a communication can determine that it was not modified after generation. 34 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ Non-Repudiation: The recipient of a communication can demonstrate to a third party that it originated from a valid sender. ⎯ Replay Protection: A received communication is unique and not a copy of a previously received communication. ⎯ Relevance Checking: A received communication is relevant to the receiver. ⎯ Privacy: The sender of a communication reveals only the information that they choose to reveal. The main focus of this clause is on how the WAVE system can be used to provide communications security services from the previous list that are appropriate to the needs of the sender and receiver. A discussion of security services other than communications security services is provided in 5.13.9. 5.13.2 Communications security within WAVE standards 5.13.2.1 Data plane This subclause describes options for security within the WAVE data plane. Higher layer entities: IEEE Std 1609.2-2013 specifies security mechanisms that may be used by applications or other higher layer entities communicating via the data plane. These mechanisms may be used to provide confidentiality, authenticity, integrity, non-repudiation, replay protection, and relevance checking. The mechanisms of IEEE Std 1609.2-2013 do not provide privacy on their own; a discussion of privacy is given in 5.13.8. Higher layer entities may use the mechanisms of IEEE Std 1609.2-2013, or they may use different mechanisms. For example, Electronic Payment Systems as specified in IEEE Std 1609.11-2010 use their own security mechanisms rather than those of IEEE Std 1609.2-2013. Since the security mechanisms to be used are application-specific, a full specification of a higher layer entity should also specify the security mechanisms to be used. Protocol stack: The only security protocol supported within the IEEE 1609 data plane below the application layer is Internet Protocol Security (IPSec), which is supported within the IP protocol stack. IPSec may be used to provide confidentiality, authenticity, and integrity between two implementations of the Internet Protocol. No other mechanisms are specified within the data plane to provide confidentiality, authenticity, integrity, or non-repudiation. IEEE Std 1609.4-2010 provides primitives that may be used to change the MAC address of a WAVE device. This may be used as part of an overall approach to provide privacy as discussed in 5.13.8. 5.13.2.2 Management plane A WAVE device that sends secured WSAs is required by IEEE Std 1609.3-2010 to use mechanisms defined in IEEE Std 1609.2-2013. No other security mechanisms are defined for use in the management plane. 35 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.13.3 IEEE Std 1609.2 and WAVE Security Services WAVE Security Services are defined in IEEE Std 1609.2-2013. Figure 17 shows the services and entities within WAVE Security Services as well as the SAPs that provide interfaces between WAVE Security Services entities and other entities. WAVE Security Services Management Plane Data Plane Security Management Services CMESAP WAVE Management Entity (WME) Lower Layer Management WMESec-SAP Security Processing Services Provider Service Security Management Entity (PSSME) CMESec-SAP Certificate Management Entity (CME) Sec-SAP PSSMESec-SAP PSSMESAP UDP / TCP WSMP IPv6 LLC WAVE MAC (including channel coordination) PHY Figure 17 — WAVE protocol stack showing detail of WAVE Security Services The Security Processing Services provide communications security services to outgoing and incoming application and management PDUs. The Security Management Services manage state and configuration information used by the Security Processing Services. The Security Management Services consist of the following: ⎯ The Certificate Management Entity (CME) manages revocation and root certificate information necessary to determine the validity of IEEE 1609.2 certificates. ⎯ The Provider Service Security Management Entity (PSSME) stores information necessary to obtain certificates to be used when signing WSAs. Use of Security Processing Services: Applications and other higher layer entities interact with the Security Processing Services via the Sec-SAP as described in 5.13.4. Signed WSAs are generated and validated via the WME-Sec-SAP as described in 5.13.5. In both these cases, when sending, the sender first invokes the security services with a PDU and the security services return to the sender a secured PDU which is then transmitted. Similarly, when a receiver receives data or WSAs that have been protected with IEEE 1609.2 mechanisms, the receiver receives over the air interface the data, which is a secured PDU, submits it to the Security Processing Services for processing, and is returned the original, unsecured PDU from the peer sender. This is illustrated in Figure 18. 36 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure 18 — Process flow for use of IEEE 1609.2 Security Processing Services Communications that are protected by WAVE Security Services are authenticated by use of digital certificates and their associated private keys as discussed in 5.13.6. The Security Processing Services provide an interface to key and certificate storage via the cryptomaterial handle (CMH). Certificates for send-side operations are obtained via the certificate management processes described in 5.13.7. Certificate Management Entity: The CME stores information about certificate validity for use by the receive-side processing of the Security Processing Services: root certificate information, revocation information, and other information about the trust status of individual certificates. Revocation information is described in 5.13.6.4 and the process of obtaining revocation information is described in 5.13.7.5. Provider service security management entity: The PSSME manages certificates that are used to sign WSAs, as described in 5.13.7.4. 5.13.4 Security processing for applications An application running on a WAVE device may use the Security Processing Services to provide authentication, integrity, authorization, replay protection, relevance checking, and/or confidentiality to the data that it exchanges. These are provided using primitives offered via the Sec-SAP illustrated in Figure 17. An application may request the Security Processing Services to apply authentication, integrity, authorization, replay protection, and relevance checking to outgoing data by signing the data via the signed data signing primitives. An application may obtain assurance that incoming data has the required security properties by requesting the Security Processing Services to verify the data via the signed data verification primitives. Within the signed data primitives, the act of signing provides authentication and integrity; the sender demonstrates authorization by attaching a digital certificate that authorizes the communication as described in 5.13.6; and replay protection and relevance checking may be obtained by the use of optional parameters in the primitive. When signing data for sending, the Security Processing Services use a cryptographic private key and a corresponding digital certificate that authorizes the data. (The “corresponding digital certificate” to a private key that signs data is defined as the certificate that the recipient of the signed data may use to verify its signature.) When verifying signed data on receipt, the Security Processing Services use the signed data itself and the following locally stored information: 37 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ Known CA certificates, which are used to construct a certificate chain from the signer’s certificate to a known trust anchor. ⎯ Revocation information about the signer’s certificate, which is used to determine whether the certificate has been noted as untrusted. This information is managed by the Certificate Management Entity (CME), and is made available to all other entities on the WAVE device. See 5.13.6 or further description of root certificates, certificate chains, and revocation. The signed data structure includes a number of optional elements. For interoperability, the sending and receiving entities use consistent options when signing and verifying. IEEE Std 1609.2-2013 provides the security profile, which is a form to be filled in a priori specifying how different security options are to be used, as a compact and standards-based way to specify those options. The IEEE 1609.2 security profile is intended to be completed by the organization that specifies an over-the-air application-service, as part of the specification of that application-service. An application may request the Security Processing Services to apply confidentiality to outgoing data by use of the encrypted data primitives. An application may request the Security Processing Services to provide access to confidential data that is encrypted for that application by use of the encrypted data decryption primitives. To encrypt data, the Security Processing Services use an encryption public key contained in the intended recipient’s certificate. In IEEE Std 1609.2-2013, responsibility for managing these certificates lies with the application, which provides the appropriate certificate to the Security Processing Services via the encryption primitives. To decrypt encrypted data when so requested by an application, the Security Processing Services use the application’s certificate and private key. These are managed via the CMH as described in 5.13.3. IEEE Std 1609.2-2013 permits the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) for signing and the Elliptic Curve Integrated Encryption Scheme (ECIES) for encryption. ECDSA is specified in IEEE Std 1363 [B13], and ECIES is specified in IEEE Std 1363a [B14]. 5.13.5 Security use cases for WSAs See 5.8 for a description of WAVE Service Advertisements. See Figure 17 for the services and entities within WAVE Security Services and the SAPs that provide interfaces between WAVE Security Services entities and other entities. The WME on a WAVE device may request the Security Processing Services to sign a WSA. This provides authentication, integrity, authorization, replay protection, and relevance checking to the WSA. WSA signing is provided using primitives offered via the WME-Sec-SAP illustrated in Figure 17. The receiving WME verifies the WSA also using primitives offered via the WME-Sec-SAP. The WME will request the Security Processing Services to sign a WSA if so requested in a Provider service request. See 5.13.6 for a description of how and why Provider applications might request inclusion in a signed WSA. To sign a WSA for transmission, the Security Processing Services uses a cryptographic private key and the corresponding digital certificate that authorize the WSA. The WME communicates the required authorizations to the Security Processing Services via the WME-Sec-SAP. The certificates that may be used to sign WSAs are managed by the PSSME. When signing a WSA, the Security Processing Services query the PSSME via the PSSME-Sec-SAP to determine whether a certificate is available that authorizes 38 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture the requested signing operation, and, if so, to obtain the CMH that references the certificate and the corresponding private key. See 5.13.7.4 for further description of the operations of the PSSME. The WME will request the Security Processing Services to verify a WSA if so requested by a User service request. When verifying signed data on receipt, the Security Processing Services use the signed data itself and the following locally stored information: ⎯ Known CA certificates, which are used to construct a certificate chain from the signer’s certificate to a known trust anchor. ⎯ Revocation information about the signer’s certificate, which is used to determine whether the certificate has been noted as untrusted. This information is managed by the Certificate Management Entity (CME), and is made available to all other entities on the WAVE device via the CME-SAP. See 5.13.6.1 for further description of root certificates, certificate chains, and revocation. The receiving WME enters information derived from the signed WSA, including whether or not it was signed and whether or not verification succeeded, into all the UserAvailableServiceTable entries that are updated as a result of that WSA. This security information is then available to User applications to help them determine whether to make use of an application-service advertised in the WSA. The specification of a Provider application and the corresponding User application should include an indication of whether or not the Provider requests, and the User expects, a signed WSA. Signing a WSA provides authentication that the sending WME is authorized to advertise the signed application-services. It does not provide a secure (encrypted, authenticated) connection between the User and the Provider. This is the responsibility of the higher layer entities themselves. The two following cases describe situations where use of an unsigned advertisement could pose a privacy risk. In such cases, a Provider application should request that its WSAs are signed, and the corresponding User application should only respond to advertisements in signed WSAs. ⎯ The application may cause a risk to the privacy of responders, i.e., if an application-service is sufficiently rarely used then the fact that a given User participates in the application-service opportunity can be used to distinguish or track the User.9 ⎯ An unauthenticated application could cause a force-multiplied denial of service attack, i.e., that the application-service is sufficiently widely used that, if it is advertised in an area of dense network traffic, so many WAVE devices will respond as to cause significant channel congestion. WSAs are not encrypted. 9 Consider a vehicular or personal WAVE device that hosts a rare user service, meaning a service that has only a relatively small number of users out of the entire population of WAVE devices. (For example, there might be a special service offering added-value information to Rotary Club members.) If this service was offered in almost every location, then since only a few WAVE devices will respond to the service, an eavesdropper will with high probability be able to track those devices that respond to it. If the eavesdropper can broadcast bogus WSAs advertising that service, the eavesdropper can in principle track the users of that service anywhere. There are several mitigations for this; the one in scope for the IEEE 1609 standards is to allow User services to require that WSAs are signed before responding. Other possible responses include the following. First, since a large number of WSA-sending locations would be needed for tracking, the attacker would be easy to detect. Second, WAVE devices could be programmed to emit bogus responses to services from time to time, to confuse any attack based on traffic analysis. 39 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 5.13.6 Use of certificates for authentication 5.13.6.1 General In the IEEE 1609.2 model, a sending entity demonstrates authorization to send a communication (either data or a WSA) by signing the communication and attaching a digital certificate. A digital certificate is a document that contains a statement of the sending entity’s permissions, bound to a public key for a public-key cryptographic algorithm, and authorized by a Certificate Authority (CA) which is trusted only to issue certificates to entities that are entitled to them. The CA certificate may in turn be issued by another CA, and so on, forming a certificate chain in which each certificate issues the following one in the chain until the chain terminates at a root certificate, issued by a root CA, which is self-signed (i.e., can be verified with the public key from the certificate itself, rather than the public key from a different certificate). The entity that uses a certificate to authenticate an outgoing communication is referred to as an “end-entity”. Figure 19 illustrates a certificate chain, showing the fields that are used to indicate the issuer of each certificate and to verify each certificate. In order to trust a signed communication, the receiver must already know and trust at least one of the certificates in the chain. The use of CAs simplifies the process of trusting incoming messages because once a CA is trusted, all certificates that chain back to that CA can be trusted by assumption (unless specific information to the contrary is received). A root certificate cannot be trusted because its issuer is trusted, as it has no issuer. It must instead be trusted by out-of-band means, i.e., because the recipient is configured to trust it by some means authenticated outside the certificate hierarchy. A certificate trusted by out-of-band means is known as a trust anchor. Root certificates are automatically trust anchors, and other certificates may be used as trust anchors to simplify processing (since the receiver can terminate certificate chain construction when they reach any trust anchor) Within WAVE Security Services, the Certificate Management Entity provides primitives to instruct the Security Processing Services to trust certificates, i.e., to install them as trust anchors. 40 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ↓ trust anchor Root CA Certificate signer_id public key Issuer’s signature issuer ↑ ↓ subordinate identifies verifies CA Certificate signer_id CA Certificate signer_id CA Certificate public key signer_id Issuer’s public keysignature public keysignature Issuer’s Issuer’s signature identifies issuer ↑ ↓ subordinate verifies CA Certificate signer_id public key Issuer’s signature identifies issuer ↑ ↓ subordinate verifies End-Entity Certificate signer_id public key Issuer’s signature ve r signer s ifie nt ide ifie s Signed Data Issuer’s signature Figure 19 — A certificate chain To trust an incoming communication, the receiver of the communication may verify that the signature is consistent with the public key obtained from the certificate, that the data is permitted by the permissions contained in the certificate, that for each certificate in the chain the certificate was issued by a known CA and is consistent with that CA’s permissions, and that the chain terminates at a known trust anchor. 5.13.6.2 Implicit and explicit certificates IEEE Std 1609.2-2013 permits two types of certificates, known as implicit and explicit. If the public key is explicitly included in the certificate, it is an explicit certificate. This is the type illustrated in Figure 19. If the public key is not explicitly given in the certificate, but is obtained by performing additional processing, the certificate is an implicit certificate. The difference between implicit and explicit certificates is illustrated in Figure 20. Verifying a signed communication requires knowledge of all certificates in a chain, regardless of whether the certificates are implicit or explicit. Implicit certificates are smaller than explicit certificates and allow faster processing the first time a chain is constructed and verified, so they are optimal for frequent messages on a congested channel or settings where a receiver will typically verify messages from many different senders. 41 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Implicit certificates are specified in Standard #4 of the Standards for Efficient Cryptography Group [B34]. Figure 20 — Implicit and explicit certificates 5.13.6.3 Permission encoding IEEE Std 1609.2-2013 encodes the permissions of senders directly in digital certificates. This allows the receiver of a communication to determine the authorization of the sender to send that communication. Permissions may include the following: ⎯ Temporal validity of the certificate: start time and end time. These are compared to the generation time and expiry time of the associated signed communication. If generation and expiry time of the communication are present, both lie between the generation and expiry times of the certificate. ⎯ Geographic validity of the certificate: from where its holder is entitled to send. This is compared to the generation location of the associated signed communication. If generation location of the communication is present, it lies within the geographic validity region of the certificate. ⎯ Operational permissions of the certificate: what actions its holder, i.e., the sender, is entitled to take. The operational permissions of a certificate used for signed data or signed WSAs are represented by a PSID value, and may be further qualified by Service Specific Permissions (SSP). For signed WSAs, maximum priority is also included. The PSID is defined in IEEE Std 1609.3-2010 and described in 5.9.4. The SSP is an octet string of length no more than 31 octets. The SSP is application-specific: on receipt of signed data, the application (not the Security Processing Services) verifies that the SSP is consistent with the application payload in the signed data, and on receipt of a signed WSA the User application is responsible for determining what use to make of the SSP in the appropriate field of the WSA certificate. The organization that is allocated a PSID value is authorized to define the syntax and semantics of the SSP associated with that PSID. The maximum priority for an application-service in a WSA certificate is the maximum priority at which that application-service may be offered. At the time of writing there are not yet any examples of organizations that have defined SSP semantics. The following are hypothetical examples of how an SSP might be defined and used: SSP in application: The SAE J2735 Basic Safety Message contains a LightbarInUse field. PSID value 0x20 has been allocated to SAE for applications employing the Basic Safety Message (see C.1 for a use case description). Since not all vehicles are equipped with a light bar are permitted to use one, it may be desirable to require that vehicles that set this field demonstrate that they are authorized to set it. This requires the following steps: 42 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ Standardization/Specification: SAE (or some other body directly or indirectly designated by SAE) defines the syntax of the SSP so that it can encode the statements “entitled to set LightbarInUse” and “not entitled to set LightbarInUse”. ⎯ Authorization: WAVE devices that emit the BSM in a WAVE Short Message with PSID 0x20 obtain certificates that contain the appropriate PSID and SSP, as described in 5.13.7. CAs use this syntax to state the permissions of certificate holders ⎯ Operation: BSM-consuming applications on receiving WAVE devices check that, if the PSID 0x20 WSM with BSM data has set the LightbarInUse field, the SSP explicitly permits the inclusion of this field. Any message that has set the LightbarInUse field in the payload but does not have the corresponding permission in the SSP is rejected. SSP in WSA: Two service providers might offer the same application, for example local point of interest notification. If one service provider could masquerade as the other, this could allow attacks such as phishing. To prevent masquerade, Providers could register for a unique identifier, such as a DNS name, and demonstrate that they are authorized for the use of that name. This name could be provided to Users in the appropriate SSP field of the WSA. 5.13.6.4 Revoked certificates A signed communication may be rejected as invalid by a receiver if the signing certificate has been revoked. A certificate is said to be revoked if an authorized entity distributes an authenticated message stating that that certificate is no longer to be trusted. Such an authenticated message is known as a Certificate Revocation List (CRL). If a certificate is revoked, all communications signed by that certificate (for an end-entity certificate) or all certificates signed by that certificate (for a CA certificate) that are received after the issue date of the revocation list are unauthorized and should be rejected. The CME within WAVE Security Services stores revocation information. To save storage space, the CME may periodically remove revocation information that applies only to certificates that would not be trusted anyway, such as expired certificates. CRLs will typically be issued by CAs. A CRL may be distributed to end-entities by WSMP using PSID 0x23, or by other means such as IPv6. IEEE Std 1609.2-2013 includes an informative description of a “certificate management process”, which is a process resident on a WAVE device that carries out communications operations necessary to support receiving CRLs. This may be restricted to receiving CRLs broadcast over WSMP, or it may actively request CRLs that it has not yet received. When the certificate management process receives a CRL, it verifies the CRL using the Security Processing Services and passes the revocation information to the CME for storage and management. 5.13.7 Certificate management 5.13.7.1 General “Certificate management” refers to the following: ⎯ Obtaining private keys and certificates that are used to sign and decrypt communications. These keys are stored on a per-entity basis on the WAVE device. ⎯ Storing root certificates and other trust anchors, and maintaining information about revocation, to allow verification of received signed communications. This information is stored by the CME on the WAVE device. 43 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Both of these management functions require communicating with a Certificate Authority. IEEE Std 1609.2-2013 provides support for certificate management by specifying data structures and the processing necessary to carry out certificate management functions. However, IEEE Std 1609.2-2013 does not specify exact communications procedures to be used to exchange these data structures. These are a necessary part of a system specification and may be included in a future version of the standard. IEEE Std 1609.2-2013 also does not provide a full specification of when to request certificates and exactly what permissions to include in a certificate request. These decisions are made by an entity out of the scope of IEEE Std 1609.2-2013, which is referred to in IEEE Std 1609.2-2013 as a certificate management process. Different WAVE devices, and different applications on WAVE devices, may support different certificate management processes: for example, a certificate management process might support only manual installation of certificates and private keys and only receive CRLs over WSMP, or it might support certificate and CRL requests as and when needed over a data connection. The certificate management process is to be distinguished from the certificate management entity. The certificate management process manages communications with CAs. The certificate management entity stores and manages the information once it has been received. 5.13.7.2 Obtaining certificates: general In IEEE Std 1609.2-2013, a private key and the corresponding certificate are stored at a CMH, which is an index to memory within the Security Processing Services. The private key and certificate may be stored by the following methods: ⎯ The key and certificate may be generated outside the Security Processing Services and imported to a CMH by the appropriate primitive defined in IEEE Std 1609.2-2013. ⎯ The private key and public key may be generated outside the Security Processing Services and stored at a CMH. A certificate management process may then generate a certificate request including the public key, send it to the CA to obtain a certificate, and store the resulting certificate at the CMH. ⎯ The private key and public key may be generated on the device. A certificate management process may then generate a certificate request including the public key, send it to the CA to obtain a certificate, and store the resulting certificate at the CMH. Possible operations of the certificate management process for signed data and signed WSAs are described in 5.13.7.3 through 5.13.7.6 respectively. 5.13.7.3 Obtaining certificates for applications An application that originates or receives secured messages is referred to in IEEE Std 1609.2-2013 as a secure data exchange entity (SDEE). Figure 21 illustrates the functional entities involved in requesting certificates for use by a messageoriginating application. The heavy dashed lines indicate processing defined in the IEEE 1609 standards and the dot-dashed arrow indicates data flows not defined in the IEEE 1609 standards. The functional entities have the following responsibilities: ⎯ The SDEE provides the certificate management process with some or all of the information to be included in the certificate request. Following successful completion of the certificate management process, the SDEE possesses a CMH referencing a private key and the associated certificate. 44 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ The certificate management process is responsible for determining the information to be included in a certificate request, determining the key and certificate to be used to sign the certificate request, invoking the Security Processing Services to create the certificate request, sending the request to the CA, invoking the Security Processing Services to process the response received from the CA and making the returned certificates available to SDEE. ⎯ The CA is responsible for processing a received certificate request and returning the response to the certificate management process. ⎯ The Security Processing Services create the certificate request and all associated keys, store the certificate and keys and process the response from the CA when it is received by the certificate management process. IEEE Std 1609.2-2013 does not define the interface between the certificate management process and the application. For an example of information that might pass across this interface, consider an application that sends WSMs relating to two different PSIDs. The application may have a single certificate containing both PSIDs, or two separate certificates each with one PSID. The trade-off is between packet size on the channel and storage space on the device. Certificate management decisions such as this are made by entities outside the scope of IEEE Std 1609.2-2013. Figure 21 — Functional entities for certificate request for applications Figure 22 shows the overall process flow for certificate request for applications. The heavy dashed box shows functionality defined in the IEEE 1609 standards, specifically IEEE Std 1609.2-2013. The “initialize keys” processing step refers to providing the certificate management process with a CMH that references the keys needed to generate the certificate request. These keys may be generated on or off the WAVE device as discussed in 5.13.7.2. 45 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure 22 — Process flow for certificate request for applications 5.13.7.4 Obtaining certificates for WSAs containing secure application-services Private keys and certificates necessary to sign WSAs are stored and managed by the PSSME. Figure 23 illustrates the functional entities involved in requesting WSA certificates. The heavy dashed lines indicate processing defined in IEEE Std 1609.2-2013, the dotted lines indicate data flows defined in IEEE Std 1609.3-2010, and the dot-dashed lines indicate data flows not defined in any IEEE standard. The functional entities have the following responsibilities: 46 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure 23 — Functional entities for certificate request for WSA signing ⎯ The secure Provider applications provide the PSSME with information that may be included in the certificate request. ⎯ The certificate management process is responsible for determining the information to be included in certificate request, determining the key and certificate to be used to sign the certificate request, invoking the Security Processing Services to create the certificate request, sending the request to the CA, invoking the Security Processing Services to process the response received from the CA, and making the returned certificates available to the secure data exchange entity. ⎯ The CA is responsible for processing a received certificate request and returning the response to the certificate management process. ⎯ The PSSME provides the certificate management process with information that it may use in generating the certificate request and stores the WSA certificates and private keys when the certificate management process receives them from the CA. ⎯ The Security Processing Services create the certificate request and all associated keys and process the response from the CA when it is received by the certificate management process. First, a Provider application registers with the PSSME to obtain a Local Service Index for Security (LSI-S). Then, the Provider application makes its request for a certificate known to the certificate management process. These requests include the LSI-S, the PSID, and the SSP for which the provider application will request inclusion in an advertisement, and the maximum priority at which the Provider will advertise the application-service. The Provider application may request multiple sets of permissions for inclusion in a certificate, for example, multiple PSIDs or multiple SSPs associated with a particular PSID. IEEE Std 1609.2-2013 provides mechanisms for the Provider application to make these requests using the PSSME via the PSSME-SAP. The certificate management process determines which requests to send to the CA, creates the requests using the Security Processing Services, sends them, verifies the response using the Security Processing Services, and processes the response contents. If a certificate is successfully received, the certificate 47 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture management process stores the certificate and key at a CMH and makes this CMH available to the Provider application and the WME via the PSSME-SAP. The Provider application should not submit a Provider service request to the WME until it has been informed that a certificate is available to authorize the associated secured application-service. The Provider application can obtain this information using the mechanisms of IEEE Std 1609.2-2013 via the PSSMESAP, which allow the application to poll the PSSME until the certificate is present. Implementations may provide a different mechanism to notify the application when the certificate is available. Finally, the Provider application registers with the WME using WME-ProviderService.request, providing the LSI-S. The LSI-S enables the WME to identify which application-services are being signed in the WSA; this allows the WME to pass that identification to the Security Processing Services, which in turn use the LSI-S to request a signing key and certificate from the PSSME that permits all the applicationservices in the WSA. Figure 24 — Process flow from newly installed Provider application to ability to send WSAs securely advertising the associated application-service WSA certificates with subsets of Provider applications. As discussed in 5.8, a WAVE Provider may send WSAs containing only a subset of the registered application-services, for example so that the WSA size remains within the IEEE 802.11 Maximum Transmission Unit (MTU). A WSA containing a subset of application-services may be authorized using a certificate that contains a subset of authorized applicationservices, so long as the subset of application-services in the certificate contains the subset of applicationservices in the WSA. The certificate management process for WSAs may anticipate this use case and prepare for it by applying for multiple certificates that contain selected subsets of the application-services. For example, if ten Provider applications have registered with the PSSME, the certificate management process may apply for one certificate for application-services 1–5 and a different certificate for applicationservices 6–10. The IEEE 1609 standards permit this use case but do not provide all the functionality needed to support it. For example, if there is no certificate that covers all application-services, neither IEEE Std 1609.2-2013 nor IEEE Std 1609.3-2010 specifies an interface to inform the WME as to which 48 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture combinations of application-services may be advertised together. These use cases will need to be supported by implementation-specific extensions. 5.13.7.5 Interactions with the CA: certificate request and revocation IEEE Std 1609.2-2013 defines two types of information that originate at a CA: certificates themselves and Certificate Revocation Lists (CRLs). IEEE Std 1609.2-2013 specifies data structures and message flows that may be used to request signing and decryption certificates interactively from the CA. Certificates may also be installed by other means. The choice of what means to use to obtain certificates may vary from application to application. IEEE Std 1609.2-2013 does not specify a communications mechanism to be used to exchange messages with the CA. IEEE Std 1609.2-2013 also specifies data structures that may be used to distribute CRLs. An application might not use CRLs; for example, if the signing devices for that application have reliable connectivity to the CA, the CA could instead issue the devices with short-lived certificates and decline to issue new certificates to a compromised device. If an application uses CRLs, the distribution mechanism should be agreed as part of the application specification. CRLs may be distributed using WSMP with the PSID field in the WSMP header set to 0x23, or by other mechanisms not specified in IEEE Std 1609.2-2013. Received revocation information is stored by the CME. An implementation may also provide other means to enter revocation information into the CME. 5.13.7.6 Bootstrap The IEEE 1609.2 Public Key Infrastructure (PKI) mechanisms assume that each WAVE device has the information necessary to allow it to trust communications from a known CA, and that the CA has the information necessary to allow it to trust certificate requests from the device; in other words, that the WAVE device has access to a root certificate, and the CA has access to some public key belonging to the device, and both the key and the certificate have been obtained in a trustworthy manner and not altered or overwritten. The process that provides this initial cryptographic information to the device and the device’s key to the CA is referred to as IEEE 1609.2 certificate bootstrap. IEEE Std 1609.2-2013 does not provide mechanisms for bootstrap. See 5.13.9 for further discussion. 5.13.8 Privacy 5.13.8.1 General The IEEE 1609 system is intended to be privacy protecting with respect to personal data. Broadly speaking, “privacy” encompasses the concept that unauthorized parties should not be able to make use of my data, authorized parties should only be able to make use of my data with my knowledge, and I should be able to choose which of my data I reveal to which authorized party (for example, my credit card company does not need to know my library card number, my library does not need to know my credit card number, and someone I pay cash to does not even need to know my name). This means that personal (as opposed to institutional) users of the system have a right to expect that their personal data remains under their control: the originator of the data can prevent the data from being used in ways they do not approve. Full privacy is not possible in an intelligent transportation system. Cars are large, visible objects, and can be tracked. Many safety-of-life applications depend on devices frequently broadcasting their location and other dynamic data. The privacy challenge within ITS is to ensure that only information necessary for 49 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture particular uses is sent and that someone who wants to get a user’s private information (such as an address) will not find that ITS are the cheapest source of that information. However, the issue is complicated by considerations of traffic analysis and data mining: if someone can tell that two messages come from me, they can potentially glean information from the combination of the messages. This is often used for good purposes in legal investigations, where the pattern of a suspect’s communication can reveal whether or not the suspect is part of a wider conspiracy. It is often a problem in, for example, healthcare research, where the combination of medical condition, year of birth, and area of residence can often identify a single person, making it difficult to provide appropriately anonymized data sets to researchers. Privacy also depends on the type of user. A person often has an expectation of privacy; a traffic signal does not. An ambulance requesting a signal change is requesting a high level of privileges and so should have a low expectation of privacy, because the claimer of a high level of privileges should be accountable for their actions. On the other hand, the ambulance driver has an expectation of privacy. Additionally, whatever privacy services are provided, there may be a legal right for appropriately authorized parties to reverse that privacy for law enforcement or to ensure the correct operation of the system. 5.13.8.2 Threats and mitigations Threats to privacy within the WAVE system may be based on information from a number of different sources. ⎯ Information from individual application messages. ⎯ Information from a collection of messages for a particular application. ⎯ Information from signalling data (source and destination addresses and other identifiers) for an application. ⎯ Information from RF characteristics of a particular device. ⎯ The combination of application or signalling data from multiple applications. This compromises privacy both because the combination of applications on a device is private (or, put more informally, service provider A does not need to know that I am also using service provider B), and because the exact combination of applications may be unique, or nearly unique, to a given WAVE device and so act as a static identifier. This information may compromise privacy as a result of being obtained by an unauthorized recipient (an eavesdropper), or because it is misused by an authorized recipient. The situation is complicated in the case of a WAVE system because many applications (such as those involving a broadcast Basic Safety Message) have no concept of an authorized user, being intended for broadcast to any receiving WAVE device in the vicinity. The IEEE 1609 standards provide mechanisms that may be used to protect privacy. The following list identifies mechanisms from within the IEEE 1609 standards that protect against particular threats to privacy, as well as areas where mechanisms exist within other standards and areas where mechanisms have not yet been standardized. Information from individual application messages: 50 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ For broadcast applications, privacy should be protected on a per-application basis. Applications that broadcast information unencrypted should not include personally identifying information. ⎯ For non-broadcast applications, IEEE Std 1609.2-2013 provides confidentiality services via the encrypted message. ⎯ For non-broadcast applications, there are many application-layer protocols that can be used to provide confidentiality for the contents of particular messages, for example the IETF protocols Cryptographic Message Syntax (CMS) [B23], Transport Layer Security (TLS) [B25] and Datagram Transport Layer Security (DTLS) [B24]. Information from a collection of messages for a particular application: ⎯ For broadcast applications, applications should avoid static fields within the application data that would allow an eavesdropper to associate one message with another from the same device. ⎯ For non-broadcast applications, this threat is also addressed by encrypting individual messages, using either the mechanisms of IEEE Std 1609.2-2013 or other mechanisms. Information from signaling data (source and destination addresses and other identifiers) for an application: ⎯ The MAC address, IP address (if applicable) and other addresses associated with a particular application should change from time to time. These changes should all be synchronized with each other and with the change of any broadcast identifier in the application data. ⎯ IEEE Std 1609.4-2010 provides the MLMEX-AddressChange primitive to trigger a MAC address change. ⎯ Other protocol-level identifiers within the network stack (for example, IP addresses) may be changed using the mechanisms defined for that protocol. ⎯ Application identifier change may be synched with network identifier change using application-specific mechanisms. ⎯ Encryption at the MAC layer would help protect all signaling data on the first hop of an application message. However, this is not possible for broadcast applications, and no mechanisms are currently defined that are suitable for non-broadcast applications using WAVE communications over IEEE Std 802.11-2012. Information from RF characteristics of a particular device: ⎯ “RF Fingerprinting” (see, for example, Brik et. al [B2], Edman and Yener [B3]) may allow attackers to distinguish one WAVE device from another by its RF transmission characteristics. Currently there are no standards that address this type of attack. The combination of application or signaling data from multiple applications: ⎯ To prevent an attacker from determining that PDUs from different applications come from the same device, the applications may use entirely different sets of network stack identifiers, or may use encryption at the MAC layer if a suitable mechanism is defined. This requires functionality beyond the functionality specified in the IEEE 1609 standards. Planned revisions to IEEE Std 1609.2-2013 include mechanisms to better protect the privacy of senders of broadcast safety messages while allowing certificates of misbehaving units to be revoked. 5.13.9 Platform security considerations Secure use of a WAVE device requires that the device protects access to its resources from attackers who have access to the device. For example: 51 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ Authorization and authentication are only provided by certificates if the certificates can only be used by authorized entities on the transmitting WAVE device. (It should not be possible for malware to get access to the signing keys used by a given application.) ⎯ Access to the safety channel should only be granted to authorized applications. Therefore, before an application (running on a particular device) can apply for certificates, the device and application should be in a state in that is known by the CA to be trustworthy. The CA can trust the device and application if the following considerations hold: ⎯ The device is determined to be functioning correctly, i.e., it does not permit unauthorized access by one process to another process’ keys. ⎯ The application is known to function correctly and use appropriate device and network resources. ⎯ The device has at least one symmetric or private cryptographic key that the CA trusts. To obtain the first property, a device will probably need to undergo a process of certification by an accredited certification program test lab. This certification process has not yet been defined but is discussed in Annex B. To obtain the second property, an application will probably need to undergo a process of certification. This process has also not yet been defined. One way of obtaining the third property is to have two states, an initialization state and an operational state. In the initialization state the device may have keys and other certificate management information such as the identity of trust anchors directly installed on it in a controlled way. Once the device is switched into the operational state, updates to core security management information are only possible as a result of authenticated communications. No mechanisms for this state change have yet been standardized in the ITS setting, but the problem has been well studied in other settings (for example, SIM card initialization). 52 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Annex A (informative) Example system configuration Figure A.1 illustrates one example of an operational system implemented using WAVE devices. Figure A.1—Example system configuration 53 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Annex B (informative) Certification B.1 Scope In the context of this discussion, certification means validation, by testing, of conformance to a published standard and possibly an accompanying defined set of performance requirements. In addition, interoperability testing may be included. Certification of devices to IEEE 1609 standards is not yet defined, but is necessary for successful implementation, operation and maintenance of interoperable 5.9 GHz DSRC V2V and V2I subsystems of the general connected vehicle architecture. The certification process encompasses both OBUs and RSUs. While certification to the IEEE 1609 standards is a necessary condition, a sufficient certification process would provide either proof of or testing of conformance to other physical and performance requirements of devices implementing the IEEE 1609 standards such as FCC Parts 0, 1, 2 & 95, and SAE J551 [B31], J1113 [B32], and J1211 [B33]. Requirement examples include the following: ⎯ Industry standard minimum form factors ⎯ Electrical power consumption ⎯ Local data interface and test ports ⎯ Onboard event logging ⎯ Connectors and cabling ⎯ Environmental conditions ⎯ Static and dynamic positional reporting accuracy ⎯ General documented industry “best practices” From a practical perspective, for example, an IEEE 1609 compliant automotive grade device would be useless if it failed to meet the maximum quiescent power consumption or operational temperature range in an automotive environment. The USDOT Connected Vehicle (CV) initiative is the principal customer for device certification at this writing. A device certification process is needed that can accommodate all wireless modalities likely to be included in the CV ecosystem and that should ultimately coordinate at some level with the CV Core System, the entity that provides transactional trust for the system. 5.9 GHz DSRC, specifically designated for public safety applications in a transportation environment, is the wireless medium for the USDOT Safety Pilot project. 5.9 GHz device certification is being piloted as an integral part of the project. 54 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture B.2 Process The certification process addresses both technical and policy issues and provides governance for implementation and enforcement and the maintenance of items such as a qualified products list. Certification programs typically encompass a combination of compliance and interoperability testing. In a full nationwide deployment scenario, the certification program serves multiple stakeholders including technology vendors and end users. Convergence of multiple technologies with delivery of road safety entails a high-risk potential for all participants, and an adequate, well-managed device certification program can serve to mitigate risk in real world system deployment. Program and process governance should be representative of all stakeholders including regulatory agencies, application developers, system implementers and operators, manufacturers using certified devices, device vendors, end users, and the security certificate entity. In one possible hierarchy, the governance group would evaluate and approve processes submitted by a technical certification process entity that would have membership from standards development groups, commercial and government test houses, and specific end users such as auto manufacturers and device vendors. Certification and standards and requirements are iteratively linked and this structure facilitates the feedback required for process refinement. Certification may be performed entirely by an independent third party test house or in combination with a vendor in-house quality control (QC) facility. The third party test house would be responsible for reviewing the vendor’s submitted QC report as part of its certification procedure. The governance group would establish contractual terms and responsibilities with test entities. The “test stack” and any associated hardware and software tools necessary for performing tests may have been developed by an independent third-party test house or under the aegis of a technical certification process entity solely or in cooperation with one or more third-party test houses. The tool set will include equipment such as spectrum analyzers, multiprotocol signal generators, and standard antennas that are common equipment in wireless test facilities. Custom test tools and test tool compliments will also be required and may be shared or leased at a nominal fee. 55 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Annex C (informative) Representative use cases C.1 Vehicle communication for collision avoidance One of the most important use cases for a WAVE system is communication to and from vehicles for the purpose of enabling collision avoidance applications. Depending on the application, the communication can be among neighboring vehicles and other mobile entities (V2V), between vehicles and roadside infrastructure (V2I), or can include both V2V and V2I. Example applications include Forward Collision Warning, Blind Spot Warning, Intersection Violation Warning, Icy Road Warning, and Longitudinal Collision Risk Warning. These, and many others, are described more fully in other documents, e.g., from SAE, ETSI, and the U. S. Department of Transportation (especially reports related to cooperative projects between the U. S. DOT and the Vehicle Safety Communications [VSC] consortium). This section describes a typical implementation supporting this use case. The collision avoidance applications utilize messages exchanged between WAVE devices. For example, vehicles that use SAE J2735 periodically send their basic state information using the Basic Safety Message (BSM). The BSM conveys the sender’s position, speed, acceleration, heading, and other key information. A vehicle-based application uses received BSMs to determine if a collision threat exists. These same functions are supported in Europe by the ETSI Cooperative Awareness Message (CAM) and Decentralized Environmental Notification Message (DENM). Additional collision avoidance applications can be provided by an RSU, for instance by sending SAE J2735 Signal Phase and Timing (SPAT) and Map Data (MAP) messages to convey the signal state and geographical description of an intersection. Figure C.1 shows the usage of standards by collision avoidance applications. A sender (vehicle or infrastructure) will employ IEEE Std 1609.2-2013 WAVE Security Services to sign and authenticate messages transmitted in support of collision avoidance applications. These messages are most often broadcast, so encryption is not used. The signed messages are sent using WSMP (see 5.3.2, defined in IEEE Std 1609.3-2010. This enables the transmit power to be controlled on a message by message basis. WSMP also promotes bandwidth efficiency, which is critical given that the channel used for safety broadcasts can experience congestion. BSMs and SPAT messages are expected to be sent on pre-determined channels, so there is no need to advertise their availability with the WSA. Their content may be updated as frequently as ten times per second per transmitter. MAP messages might or might not be advertised. In the model considered most likely for deployment in the United States, all three types of message (BSM, SPAT, and MAP) would be sent on an SCH designated as the “safety channel,” which would be monitored continuously by devices interested in receiving this data. Thus, no WSA would be needed for any of the messages. Similarly, the channel switching function of IEEE Std 1609.4-2010 (see 5.11) would be unnecessary for the exchanges on this SCH. A device participating on the “always-on” safety channel could be configured with a second radio over which to participate in other CCH and/or SCH activities. IEEE Std 1609.12 shows three PSID values for application areas related to the BSM. Two PSID values will be used for vehicle BSMs, one of these intended for messages composed using vehicle sensor data that meets defined high accuracy requirements.10 Devices that do not have data at the defined level of accuracy will use the second PSID value. The third PSID value is used for messages composed by devices in tracked vehicles (e.g., trains). The respective PSID value is carried in the WSMP header, which enables a receiver to efficiently distinguish the three classes of BSM. A fourth PSID value has been allocated for an application area associated with SAE J2735 intersection messages. This will be used in the header of a 10 At time of writing, the sensor requirements are under development by SAE DSRC Message Sets Technical Committee. 56 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture 1609.3 802.11 1609.4 Management Security WSM carrying a SPAT or MAP message. PSID values have also been allocated for other application areas associated with SAE J2735 messages; a total of nine PSID values for SAE J2735 had been allocated at the time this standard was being written. Figure C.1—Standards used for collision avoidance IEEE Std 1609.3-2010 includes the specification of the optional WSMP Safety Supplement (WSMP-S). WSMP-S allows a sender of a safety message (e.g., BSM) to convey additional information about its capabilities regarding multi-channel operation. This initial WSMP-S usage is not needed in an environment with an “always-on” safety channel as described previously, but it provides flexibility for other channel models. More importantly, the WSMP-S mechanism is extensible. Its definition can be expanded in future revisions of IEEE Std 1609.3 to permit a sender to convey additional information in support of safety applications. An example usage of an expanded WSMP-S is to advertise local channel load measurements to enable fair allocation of channel resources in a distributed congestion control algorithm. C.2 Electronic fee collection C.2.1 Introduction This use case description considers an electronic fee collection (EFC), specifically a toll collection, transaction using technology as specified in the WAVE standards, including IEEE Std 1609.3-2010, IEEE 57 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Std 1609.4-2010, and IEEE Std 1609.11-2010 Annex A (Profile for Electronic Fee Collection systems per ISO 14906 and ISO 15628:2007). At a tolling gantry, an RSU acts as a Payee Unit (as defined in IEEE Std 1609.11-2010); vehicles carry OBUs acting as Payer Units. The general objective is that the tolling transaction is accomplished reliably and securely while the vehicle passes the tolling gantry at highway speeds. From a toll operator’s perspective, the transaction should occur within a spatial/temporal frame that provides unambiguous association of the logical payer with a physical vehicle (i.e., localization) for compatibility with revenue protection violation detection and enforcement systems. In other words, if five vehicles drive through the toll plaza, but only four electronic tolls are paid, the system determines which of the vehicles is the violator. It may accomplish this by photographing each vehicle and matching each photo to a transaction. In doing so, it determines the time and lane in which each vehicle performs its EFC transaction. C.2.2 Example 1: localization via RF coverage Figure C.2 illustrates a first example of such a system. Vehicles carrying battery-powered WAVE OBU toll tags approach the tolling gantry from the right. A three-antenna RSU supports the operation. A first RSU WAVE radio is tuned to the CCH and transmits a series of wake-up frames and WSAs that announce the presence of the tolling service and deliver the particulars of the service, including the SCH to be used. Two other RSU WAVE radios are tuned to the SCH and execute the exchange of messages that accomplish the tolling transaction. These SCH radios transmit and receive through antennas configured for localization of the specific vehicles/tags. Figure C.2—Example toll collection setup, localization via RF coverage C.2.3 OBU wake-up If the OBU Payer units are battery powered, it is desirable to allow them to become dormant between tolling exchanges to extend battery life, waking up just in time to accomplish each EFC transaction. Receipt of a well-defined unique radio signal transmitted in an area just prior to the tolling gantry can serve as the wake-up trigger. An example design for this feature is described following. Repeated IEEE 802.11 QoS Null frames transmitted at 6Mbps on the CCH are used as a wake-up trigger. Three such frames within a time window (2 ms) above a signal threshold (–44 dBm ±3 dB) cause the receiving OBU to wake up. This unique pattern gives the wake-up mechanism certain robustness against other strong radio signals but enables the battery powered OBU to wake-up within reasonable distance to the service area to successfully accomplish a complete EFC transaction at maximum highway speeds. Figure C.3 illustrates an example of such a wake-up pattern transmitted on the CCH. 58 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Figure C.3—Wake-up pattern C.2.4 Example 2: localization via GPS reports In a second example, the tolling system relies on location reports from the OBUs to determine their lane. As vehicles enter the CCH coverage zone, they receive the WSA with information about the upcoming tolling service. As part of the message exchange with the RSU, each OBU provides precise location information, e.g., derived from GPS. This scenario illustrates an example where the OBUs are powered from the vehicle battery and therefore do not require the wake-up signal. (These location reports are not included in the tolling exchange described in C.2.5. The vehicle location could be delivered over WSMP during the message exchange of Figure C.5. Alternately, if the OBU is broadcasting its location, e.g., in a Basic Safety Message as described in C.1, the RSU could derive its location via that means.) This integrated OBU might include dual radios, so that one radio could continuously participate in safety services via an “always-on” safety channel as described in C.1, while the other radio switches among control and service channels to participate in other application-services, such as EFC. In a deployment including tag-type OBUs of example 1 as well as integrated OBUs of example 2, the RSU at the gantry illustrated in Figure C.2 could support both scenarios. The communication range of the integrated OBU would be larger compared to example 1 as the OBU is continuously active and does not need to go dormant to extend its battery life. C.2.5 Message exchange Refer to Figure C.4 and Figure C.5, adapted from IEEE Std 1609.11-2010 Annex A, that illustrate an example message exchange occurring on the SCH, consistent with localization via RF coverage per example 1 in C.2.2. IEEE Std 1609.11 identifies three elements within each of the Payer and Payee; here the discussion is simplified by referring to the combination of the elements as “Payer application” and “Payee application.” Each device participates in an advertised application-service opportunity as specified in IEEE Std 1609.32010 and described in 5.7. The OBU is configured as a User, which causes it to monitor received WSAs for an application-service of interest, e.g., EFC. The RSU is configured as a Provider, with its first WAVE radio to transmitting WSAs on the CCH, and the other WAVE radios monitoring the SCH for EFC activity, i.e., waiting for Payers to arrive. The WSA has the following parameters of interest, shown in Table C.1. 59 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Table C.1—Example Provider service request parameters Parameter Destination MAC address WSA type PSID Channel number Channel access Repeat rate IP service Value broadcast unsecured 0x01 182 continuous 250 false Notes WSA is broadcast WSA is not signed electronic fee collection SCH identifier User may switch to SCH immediately WSA transmitted 5 times per 100 ms WSMP is used The coverage areas of the RSU radios may be optimized by choosing the antenna characteristics and configuring transmit power for each radio channel appropriately. The OBU’s User service request has parameters matching those of the WSA Service Info, e.g., PSID 0x01. The OBU Payer and RSU Payee applications also register with their local WAVE management entity as recipients of received WAVE Short Messages on the EFC PSID (again, 0x01, per IEEE Std 1609.12). 1) When an OBU enters the CCH coverage zone, it recognizes the WSA transmissions on the CCH as indicating the presence of an EFC service. Battery powered OBUs will first be awakened by the wake-up signal pattern. The OBU receives and processes the WSA to determine the specifics of the application-service. 2) The OBU WME switches its radio to the indicated SCH, with immediate and extended access, and notifies the Payer application. 3) The Payer application constructs a Vehicle Service Table (VST) for delivery to the Payee application via WSMP. The VST identifies the Payer device and provides pertinent information to the Payee application. Figure C.4—Example EFC message exchange, part 1 4) Next, as shown in Figure C.5 step 4, the roadside Payee application (still using WSMP for transport) queries the vehicle Payer application for information, e.g., concerning the Payer’s previous two tolling transactions, as well as information concerning the payment method. The 60 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Payer responds via WSMP. IEEE Std 1609.11-2010 specifies how the data is encoded and how the sensitive data is encrypted. The Payee requests additional vehicle data such as EquipmentOBUID and VehicleLicencePlateNumber, perhaps using the same request, or a separate one as shown here. 5) The Payee application determines the appropriate toll to be charged, and delivers the information to the Payer application over WSMP. The Payer may store this for later use, thus completing the payment. 6) The Payee application (via WSMP) triggers a notification (e.g., an audible beep) to the operator at the OBU. 7) The Payee application indicates to the Payer application that the transaction is complete. The Payer application causes the User to stop participating in the application-service opportunity, i.e., the OBU ceases operation on the SCH and returns to CCH monitoring. 8) If appropriate, the device is put back to sleep to conserve battery charge. A short-duration timer may be used to prevent the device from reawakening on a trigger from the tolling station that it is leaving. 61 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture OBU RSU Payer application WAVE Switching WAVE – SCH Payee application TRANSACTION PHASE Message with requests for ReceiptData1, ReceiptData2 and secured PaymentMeans SCH Operation WSM-WaveShortMessage.ind 4 Message with ReceiptData1, ReceiptData2 and encrypted PaymentMeans WSM-WaveShortMessage.req WSM-WaveShortMessage.ind WSM-WaveShortMessage.req 5 6 WSM-WaveShortMessage.ind WSM-WaveShortMessage.ind Message with requests for EquipmentOBUID, VehicleLicensePlate Number, ... Message with EquipmentOBUID, VehicleLicensePlate Number, ... Message with ReceiptData1 and ReceiptData2 Message with SET_MMI request WSM-WaveShortMessage.req WSM-WaveShortMessage.ind WSM-WaveShortMessage.req WSM-WaveShortMessage.ind WSM-WaveShortMessage.req WSM-WaveShortMessage.req END OF TRANSACTION 7 WSM-WaveShortMessage.ind 8 WME-UserService.req (Action = delete) Closing message WSM-WaveShortMessage.req CCH Operation Figure C.5—Example EFC message exchange, part 2 62 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Annex D (informative) International ITS documents At the time of the writing of this guide, the current status of CEN, ETSI, and ISO ITS standards has been published at the following location. http://www.imobilitysupport.eu/imobility-support/its-deployment/standardisation/library/reports-10 It is the stated intent of this document’s author to keep it up to date. 63 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Annex E (informative) Mapping PSID values to a contiguous set of integers As specified in IEEE Std 1609.3-2010 and IEEE Std 1609.12, PSID values are allocated as unique variablelength octet strings. However, there is a one-to-one mapping between these unique octet strings and the contiguous set of integers (starting at zero) which is obtained by interpreting the “non-length” bits of the PSID as integers with appropriate offsets added depending on the number of octets. This one-to-one mapping may simplify the procedure by which an organization or individual requests an assignment of PSID values from a registration authority, and is a means for ensuring harmonization with international standards that define this identifier (e.g., ITS Application Identifier [ITS-AID]) as a variable length integer. Table E.1 below illustrates this mapping. Each PSID value has 1 to 4 bits [the most significant bit(s)] that indicate the length of the field. Stripping these bits yields a range of values starting at zero, as shown in the third and fourth columns. An appropriate integer offset may be determined chosen, as shown in the fifth column. Adding this offset to the “stripped” values results in a contiguous set of unique integer values, as shown in the final column. Table E.1— A mapping from PSID value to integer PSID length (octets) 1 00 – 7F Value with MSBs stripped (hex) 00 – 7F Value with MSBs stripped (decimal) 0 – 127 0 0 – 127 2 80-00 – BF-FF 00-00 – 3F-FF 0 – 16,383 128 128 – 16,511 3 C0-00-00 – DF-FF-FF E0-00-00-00 – EF-FF-FF-FF 00-00-00 – 1F-FF-FF 00-00-00-00 – 0F-FF-FF-FF 0– 2,097,151 0– 268,435,455 16,512 16,512 – 2,113,663 2,113,664 – 270,549,119 4 PSID value (hex) Integer offset 2,113,664 Mapped integer value 64 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Annex F (informative) Deployment history During the time that the WAVE standards have been under development, there have been a number of field trials to validate, and suggest improvements to, the technology. In the U. S., the major deployments have been the Vehicle Infrastructure Integration Consortium (VIIC) Proof of Concept (POC) project, and the Safety Pilot Model Deployment conducted by the University of Michigan Technology Research Institute (UMTRI) for the U. S. Department of Transportation. The VIIC Proof of Concept project was a field test run in the north-west suburbs of Detroit, Michigan involving 27 vehicles and 55 roadside units. The project was announced in 2005, development and integration work took place in 2006 and 2007, and the field trial itself ran from fall 2007 through 2008. The technology was based on the 2006 trial-use versions of IEEE Std 1609.2, IEEE Std 1609.3, and IEEE Std 1609.4, along with the then-current draft of IEEE P802.11p. Separate final reports were produced for the vehicle and infrastructure components and are available from http://www.its.dot.gov/vii/. Some modifications and extensions were made to the IEEE 1609 standards features to meet the requirements of the POC. Specifically, IEEE Std 1609.2-2013 was extended to support anonymous certificates that could not be linked to their holders and to support secure sessions via two novel protocols—Vehicular Datagram Transport Layer Security (V-DTLS) and Vehicular Host Identity Protocols (V-HIP). Subsequently, the WAVE standards were updated to full-use as a result of recommendations and observations made during POC. Changes included the following: ⎯ IEEE Std 1609.4-2010: Support MAC address change ⎯ IEEE Std 1609.3-2010: ⎯ ⎯ Removed WSM forwarding ⎯ Made WSMP header extensible ⎯ Introduced the practice of describing IEEE 802.11p operations as “outside the context of a basic service set” ⎯ Removed requirements for the WME or the WAVE protocol stack to maintain state information on applications ⎯ Added indication of link quality to allow higher layers to use this to choose applicationservices ⎯ Removed idle channel timeout ⎯ Changed from Application Class Identifier (single byte) to variable-length PSID IEEE Std 1609.2-2013: ⎯ Introduced the ToBeEncrypted type ⎯ Removed SecuredWSM: secured data sent over WSMP is secured at the application layer, not within the network stack 65 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture ⎯ Improved certificate management processes, including encrypting messages and introducing error notifications and acknowledgements The Safety Pilot Model Deployment was a field test run in Ann Arbor, Michigan, involving 2,564 cars, 169 trucks, 103 transit vehicles, and 29 roadside units. The selection of UMTRI as Test Conductor was announced in August 2011, the first cars were driven as part of the Model Deployment on August 21, 2012, and the project is scheduled at the time of writing to run through August 2013. The technology was based on the 2010 versions of IEEE Std 1609.3 and IEEE Std 1609.4, along with draft 9.3 of IEEE P1609.2 and the sections of IEEE Std 802.11-2012 referring to operation outside the context of a basic service set. WAVE devices used in this program were conformant to these standards, with the exception that the specific form of security certificate used in the program was not defined in draft 9.3 of IEEE P1609.2. This certificate provides anonymity so it cannot easily be linked to a specific vehicle. The IEEE 1609 WG expects to consider revising or amending IEEE 1609.2 to include a form of anonymous certificate, based on experience obtained through the Model Deployment program. As part of the project, certification test services were developed and provided by OmniAir and Booz Allen Hamilton. At the time of writing, up-todate information about the project is available from http://www.safetypilot.us. Other ITS deployments in the U. S. include the following. Vehicle counts have been provided by knowledgeable sources. ⎯ Scalability tests run by the Vehicle Safety Communications 3 (VSC3) consortium, which have involved up to 200 vehicles in 2011–2013. ⎯ New York State Affiliated Test Bed fielded a demo system for the 2008 World Congress Technology Showcase with 22 RSUs on I-495 corridor and in Manhattan. Later expanded with an emphsis on commercial vehicles to include 20 aftermarket devices, 4 plow trucks, and 39 RSUs. ⎯ Michigan Affiliated Test Bed, on the same site as the VII POC. ⎯ Anthem, Arizona, with six pole mounted RSUs integrated with signal controllers, and OBUs deployed in emergency response vehicles. ⎯ Palo Alto, California, with RSUs mounted along El Camino Real and OBUs in personal vehicles, transit buses and commercial trucks. Applications include traveler information, electronic payment, ramp metering and curve over-speed warning. ⎯ Orlando, Florida, demo system at the 18th World Congress Technology Showcase, with 24 RSUs. ⎯ Minnesota deployments including 500 volunteer vehicles and 80 snow plows. ⎯ Two testbeds in Virgina support a mix of vehicular types and dozens of RSUs. European field tests have in general used a profile of IEEE Std 802.11p for PHY and lower MAC. Some European field tests have used IEEE Std 1609.2-2013 for security services. In general, European field tests have not used IEEE Std 1609.3-2010 or IEEE Std 1609.4-2010. 66 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture Annex G (informative) Bibliography [B1] ASTM E2213-03-2003, Standard Specification for Telecommunications and Information Exchange Between Roadside and Vehicle Systems—5 GHz Band Dedicated Short Range Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) Specifications. [B2] Brik, V., Banerjee, S., Gruteser, M., and Oh, S. Wireless device identification with radiometric signatures, Proceeding MobiCom '08MobiCom '08 Proceedings of the 14th ACM international conference on Mobile computing and networking ACMACM New York, NY, USA 2008. doi> 10.1145/1409944.140995910.1145/1409944.1409959.11 [B3] Current Status of Security Standards, Document #1-1, EU-US ITS Task Force, Standards Harmonization Working Group. [B4] Edman, M., Yener, B., Attacks against Modulation-based Radiometric Identification http://ftp.cs.rpi.edu/research/pdf/09-02.pdf [B5] ETSI EN 302 665, Intelligent Transport Systems (ITS); Communications Architecture. [B6] Federal Communications Commission ET Docket No. 98-95, RM-9096, Amendment of Parts 2 and 90 of the Commission’s Rules to Allocate the 5.850–5.925 GHz Band to Mobile Service for Dedicated Short Range Communications of Intelligent Transportation Services. [B7] Federal Communications Commission FCC 03-324–2004, Amendment of the Commission’s Rules Regarding Dedicated Short-Range Communication Services in the 5.850–5.925 GHz Band (5.9 GHz Band). [B8] Federal Communications Commission FCC 06-110 2006, Amendment of the Commission’s Rules Regarding Dedicated Short-Range Communication Services in the 5.850–5.925 GHz Band (5.9 GHz Band). [B9] Feedback to Standards Development Organizations, Document #1-3, EU-US ITS Task Force, Standards Harmonization Working Group. [B10] Feedback to Standards Development Organizations—Communications, Document #3-3, EU-US ITS Task Force, Standards Harmonization Working Group. [B11] IEEE Std 802.2-1998 (ISO/IEC 8802-2:1994), IEEE Standard for Information technology— Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 2: Logical link control. [B12] IEEE Std 802.11p-2010, IEEE Standard for Information technology—Telecommunications and information exchange between systems—Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Amendment 6: Wireless Access in Vehicular Environments. [B13] IEEE Std 1363™-2000, IEEE Standard Specifications for Public Key Cryptography. [B14] IEEE Std 1363a™-2004, IEEE Standard Specifications for Public Key Cryptography: Additional Techniques. [B15] IEEE Std 1609.1-2006, IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)—Resource Manager [WITHDRAWN]. 11 Available from www.winlab.rutgers.edu/~gruteser/papers/brik_paradis.pdf. 67 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1609.0-2013 IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture [B16] IEEE Std 1609.2-2006, IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)—Security Services for Applications and Management Messages [WITHDRAWN]. [B17] IEEE Std 1609.3-2007, IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)—Networking Services [SUPERCEDED]. [B18] IEEE Std 1609.4-2006, IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)—Multi-Channel Operation [WITHDRAWN]. [B19] IEEE P1609.6, Draft Standard for Wireless Access in Vehicular Environments (WAVE)—Remote Management Services.12 [B20] IETF Request for Comments: RFC 768-1980, User Datagram Protocol. [B21] IETF Request for Comments: RFC 793-1981, Transmission Control Protocol. [B22] IETF Request for Comments: RFC 2460-1998, Internet Protocol, Version 6 (IPv6) Specification. [B23] IETF Request for Comments: 3852, Cryptographic Message Syntax (CMS). [B24] IETF Request for Comments: 4347, Datagram Transport Layer Security (DTLS). [B25] IETF Request for Comments: 5246, The Transport Layer Security (TLS) Protocol Version 1.2. [B26] IETF Request for Comments: 6071, IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap. [B27] ISO/IEC 7498-1:1994, Information Technology—Open Systems Interconnection (OSI) 7 layer reference model. [B28] ISO/IEC 42010:2007 (IEEE Std 1471™-2000), Systems and software engineering—Recommended practice for architectural description of software-intensive systems. [B29] ISO 21217:2010, Intelligent transport systems—Communications access for land mobiles (CALM— Architecture. [B30] National ITS Architecture, Version 7.0, U. S. Department of Transportation, Research and Innovative Technology Administration. [B31] SAE J551/1, Performance Levels and Methods of Measurement of Electromagnetic Compatibility of Vehicles, Boats (up to 15 m), and Machines (16.6 Hz to 18 GHz). [B32] SAE J1113/1, Electromagnetic Compatibility Measurement Procedures and Limits for Components of Vehicles, Boats (up to 15 m), and Machines (Except Aircraft) (16.6 Hz to 18 GHz). [B33] SAE J1211, Handbook for Robustness Validation of Automotive Electrical/Electronic Modules. [B34] Standards for Efficient Cryptography Group, “SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV)”, Working Draft Version 0.97, March 2011. [B35] Status of Communication Standards, Document #3-1, EU-US ITS Task Force, Standards Harmonization Working Group. [B36] United States Code of Federal Regulations, Title 47 Telecommunication. 12 This IEEE standards project was not approved by the IEEE-SA Standards Board at the time this publication went to press. For information about obtaining a draft, contact the IEEE. 68 Copyright © 2014 IEEE. All rights reserved. Authorized licensed use limited to: University Town Library of Shenzhen. Downloaded on January 04,2018 at 13:03:28 UTC from IEEE Xplore. Restrictions apply.
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.7 Linearized : No Tagged PDF : No Page Layout : SinglePage XMP Toolkit : Adobe XMP Core 5.1.0-jc003 Format : application/pdf Create Date : 2014:02:07 14:42:13-05:00 Creator Tool : Microsoft® Word 2010 Modify Date : 2018:01:04 08:03:28-05:00 Metadata Date : 2018:01:04 08:03:28-05:00 Producer : Microsoft® Word 2010; modified using iText® 5.5.10 ©2000-2015 iText Group NV (AGPL-version) Document ID : uuid:734e9919-acfc-4f0f-98fb-6e7627970437 Instance ID : uuid:5b81c871-3bbc-4ef8-a8ed-5508edf20997 Creator : Intelligent Transportation Systems Committee of the IEEE Vehicular Technology Society Title : IEEE Std 1609.0-2013, IEEE Guide for Wireless Access in Vehicular Environments (WAVE)—Architecture Description : The wireless access in vehicular environments (WAVE) architecture and services necessary for WAVE devices to communicate in a mobile vehicular environment are described in this guide. It is meant to be used in conjunction with the family of IEEE 1609 standards as of its publication date. These include IEEE Std 1609.2™, IEEE Standard Security Services for Applications and Management Messages, IEEE Std 1609.3 Networking Services, IEEE Std 1609.4 Multi-Channel Operation, IEEE Std 1609.11 Over-the-Air Electronic Payment Data Exchange Protocol for Intelligent Transportation Systems (ITS), IEEE Std 1609.12 Identifier Allocations, and IEEE Std 802.11 in operation outside the context of a basic service set. Subject : dedicated short range communications, DSRC, IEEE 1609.0™, OBU, onboard unit, Provider Service Identifier (PSID), roadside unit (RSU), WAVE, WAVE service advertisement, wireless access in vehicular environments, WSA, WAVE Short Message, WAVE Short Message Protocol, WSM, WSMP Page Mode : UseOutlines Page Count : 78 Language : en-US Has XFA : No Author : Intelligent Transportation Systems Committee of the IEEE Vehicular Technology Society Keywords : dedicated short range communications, DSRC, IEEE 1609.0™, OBU, onboard unit, Provider Service Identifier (PSID), roadside unit (RSU), WAVE, WAVE service advertisement, wireless access in vehicular environments, WSA, WAVE Short Message, WAVE Short Message Protocol, WSM, WSMPEXIF Metadata provided by EXIF.tools