1、IEEE Std 1609.1-2006IEEE Trial-Use Standard forWireless Access in VehicularEnvironments (WAVE)Resource ManagerI E E E3 Park Avenue New York, NY10016-5997, USA13 October 2006IEEE Vehicular Technology Society (VTS)Sponsored by theIntelligent Transportation Systems (ITS) CommitteeThe Institute of Elect
2、rical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2006 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 13 October 2006. Printed in the United States of America.IEEE is a registered trademark in the U.S. Patent +1 97
3、8 750 8400. Permission to photocopy portions ofany individual standard for educational classroom use can also be obtained through the Copyright ClearanceCenter.Copyright 2006 IEEE. All rights reserved. iiiIntroductionThis standard is based on IEEE Std 1455-1999 B4abut intended for the 5.9 GHz freque
4、ncy band. Severalchanges have been incorporated to accommodate the new requirements of the communication stackdescribed in the associated standards (IEEE Std 1609.2,bIEEE P1609.3, and IEEE P1609.4B3) andthe User Datagram Protocol (UDP) described in IETF RFC 768. As well, some inconsistencies and err
5、ors inIEEE Std 1455-1999 have been addressed.This standard specifies a wireless access in vehicular environments (WAVE) application, known as theresource manager (RM), designed to allow applications at remote sites to communicate with devices knownas onboard units (OBUs), which are mounted in vehicl
6、es, through devices known as roadside units (RSUs),which are mounted on the roadside. The RM, acting like an application layer, multiplexes thecommunications of multiple remote applications, each communicating with multiple OBUs. The purpose ofthe communication is to conduct information interchange,
7、 needed to implement the requirements of theremote WAVE applications.Notice to usersErrataErrata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL forerrata periodica
8、lly.InterpretationsCurrent interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/index.html.PatentsAttention is called to the possibility that implementation of this standard may require use of subject mattercovered by patent rights. By publication of thi
9、s standard, no position is taken with respect to the existence orvalidity of any patent rights in connection therewith. The IEEE shall not be responsible for identifyingpatents or patent applications for which a license may be required to implement an IEEE standard or forconducting inquiries into th
10、e legal validity or scope of those patents that are brought to its attention.aThe numbers in brackets correspond to the numbers of the bibliography in Annex E.bInformation on references can be found in Clause 2.This introduction is not part of IEEE Std 1609.1-2006, IEEE Trial-Use Standard for Wirele
11、ss Access in VehicularEnvironments (WAVE)Resource Manager.Publication of this trial-use standard for comment and criticism has been approved by the IEEE. Trial-usestandards are effective for 24 months from the date of publication. Comments for revision will beaccepted for 18 months after publication
12、 Suggestions for revision should be directed to the Secretary,IEEE-SA Standards Board, 445 Hoes Lane, Piscataway, NJ 08854, and should be received no later than13 April 2008. It is expected that following the 24-month period, this trial-use standard, revised andballoted as necessary, shall be submi
13、tted to the IEEE-SA Standards Board for approval as a full-usestandard.iv Copyright 2006 IEEE. All rights reserved.ParticipantsThe following is a list of participants in the Dedicated Short-Range Communications (DSRC) WorkingGroup.Thomas M. Kurihara, ChairThe following members of the individual ball
14、oting committee voted on this standard. Balloters may havevoted for approval, disapproval, or abstention. TiVon AbramsScott AndrewsLee ArmstrongJames ArnoldBroady CashKen CookSusan DickeyWayne FisherGamez GergesGloria GwynneChris HedgesRon HochnadelJason HunzingerDaniel JiangCarl KainPankaj KarnikDo
15、ug KavnerDavid KelleyBrian KindPeter KofodJapjeev KohliRyan LammJerry Landt Jules MadeyAlastair MalarkyMira MarshallTim McGuickinJustin McNewYasser MorganJohn MoringRoss MorrisRichard NoensRoger OConnorPeter OomenSam OyamaFrank PerrySusan ProperMohan PundariEric RescoraRandy RoebuckRichard RoyTom Sc
16、haffnitDick SchnackeJerry ServissJohn SheppardRobert SoranoStephen Spenler Steve TenglerDan TerrierGlenn TurnockBryan WellsFilip WeytjensWilliam WhyteJijun YinJeffery ZhuSatish K. AggarwalToru AiharaAdewole C. AkposeThomas AlexanderGerald W. AlthauserButch AntonLee R. ArmstrongCharles L. BarestJohn
17、R. BarrSaman BehtashSean S. CaiJames T. CarloJuan C. CarreonBroady B. CashJon S. ChambersDanila ChernetsovElizabeth ChesnuttAik ChindapolKeith ChowJ. Kenneth CookTommy P. CooperCarlo DonatiSourav K. DuttaWayne K. FisherAndre F. FournierAvraham FreedmanH. M. GlickensteinSergiu R. GomaRandall C. Grove
18、sGloria G. GwynneRonald D. HochnadelWerner HoelzlDennis HorwitzRussell D. HousleyDavid HunterArshad HussainPeeya IwagoshiRaj JainOh JongtaekKevin J. KarczPankaj R. KarnikPiotr KarockiDouglas M. KavnerThomas M. KuriharaJeremy A. LandtSolomon LeeDaniel G. LevesqueJun LiuWilliam LumpkinsG. L. LuriJuliu
19、s M. MadeyFaramarz MaghsoodlouJustin P. McnewGeorge J. MiaoGary L. MichelWilliam J. MitchellJohn T. MoringRoss A. MorrisMichael S. NewmanPaul NikolichRichard H. NoensSatoshi ObaraPeter OomenSatoshi OyamaSubburajan PonnuswamyVikram PunjPhilip T. RobinsonRobert A. RobinsonRandal D. RoebuckRandall M. S
20、afierOsman SakrStephen C. SchwarmRich SeifertGerald K. ServissJohn W. SheppardRobert T. SorannoStephen J. SpenlerLuca SpotornoThomas J. TimchoGlenn TurnockMark-Rene UchidaScott A. ValcourtStephen C. WebbDoulgas L. WelkFilip WeytjensWilliam WhytePaul R. WorkCopyright 2006 IEEE. All rights reserved. v
21、When the IEEE-SA Standards Board approved this standard on 15 September 2006, it had the followingmembership:Steve M. Mills, ChairRichard H. Hulett, Vice ChairJudith Gorman, Secretary*Member EmeritusAlso included are the following nonvoting IEEE-SA Standards Board liaisons:Satish K. Aggarwal, NRC Re
22、presentativeRichard DeBlasio, DOE RepresentativeAlan H. Cookson, NIST RepresentativeMichelle D. TurnerIEEE Standards Program Manager, Document DevelopmentMatthew CegliaIEEE Standards Program Manager, Technical Program DevelopmentMark D. BowmanDennis B. BrophyJoseph BruderRichard CoxBob DavisJulian F
23、orster*Joanna N. GueninMark S. HalpinRaymond HapemanWilliam B. HopfLowell G. JohnsonHerman KochJoseph L. Koepfinger*David J. LawDaleep C. MohlaPaul NikolichT. W. OlsenGlenn ParsonsRonald C. PetersenGary S. RobinsonFrank StoneMalcolm V. ThadenRichard L. TownsendJoe D. WatsonHoward L. Wolfmanvi Copyri
24、ght 2006 IEEE. All rights reserved.Contents1. Overview 11.1 Scope 11.2 Purpose. 22. Normative references. 23. Definitions, abbreviations, and acronyms 33.1 Definitions . 33.2 Abbreviations and acronyms . 34. Architecture and communications flow summary . 44.1 General. 44.2 Application component refe
25、rences 64.3 WAVE RMA data transfer and management services 64.4 Data structure representation . 64.4.1 Protocol data units (PDUs) 74.4.2 Service data units (SDUs) 74.5 Summary of operation . 85. OBU resources. 105.1 General. 105.2 Memory 105.2.1 Storage pages . 115.2.2 Memory-mapped pages 115.2.3 Tr
26、ansfer pages 125.3 User interfaces (UIs) 125.3.1 Visual displays. 125.3.2 Buzzers (audible alert) . 125.3.3 Enunciators 125.3.4 Character readout. 125.3.5 Keypad . 125.3.6 Future UI resources125.4 Data formats for memory resources. 126. RM command set . 136.1 Overview 136.2 Command format . 146.2.1
27、Command Identifier field. 156.2.2 No Response Indicator bit 166.2.3 Command Transaction Identifier field. 166.2.4 Command Parameter Length field. 166.2.5 Command Parameter field . 176.3 Response format 176.3.1 Command Identifier field. 186.3.2 Command Transaction Identifier field. 186.3.3 Response S
28、tatus field . 18Copyright 2006 IEEE. All rights reserved. vii6.3.4 Response Length field . 196.3.5 Response Data field . 206.4 Command definitions. 206.4.1 Read Memory Page command. 206.4.2 Write Memory Page command 216.4.3 Insert Message command. 226.4.4 Set User Interface command 236.4.5 Sleep Tra
29、nsaction command 256.4.6 Reserve Memory Page command 266.4.7 Release Memory Page command. 266.4.8 Reserve Partition command . 276.4.9 Release Partition command . 287. Services provided by the RM to the RMA 297.1 General. 297.2 RMA-RM interface service elements 297.2.1 PDUsRMA APDU. 297.2.2 SDUsRMA A
30、SDU. 297.2.3 PDU and SDU naming convention 307.3 Protocol services 307.4 Protocol management services. 317.4.1 Activate request service . 317.4.2 Activate response service. 327.4.3 Notify indication service 327.4.4 Notify confirmation service . 337.4.5 Terminate session indication service . 347.4.6
31、Terminate session confirmation service 347.4.7 Deactivate request service . 357.4.8 Deactivate response service . 357.5 Protocol data transfer services . 367.5.1 Exchange request service. 367.5.2 Exchange response service 367.5.3 Exchange confirmation service 378. Interface to services used by RM. 3
32、88.1 General. 388.2 OBU information not accessible using standard command set . 388.3 Registration of RM and RCP . 388.4 WME notification to RCP 388.5 OBU information returned in the response to PST by RCP 388.5.1 Memory Configuration field 398.5.2 OBU Configuration field . 408.5.3 Maximum Applicati
33、on Data Block field . 418.6 Reception of RPST by RM 418.7 Auto-command sequence processing. 418.8 Conducting an application session. 418.9 Termination of application session 42Annex A (normative) ASN.1 encoding . 43Annex B (normative) Registered pages and partitions 48viii Copyright 2006 IEEE. All r
34、ights reserved.Annex C (normative) Protocol Implementation Conformance Statement (PICS) proforma. 50C.1 General. 50C.2 Abbreviations and special symbols 50C.3 Instructions for completing the PICS proforma. 50C.4 PICS proformaIEEE Std 1609.1 52Annex D (informative) Definitions 58D.1 Command. 58D.2 On
35、board equipment (OBE) 58D.3 Page 59D.4 Partition 59D.5 Protocol data unit (PDU) . 59D.6 Roadside equipment (RSE) 60D.7 Service data unit (SDU). 60D.8 Session . 60D.9 Transaction. 61D.10 User 62Annex E (informative) Bibliography. 63Copyright 2006 IEEE. All rights reserved. 1IEEE Trial-Use Standard fo
36、r Wireless Access in Vehicular Environments (WAVE)Resource Manager1. OverviewThere are two types of wireless access in vehicular environments (WAVE) devices. The first type, referredto as the roadside unit (RSU), is stationary while in operation and usually permanently mounted along theroadside. The
37、 second type, known as the onboard unit (OBU), may operate while mobile and is usuallymounted onboard a vehicle (see Figure 1 in 4.1). Typically, the stationary devices host an application thatprovides a service, and the mobile devices host a peer application that uses this service. There may also b
38、eapplications on devices remote from the RSU, whose purpose is to provide services to the OBU. Thisstandard describes a WAVE application that resides on the RSU but is designed to multiplex requests fromremote applications, providing them access to the OBU. This standard specifies the WAVE applicati
39、on known as the resource manager (RM), which resides on, forexample, the RSU, and its peer known as the resource command processor (RCP), which resides on theOBU. Remote from the RSU, the other applications, known as resource manager applications (RMAs),communicate with the RCP through the RM. This
40、standard describes how the RM multiplexes requests frommultiple RMAs, each of which is communicating with multiple OBUs hosting an RCP. The purpose of thecommunication is to provide the RMAs access to “resources,” such as memory, user interfaces (UIs), andinterfaces to other onboard equipment contro
41、lled by the RCP, in a consistent, interoperable, and timelymanner to meet the requirements of RMAs.The RM uses the concept of all of the communication being initiated from an entity known as a provider,which issues requests to an entity known as a user, which responds only to requests that it receiv
42、es. Withinthis standard, the RM is the provider of a service (as a representative of the RMAs), and RCP the user of aservice (representing the resources to be managed). Either the RSU or OBU can operate as the provider; inother words, either device type can host the RM. The device, either RSU or OBU
43、 that is hosting the RM willbe referred to as the provider device.1.1 ScopeThe scope of this standard is to specify the services and interfaces of the WAVE RM, including protectivemechanisms for security and privacy, applicable and available to all users of DSRC and WAVE modeIEEEStd 1609.1-2006 IEE
44、E TRIAL-USE STANDARD FOR WIRELESS ACCESS IN2 Copyright 2006 IEEE. All rights reserved.operations in the 5.9 GHz band authorized by the Federal Communication Commission (FCC) for intelligenttransportation systems (ITS). NOTEThis version of the standard does not specify explicitly the details of the s
45、ecurity interface. Security provisionsare in IEEE Std 1609.2.1, 21.2 PurposeThe purpose of this standard is to enable complete interoperability of applications using WAVE in a mannerthat simplifies the onboard vehicle systems, reducing cost and improving performance. Effective use of thememory pages
46、 by applications can also minimize configuration management issues over the life of a system.This standard is intended to enable a wide range of applications to be supported by an OBU of the lowestpossible cost. The low cost is enabled by removing the need for the OBU to interpret application messag
47、es.There is no OBU software representing applications using RM; thus the processing, memory, andconfiguration management requirements are removed from the OBU. Instead of putting such processingrequirements on the OBU, they are placed on the RSU or an application processor remote from the RSU.The on
48、ly processing requirement is that of interpreting the specific commands and message headers definedherein, which is application independent. The OBU merely serves as a mobile mailbox to carry applicationmessages and data from one RSU to another or as a common interface point to transfer data to othe
49、r onboardsystems.By allowing memory to be assigned to an application at any time during the life of the OBU, futureapplications can be developed and deployed without onboard hardware or software modification. For applications using RM as a mobile mailbox, with no onboard use of the data stored in memory, there aresignificant security advantages. By having the OBU treat each applications messages as a bit-stream to besaved and later retrieved from memory, such data can be encrypted in a manner that is not known to theOBU. There is no need for the OBU to su
