EN 15509:2007

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Road transport and traffic telematics - Electronic fee collection - Interoperability application profile for DSRCCestna transportna in prometna telematika - Elektronsko pobiranje pristojbin - Medobratovalnost profila aplikacije za DSRCTélématique de la circulation et du transport routier - Perception de télépéage - Profil d'application d'interopérabilité pour DSRCStraßenverkehrstelematik - Elektronische Gebührenerhebung - Anwendungsprofil für DSRC InteroperabilitätTa slovenski standard je istoveten z:EN 15509:2007SIST EN 15509:2008en35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and trade03.220.20Cestni transportRoad transportICS:SLOVENSKI
STANDARDSIST EN 15509:200801-februar-2008

EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 15509May 2007ICS 35.240.60 English VersionRoad transport and traffic telematics - Electronic fee collection -Interoperability application profile for DSRCTélématique de la circulation et du transport routier -Perception de télépéage - Profil d'applicationd'interopérabilité pour DSRCStraßenverkehrstelematik - ElektronischeGebührenerhebung - Anwendungsprofil für DSRCInteroperabilitätThis European Standard was approved by CEN on 22 March 2007.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the CEN Management Centre or to any CEN member.This European Standard exists in three official versions (English, French, German). A version in any other language made by translationunder the responsibility of a CEN member into its own language and notified to the CEN Management Centre has the same status as theofficial versions.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2007 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 15509:2007: E

Data specification.22 Annex B (normative)
Security calculations.26 B.1 General.26 B.2 Attribute authenticator.26 B.2.1 General.26 B.2.2 Authenticator using the attribute Payment Means.28 B.3 Access Credentials.29 B.3.1 General.29 B.3.2 The principle of Access Credentials.29 B.3.3 Calculation of Access Credentials.29 B.4 Key derivation.30 B.4.1 General.30 B.4.2 Calculation of derived Authentication Key.30 B.4.3 Calculation of the Access Key.31 B.5 Transaction Counter.31 Annex C (normative)
ICS proforma.32 C.1 General.32 C.2 Guidance for completing the ICS proforma.32 C.2.1 Purposes and structure.32 C.2.2 Abbreviations and conventions.32 C.3 Instructions for completing the ICS proforma.34 C.4 ICS proforma for OBU.35 C.4.1 Identification implementation.35 C.4.2 Identification of the standard.35 C.4.3 Global statement of conformance.35 C.4.4 ICS proforma for OBU.36

IAP taxonomy and numbering.47 D.1 General.47 D.2 Contents of an Interoperable Application Profile (IAP).47 D.3 IAP referencing and numbering.48 D.3.1 IAP numbering.48 D.3.2 Security levels numbering.48 D.3.3 Numbering and referencing examples.48 Annex E (informative)
Security computation examples.49 E.1 General.49 E.2 Computation of Attribute Authenticator.49 E.3 Computation of Access Credentials.50 E.4 Key derivation.51 E.4.1 Authenticator Key.51 E.4.2 Access Credentials Key.51 Annex F (informative)
Security considerations.53 Annex G (informative)
Inter layer management.55 G.1 General.55 G.2 RSE Inter Layer Management guidelines.55 G.3 OBU Inter Layer Management guidelines.55 G.4 State Transition Tables.56 Annex H (informative)
Vehicle classification data.61 Annex I (informative)
Using this European Standard for other DSRC-based transactions.62 Annex J (informative)
Mounting guidelines for the OBU.63 J.1 General.63 J.2 OBU mounting position.63 J.3 OBU minimum active angle.63 Bibliography.65

CEN/ISO TS 17573. This European Standard only defines a basic level of technical interoperability for EFC equipment, i.e. on-board unit (OBU) and roadside equipment (RSE) using DSRC. It does not provide a full solution for interoperability, and it does not define other parts of the EFC-system, other services, other technologies and non-technical elements of interoperability. The elaboration of this European Standard is based on the experiences from a vast number of implementations and projects throughout Europe. The standard makes use of the results from European projects such as CARDME, PISTA and CESARE, as they represent the fruit of European EFC harmonisation and have been used as the basis for several national implementations. The development of a common European Electronic Toll Service (EETS) as a part of the European EFC Directive (2004/52/EC) also calls for the definition of an interoperable EFC-service. This European Standard provides for effective support for the work on the definition of EETS. Although there already are numerous existing base standards and specifications, there are specific needs that motivate this Interoperable Application Profile standard.  Definition of the necessary and sufficient EFC-DSRC requirements to support technical interoperability.  Provision of a crucial part of the EETS and hence support for the EFC Directive (2004/52/EC). Including structured management of revisions of the standard.  CARDME/PISTA/CESARE dialects are used in many countries but they need to converge, as the present situation is not cost effective.  Needed additional DSRC-requirements are made.  Choice of data elements including vehicle data.  Extended definition of the use of some data elements, including semantics and coding.  Clear choices for security implementation.  It facilitates a complementing test specification (with clear relations between the conformance requirements and evaluation tests).  Good support for procurements.
The Application Profile is described using the concept of "International Standardised Profiles (ISP)" as defined in ISO/IEC TR 10000-1. The ISP-concept is specifically suited for defining interoperability specifications where

On Board Unit(OBU)Road SideEquipment(RSE)Central System(at Toll Charger)Central System(at OBU Provider)Personalisation &initialisation link(Any link)DSRC-link(Any link)Scope for this standard (dotted line)

APRSEApplication functionsand dataSecurity algorithms
DSRC L7RequestfunctionsDSRC
L2 LLCDSRC L2 MACDownlinkframes
DSRC L1DSRC L1Parameters
APOBUApplication functionsand dataSecurity algorithms
DSRC L7ResponsefunctionsDSRC L2 LLCDSRC L2 MACUplinkframes
DSRC L1DSRC L1Parameters Figure 2 — Relations between this European Standard and DSRC-stack elements
This European Standard defines an Application Profile based on the ISP-concept. The base standards that this Application Profile is based upon are:  EN ISO 14906 on EFC application interface definition for DSRC (this implies indirect references to
EN ISO 14816 on Numbering and data structures);  EN 12834: on DSRC application layer (L7).  EN 13372 on DSRC profiles (this implies indirect references to the DSRC L1, L2 and L7 standards:
EN 12253, EN 12795 and EN 12834).

[EN ISO 14906:2004] NOTE The access credentials carry information needed to fulfil access conditions in order to perform the operation on the addressed element in the OBE. The access credentials can carry passwords as well as cryptographic based information such as authenticators. 3.2 action function that an application process resident at the roadside equipment can invoke in order to make the on-board equipment execute a specific operation during the transaction
[EN ISO 14906:2004]
[EN ISO 14906:2004] 3.4 authenticator data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and/or the integrity of the data unit and protect against forgery
[EN ISO 14906:2004] 3.5 base standard an approved international standard or ITU-T Recommendation
[ISO/IEC TR 10000:1998] 3.6 channel information transfer path
[EN ISO/IEC 7498-2 and EN ISO 14906:2004] 3.7 component logical and physical entity composing an on-board equipment, supporting a specific functionality
[EN ISO 14906:2004] 3.8 contract expression of an agreement between two or more parties concerning the use of the road infrastructure
[EN ISO 14906:2004] 3.9 cryptography discipline which embodies principles, means, and methods for the transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorised use
[EN ISO 14906:2004] 3.10 data group collection of closely related EFC data attributes which together describe a distinct part of an EFC transaction
[EN ISO 14906:2004] 3.11 data integrity property that data has not been altered or destroyed in an unauthorised manner
[EN ISO 14906:2004]
[EN ISO 14906:2004] 3.13 International Standardised Profile an internationally agreed-to, harmonised document which describes one or more profiles
[ISO/IEC TR 10000:1998] 3.14 interoperability the ability of two or more IT systems to exchange information and to make mutual use of the information that has been exchanged [ISO/IEC TR 10000:1998] 3.15 issuer entity responsible for the payment system and responsible for issuing the Payment Means to the User
[CEN ISO/TS 17573:2003] 3.16 on-board equipment equipment located within the vehicle and supporting the information exchange with the roadside equipment. It is composed of the on-board unit and other sub-units whose presence have to be considered optional for the execution of a transaction
[EN ISO 14906:2004] 3.17 on-board unit minimum component of an on-board equipment, whose functionality always includes at least the support of the DSRC interface
[EN ISO 14906:2004] 3.18 profile a set of one or more base standards and/or ISP, and where applicable, the identification of chosen classes, conforming subsets, options and parameters of those base standards, or ISPs necessary to accomplish a particular function [ISO/IEC TR 10000:1998] 3.19 roadside equipment equipment located at a fixed position along the road transport network, for the purpose of communication and data exchanges with the on-board equipment of passing vehicles
[EN ISO 14906:2004]
[EN ISO 14906:2004] 3.21 service primitive (communication) elementary communication service provided by the Application layer protocol to the application processes
[EN ISO 14906:2004] NOTE The invocation of a service primitive by an application process implicitly calls upon and uses services offered by the lower protocol layers. 3.22 service provider (EFC) operator that accepts the user's payment means and in return provides a road-use service to the user
[EN ISO 14906:2004] 3.23 session exchange of information and interaction occurring at a specific EFC station between the roadside equipment and the user/vehicle
[EN ISO 14906:2004] 3.24 transaction whole of the exchange of information between the roadside equipment and the on-board equipment necessary for the completion of an EFC operation over the DSRC
[EN ISO 14906:2004] 3.25 transaction counter data value in the on-board unit that is incremented by the roadside equipment at each transaction 3.26 transaction model functional model describing the general structure of Electronic Payment Fee Collection transactions
[EN ISO 14906:2004] 3.27 transport service provider person, company, authority or abstract entity offering a transport service to the User for which the user has to pay a fee (the fee will in some cases be zero, e.g. emergency vehicles)
[CEN ISO/TS 17573:2003] 3.28 user entity that uses transport services provided by the service provider according to the terms of a contract

Transfer-Application Protocol Data Unit [EN ISO 14906:2004]

DSRC Profiles P0 / P1 L1-A according to EN 13372 with a Conversion Gain which is limited to a maximum value of 10 dB (Parameter U12b = 10dB) and a Cut-off power level of minimum -60 dBm (Parameter D12 = -60 dBm). NOTE This implies that the OBU shall comply with the underlying DSRC-standards for L1, L2 and L7
[EN 12253, EN 12795 and EN 12834]. The following DSRC-L7 according to EN 12834 features shall be supported by the OBU:  concatenation of multiple consecutive T-APDU fragments in one layer 2 frame (i.e. LLC-service) with and without chaining, given that the size constraint for the LLC-frames are not violated (i.e. fit into 1 L2 frame);  fragmentation header limited to 1 octet only;  any “fill bit” (as defined 6.3.4 in EN L7), used for octet alignment, shall be assigned the value zero. 5.1.3 DSRC L7 and EFC functions The OBU shall support the DSRC Layer 7 services and EFC functions, defined in EN 12834 and EN ISO 14906:2004, 7.2, in Table 1.

GET N/A N/A Retrieves data from the OBU, with or without AC-CR SET N/A N/A Writes data to the OBU, with or without AC-CR ACTION SET_MMI 10 Invokes an MMI function (e.g. signal "OK" via buzzer). All SetMMIRq values (i.e. 0, 1, 2 and 255) defined in Annex A of EN ISO 14906:2004 shall be supported ACTION ECHO 15 OBU echoes received data EVENT-REPORT RELEASE 0 Terminates communication
5.1.4 Data requirements The addressing of the EFC system and application data shall conform to the rules defined in 5.3 in
EN ISO 14906:2004. The EFC attributes in Table 2 as defined in EN ISO 14906:2004 (in Clause 8 and Annex A) and in
EN 12834, shall be implemented in the OBU:

ATTRIBUTES (EID>0) AttrId Type Length a (in octets)Read b Write b Remarks APPLICATION CONTEXT
This attribute is defined in EN 12834.
ApplicationContextMark N/A N/A 6 or 16 Yes No An octet string that is sent from the OBU in the Initialisation phase (VST) that contains the identification of a specific DSRC application context. For EFC the first 6 octets always will contain the EFCContextMark. Length varies between security levels (see Annex A for details). CONTRACT
Information associated with the service rights of the issuer of the EFC service.
EFC Context Mark 0 32 6 Yes No Contains the Contract Provider. Transmitted as part of the VST. PAYMENT
Data associated with the Payment transaction.
PaymentMeans (including PAN) 32 64 14 Yes No Includes: - The Personal Account Number, including the Payment Means Issuer. - The PAN Expiry Date - The payment means Usage Control VEHICLE
Information pertaining to the identification and characteristics of the vehicle.
VehicleLicencePlateNumber 16 47 17 Yes No More specific and limited in scope than in
EN ISO 14906
VehicleClass 17 49 1 Yes No More specific and limited in scope than in
EN ISO 14906
VehicleDimensions 18 50 3 Yes No
VehicleAxles 19 51 2 Yes No
VehicleWeightLimits 20 52 6 Yes No
VehicleSpecificCharacteristics 22 54 4 Yes No
EQUIPMENT
Information pertaining to the OBU.
EquipmentOBUId 24 56 5 (=1+4) Yes No
EquipmentStatus (transaction counter) 26 58 2 Yes Yes More specific and limited in scope than in
EN ISO 14906 RECEIPT
Information associated with a specific session, including both financial and operational data.
ReceiptData1 (last) 33 65 28 Yes Yes
ReceiptData2 (penultimate) 34 66 28 Yes Yes
a Including the length determinant as defined in ISO/IEC 8825-2 (packed encoding rules for ASN.1 is used in EN ISO 14906).
b The read and write columns denotes read and write operations in an EFC DSRC transaction (not other possible situations)
EFC attribute requirements that restrict choices of or which are more specific and limited in scope than those of EN ISO 14906 can be found in Annex A. 5.1.5 Security requirements 5.1.5.1 General This European Standard defines security features and mechanisms based on the general security framework defined in 7.1.4 in EN ISO 14906:2004. This European Standard allows for implementation of two different levels of security (0,1). Support of security level 0 is mandatory whereas level 1 can be implemented on an optional basis. NOTE See Annex D for further details and explanation. 5.1.5.2 Security level 0 requirements The security related data elements listed in Table 3, shall be implemented in the OBU:

RndRSE 5 = 1+4 Random number, containing SessionTime, from RSE used for the computation of Authenticator.
The OBU shall be able to calculate an Authenticator (i.e. support the GET_STAMPED function operating on one attribute list considering that the response shall fit into one Layer 2 frame) to validate data integrity and origin of the application data. These calculations shall be performed according to B.2. NOTE
The OBU also supports (through the data stored in the OBU) other security features such as the TransactionCounter (see B.5) and signed receipt that are performed at the RSE or in the central system. 5.1.5.3 Security level 1 requirements The OBU shall support the security level 0 requirements as defined in 5.1.5.2. The OBU shall support calculation of Access Credentials for protection of user related data on the OBU. These calculations shall be performed according to B.3. This requires the additional security data elements, in Table 4, to be implemented in the OBU. Table 4 — OBU security related data for handling of Access Credentials Name Length (in octets)Remarks AccessKey 8 Private. AC_CR 1+4 Access credentials calculated by the RSE and the OBU using RndOBU and the Access Key AC_CRKey. AC_CR-KeyReference 2 Reference to the key generation and the Diversifier for the computation of AC_CRKey. RndOBU 5 = 1+4 Random number (nonce) used together with AccessKey (referenced through AC_CR-KeyReference) to calculate the Access credentials.
NOTE Operators should be aware that that any RSE that has only implemented the security requirements associated with level 0 in this European Standard (as in 5.2.5.2) will not be able to access OBU data protected by means of access credentials.

Clause 6 in EN ISO 14906:2004. Annex B in EN ISO 14906:2004 provides an informative example of a transaction by specifying the CARDME transaction. 5.2 RSE requirements 5.2.1 General This subclause contains the normative conformance requirements on the Roadside Equipment (RSE). 5.2.2 DSRC requirements The RSE shall support any OBU complying with 5.1.2. NOTE This implies that the RSE needs to comply with the DSRC-standards for Profiles, L1, L2 and L7
[EN 13372, EN 12253, EN 12795 and EN 12834]. 5.2.3 DSRC L7 and EFC functions The RSE shall support the DSRC Layer 7 services and EFC functions, defined in EN 12834 and EN ISO 14906:2004, 7.2, in Table 5. Table 5 — Overview of DSRC L7 and EFC functions DSRC-L7 services EFC function Action/ Event type Remarks INITIALISATION N/A N/A Establishes communication, selects the application and contract ACTION GET_STAMPED 0 Retrieves data with an authenticator from the OBU, with or without AC-CR
GET N/A N/A Retrieves data from the OBU, with or without AC-CR
SET N/A N/A Writes data to the OBU, with or without AC-CR
ACTION SET_MMI 10 Invokes an MMI function (e.g. signal "OK" via buzzer). All SetMMIRq values (i.e. 0, 1, 2 and 255) defined in Annex A of EN ISO 14906:2004 shall be supported. ACTION ECHO 15 OBU echoes received data EVENT-REPORT RELEASE 0 Terminates communication
5.2.4 Data requirements The RSE shall support any OBU complying with 5.1.4. There are no specific data requirements for the RSE, other than the possibility to retrieve read and write (including decoding and encoding, respectively) data as defined in 5.1.4.

An informative example of a transaction can be found in EN ISO 14906:2004, Annex B.

Data specification The specification and use of data elements is defined in EN 14906 and in EN 12834. This annex includes EFC attribute and security related data requirements that restrict choices of or which are more specific and limited in scope than those of base standards. NOTE Some data elements are subject t
...