8.7.1 Generality
The IC-card card will hold several products, but only one may be useful at any validation. To process the card rapidly during validation, the choice of the product to use must be easy and must not need any customer interaction. For this, a simple rule understandable by customers must be defined.
In all cases, priority is given to current journey as long as it is active : validation inside the geographical validity domain and before transfer time is reached, is by default a transfer validation (free interchange); traveller may override this choice and buy a connection ticket, which anyway will take any period pass product in account (extension).
The connection to an unused slicing period travel is forbidden.
8.7.2 Automatic and explicit selection Automatic selection :
If after applying the rules defined above there is no product stored on smart the card that apply, then, if automatic (implicit) journey purchase (using 'Stored Value') applies, this automatic ticket is then sold and used.
Explicit selection :
Selection for immediate use is proceeded by a vending or dedicated machine, which writes down to the card a Travel Right pointing to the specified product. Explicit selection is when the product is sold and marked for immediate usage; this product by-passes the usual priority rules and is used in any cases.
8.7.3 Priority Processing at validation
The priority processing at CAD (for validation process) is based on the following criteria :
• contract list information which tells
• if the contract is already in use or not,
• which is the contract priority (may be defined by the user)
• detailed information checked from the contracts
• Temporal validity (start date / Time, end date / time, period right to travel)
• Geographical validity (start point, stop points, start zone, destination zone…) for more details, refer to section 9.3.4.5 "Contract list structure description"
8.7.4 Priority processing at point of sale
Several products may be present on a card at the same time. Conflicts that may happen between them are not managed by validators (transaction time optimisation) and have to be avoided when products are sold.
To make conflict management understandable by customers, following rules must apply :
• It is not be possible to put more than two period pass of same type except if :
• The product is flexible product. In this case, the second will be valid after the first.
• Date of start of validity of product is after date of end of validity of first product.
• It is not possible to put more than one limited period pass except if it is the same type with precedent restriction.
• It is not possible to put more than one unlimited period pass for the same product owner if there is more than one not used.
• If a customer wants to have an unlimited period pass which begins after another one, a date of start of validity must be given.
• It is not possible to put more than one single ticket except for immediate use and except for automatic 'Stored Value' single tickets. If there is more than one person who want to travel, they must be all registered in the same single ticket.
Case example with more than one product:
A customer has a NSB monthly period pass and an OS daily pass.
• When validating in OS bus in OS domain, OS daily pass will be used.
• When validating in SL bus in OS domain, OS daily pass will be used.
• When validating in NSB train in OS domain, NSB monthly pass will be used.
• When validating in NSB train in NSB domain, NSB monthly pass will be used.
8.7.5 Action list usage and rules (Tele renew)
To be written.
8.7.6 Removal of a product
This paragraph shows when a product can be removed from the card.
Note that a contract can be cancelled when :
• Product has been used and product end of validity has been reached.
• Product has never been used and maximum date for refund is reached (end of version validity more than 1 year).
• Product has never been used, product end of validity has been reached and product is not refundable.
• Product has never been used, maximum date for validation has been reached (end of version validity is more than 3 months) and product is not refundable.
In other cases, product cannot be cancelled from the card.
If an equipment doesn’t have the description of the product in his parameter tables, it cannot remove the product.
This test will be made :
• At each sale operation for all the products.
• At each use of this product.
9 NORTIC SPECIFICATION FOR DES FIRE FILE STRUCTURE
This chapter describes the file structure and content for the directories and files to be implemented on the NDS DESFire cards.
[R 117] The NDS DESFire IC-card shall enable the implementation of the following directories:
• MF (Masterfile)
• CardIssuerDF (directory used by card issuer at the time of card initialisation)
• TransportDF (directory used for storage of data elements required for local, regional and inter-regional interoperable fare management)
• NorticDF (directory used for storage of data elements for the national interoperable product NORTIC TravelContract)
The free memory left may be used to host additional applications/directories in the future.
The following table gives the card file breakdown structure.
Each directory is highlighted in grey. Each 'file' is given a name, a type and record(s). The record content column relates, either to key content or data element structures.
Note that the Master file stands for the PICC itself.
Application
# Directory/File name Type Record* : contents Described in
MF (Master File) DF 9.1
0x000000
PICC Master Key key ³ Keys (M)
CardIssuerDF DF 9.2
CI_Keys key ³ Keys (4 keys)
0x578000 (hexadeci mal)
CI_Header standard CardHeader 9.2.1
TransportDF DF 9.3
T_Keys key ³ Keys (7 keys)
T_Environment standard Environment 0
T_CardHolder standard Holder 9.3.2
T_ProductRetailer backup Contract [1..8] 9.3.3 Counter [1..8] 9.3.4.1 ContextsAndSequenceNumbers 9.3.4.3 T_ServiceProvider backup
ContractList 9.3.4.5
SpecialEventLog [1..8] 9.3.5.1.1 T_SpecialEvent backup
SpecialEventList 9.3.5.1.2
T_StoredValue value StoredValue 9.3.6
0x578001 (hexadecimal)
T_GeneralEventLog cyclic GeneralEventLog [1..8] 9.3.7
Application
# Directory/File name Type Record* : contents Described in T_SVReloadLog cyclic StoredValueReloadLog [1..2] 9.3.8
NorticDF DF 9.2
Nortic_Keys key ³ Keys (x keys) t.b.d
t.b.d
t.b.d (hexadecimal)
Table 5 NSD DESFire data layout Notation :
In the following sections, each record is described using 2 descriptions :
• detailed encoding : these tables give all the necessary details related to the data elements, sizes, data types and initials values. To be noted that the dot at the left part of each field means "mandatory" and the numbers identifies the optional number according to the presence bitmap indicator.
• ASN.1 representation which uses the PER encoding / bit aligned. When conflicting, ASN.1 prevails.
• Fields marked as "unused" will be ignored by the CAD Software
The structure follows the recommendations in ENV-1545 as closely as possible. Structures or fields that are specific for the NDS – either in that it does not exist in ENV-1545 or because it is used differently – is prefixed with “IO” – IO stands for “Interoperability Organisation”.
NOTE: The prefix IO should be discussed and finally defined enabling a more general prefix than the one used in the Oslo projects where the tasks of the Application Owner, Registrar, Security Manager and Collection and Forwarding operator are allocated to the Interoperable Organisation.