SIST EN 12834:2004
(Main)Road transport and traffic telematics - Dedicated Short Range Communication (DSRC) - DSRC application layer
Road transport and traffic telematics - Dedicated Short Range Communication (DSRC) - DSRC application layer
This European Standard specifies the Application Layer Core which provides communication tools for applications
based on DSRC. These tools consist of Kernels that can be used by application processes via service primitives.
The application processes, including application data and application specific functions, are outside the scope of
this European Standard.
The standard is named 'Application Layer' although
- it does not cover all functionality of OSI Layer 7 and
- it includes functionality from lower layers.
This European Standard uses services provided by DSRC Data Link Layer, [EN 12795], and covers functionality of
intermediate layers of the OSI Basic Reference Model [EN ISO/IEC 7498-1].
Figure 1 illustrates the global data flow between the parts of the DSRC stack (Physical, Data Link and Application
Layers) and the application.
The following subjects are covered by this European Standard:
- application Layer structure and framework;
- services to enable data transfer and remote operations;
- application multiplexing procedure;
- fragmentation procedure;
- concatenation and Chaining procedures;
- common encoding rules to translate data from abstract syntax ASN.1, [ISO/IEC 8824-1], into transfer syntax,
[ISO/IEC 8825-2], and vice versa;
- communication initialisation and release procedures;
- broadcast service support;
- DSRC management support including communication profile handling.
It is outside the scope of this European Standard to define a security policy. Some transport mechanisms for
security related data are provided.
NOTE During the lifetime of ENV 12834:1997, no implementation of the Broadcast Pool functionality has become known.
Broadcast Pool functionality is therefore considered untested and is kept in this European Standard for compatibility with the
ENV only.
Straßenverkehrstelematik - Nahbereichskommunikation Fahrzeug-Bake (DSRC) - Anwendungsschicht
Télématique de la circulation et du transport routier - Communication a courte portée - Couche applicative
Cestna transportna in prometna telematika (RTTT) – Posebna komunikacija kratkega dosega (DSRC) – Aplikacijska plast DSRC
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Cestna transportna in prometna telematika (RTTT) – Posebna komunikacija kratkega dosega (DSRC) –
Aplikacijska plast DSRCStraßenverkehrstelematik - Nahbereichskommunikation Fahrzeug-Bake (DSRC) - AnwendungsschichtTélématique de la circulation et du transport routier - Communication a courte portée - Couche applicativeRoad transport and traffic telematics - Dedicated Short Range Communication (DSRC) - DSRC application layer35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and trade35.100.70Uporabniški slojApplication layerICS:Ta slovenski standard je istoveten z:EN 12834:2003SIST EN 12834:2004en01-maj-2004SIST EN 12834:2004SLOVENSKI
STANDARDSIST ENV 12834:20031DGRPHãþD
SIST EN 12834:2004
EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 12834November 2003ICS 35.100.70; 35.240.60English versionRoad transport and traffic telematics - Dedicated Short RangeCommunication (DSRC) - DSRC application layerTélématique de la circulation et du transport routier -Communication à courte portée - Couche applicativeStraßenverkehrstelematik - NahbereichskommunikationFahrzeug-Bake (DSRC) - AnwendungsschichtThis European Standard was approved by CEN on 4 December 2002.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 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 Management Centre has the same status as the officialversions.CEN members are the national standards bodies of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece,Hungary, Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway, Portugal, Slovakia, Spain, Sweden, Switzerland and UnitedKingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2003 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 12834:2003 ESIST EN 12834:2004
EN 12834:2003 (E)2ContentspageForeword.31Scope.42Normative references.63Terms and definitions.64Abbreviations.85Structure of the application layer core.106Transfer-kernel.116.1General.116.2Services.116.3Behaviour.167Initialisation-kernel.247.1General.247.2Services.247.3Behaviour.278Broadcast-kernel.338.1General.338.2Services.338.3Behaviour.34Annex A
(normative)
Data structures.36A.1Use of modules.36A.2ASN.1-modules.36Annex B
(normative)
Naming and registration.41B.1General.41B.2Items for registration.41B.3Items defined by application standards.41Annex C
(informative)
Example.42Annex D
(informative)
A-deviations.44SIST EN 12834:2004
EN 12834:2003 (E)3ForewordThis document (EN 12834:2003) has been prepared by Technical Committee CEN TC 278 “Road Transport andTraffic Telematics”, the secretariat of which is held by NEN.This European Standard shall be given the status of a national standard, either by publication of an identical text orby endorsement, at the latest by May 2004, and conflicting national standards shall be withdrawn at the latest byMay 2004.This document supersedes ENV 12834:1997.The development of this European Standard was carried out under European Commission Mandate M/018.This European Standard forms part of a series of European Standards defining the framework of a DedicatedShort-Range Communication (DSRC) link in the Road Transport and Traffic Telematics (RTTT) environment.The communication requirements of many RTTT applications can be fulfilled by DSRC. The DSRC standardsenable compliant communication systems to serve multiple RTTT applications in parallel.The small service areas and severe real-time constraints require a specific protocol architecture leading to thereduced protocol stack shown in Figure A, built up by the Application Layer, the Data Link Layer, and the PhysicalLayer. Such an architecture is very common for real-time environments.This European Standard gives the architecture and services offered by the DSRC Application Layer.Figure A — DSRC protocol stackThe following set of European Standards for the DSRC link is issued by CEN:— EN 12253 "DSRC Physical Layer using Microwave at 5,8 GHz”;— EN 12795 “DSRC Data Link Layer: MAC and LLC”;— EN 12834 "DSRC Application Layer" (this European Standard);— prEN 13372 "DSRC Profiles for RTTT Applications".Annexes A and B are normative. Annexes C and D are informative.According to the CEN/CENELEC Internal Regulations, the national standards organizations of the followingcountries are bound to implement this European Standard: Austria, Belgium, Czech Republic, Denmark, Finland,France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway, Portugal,Slovakia, Spain, Sweden, Switzerland and the United Kingdom.SIST EN 12834:2004
EN 12834:2003 (E)41 ScopeThis European Standard specifies the Application Layer Core which provides communication tools for applicationsbased on DSRC. These tools consist of Kernels that can be used by application processes via service primitives.The application processes, including application data and application specific functions, are outside the scope ofthis European Standard.The standard is named “Application Layer” although— it does not cover all functionality of OSI Layer 7 and— it includes functionality from lower layers.This European Standard uses services provided by DSRC Data Link Layer, [EN 12795], and covers functionality ofintermediate layers of the OSI Basic Reference Model [EN ISO/IEC 7498-1].Figure 1 illustrates the global data flow between the parts of the DSRC stack (Physical, Data Link and ApplicationLayers) and the application.Figure 1 — Architecture and data flow of the DSRC stackNOTEFor definitions of the terms used in Figure 1 see [EN ISO/IEC 7498-1].SIST EN 12834:2004
EN 12834:2003 (E)5The following subjects are covered by this European Standard:— application Layer structure and framework;— services to enable data transfer and remote operations;— application multiplexing procedure;— fragmentation procedure;— concatenation and Chaining procedures;— common encoding rules to translate data from abstract syntax ASN.1, [ISO/IEC 8824-1], into transfer syntax,[ISO/IEC 8825-2], and vice versa;— communication initialisation and release procedures;— broadcast service support;— DSRC management support including communication profile handling.It is outside the scope of this European Standard to define a security policy. Some transport mechanisms forsecurity related data are provided.NOTEDuring the lifetime of ENV 12834:1997, no implementation of the Broadcast Pool functionality has become known.Broadcast Pool functionality is therefore considered untested and is kept in this European Standard for compatibility with theENV only.SIST EN 12834:2004
EN 12834:2003 (E)62 Normative referencesThis European Standard incorporates by dated or undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text, and the publications are listed hereafter. Fordated references, subsequent amendments to or revisions of any of these publications apply to this EuropeanStandard only when incorporated in it by amendment or revision. For undated references the latest edition of thepublication referred to applies (including amendments).ISO/IEC 8824-1:2000, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basicnotation.ISO/IEC 8825-2:2000, Information technology - ASN.1 encoding
rules: Specification of Packed EncodingRules (PER).EN ISO/IEC 7498-1, Information technology - Open Systems Interconnection - Basic Reference Model: TheBasic Model (ISO/IEC 7498-1).EN 12795, Road Transport and Traffic Telematics (RTTT) - Dedicated Short Range Communication (DSRC) -DSRC Data Link Layer: Medium Access and Logical Link Control.prEN 13372, Road Transport and Traffic Telematics (RTTT) - Dedicated Short-Range Communication (DSRC)- DSRC Profiles for RTTT Applications.ENV ISO 14906, Road Transport and Traffic Telematics (RTTT) - Electronic Fee Collection (EFC) -Application interface definition for dedicated short range communications (ISO/TR 14906:1998).ENV ISO 14816, Road Traffic and Transport Telematics - Automatic vehicle and equipment identification -Numbering and data structures (ISO/TR 14816:2000).3 Terms and definitionsFor the purpose of this European Standard, the following terms and definitions apply.3.1applicationuser of the services offered by the DSRC communication stack3.2attributetakes a value, which may have a structure, consisting of a set or sequence of data elementsNOTEThe value of an attribute can be observed or modified by sending a request to GET (read) or SET (write) the value.3.3attribute identifierunambiguously distinguishes an attribute from all other attributes within the same element3.4Beacon service tabledata structure transmitted by the RSU indicating available services3.5broadcast pooldata structure broadcast from the RSU to the OBUsSIST EN 12834:2004
EN 12834:2003 (E)73.6chainingfunction performed by the Transfer Kernel to link the execution of service primitives together3.7concatenationfunction performed by the Transfer Kernel to map multiple Application Layer Protocol Data Units or ApplicationLayer Protocol Data Layer Fragments into one Data Link Layer Service Data Unit3.8elementcoherent set of data and functionality. Application Elements are created by the Applications and are addressedusing Element Identifiers3.9element identifierunambiguously distinguishes an element from all other elements residing in the same OBU3.10fragmentationfunction performed by the Transfer Kernel to map one ASDU on multiple LSDUs3.11head of the linequeuing discipline (also referred to as strict or fixed priority queuing), where a number of queues are served inpriority order. A lower priority queue is served if all higher priority queues are empty, each queue is served in First-Come-First-Serve order, each user goes head of the line of the users of lower priorities but behind all users ofequal or higher priority3.12managementprovides and distributes values for the communication parameters for controlling the DSRC Communication stack3.13multiplexingfunction within the Transfer Kernel allowing simultaneous support for more than one Application in a single OBU3.14operationabstract representation of behaviour invoked in an entity3.15profileinformation about capabilities and settings in the different DSRC layers3.16timenumber of seconds passed since 1st January 1970, 00:00 (UTC)NOTEThis format is also known as ‘UNIX time’.3.17vehicle service tabledata structure transmitted by the OBU indicating available servicesSIST EN 12834:2004
EN 12834:2003 (E)84 AbbreviationsFor the purpose of this European Standard, the following abbreviations apply.4.1AIDApplication Identifier4.2APDUApplication Protocol Data Unit4.3ASDUApplication Service Data Unit4.4ASN.1Abstract Syntax Notation One[ISO/IEC 8824-1:2000]4.5B-KernelBroadcast Kernel4.6BSTBeacon Service Table4.7DSRCDedicated Short Range Communication4.8EFCElectronic Fee Collection4.9EIDElement Identifier4.10IDIdentifier4.11IIDInvoker Identifier4.12I-KernelInitialisation KernelSIST EN 12834:2004
EN 12834:2003 (E)94.13LIDLogical Link Control Identifier4.14LLCLogical Link Control4.15LPDULLC Protocol Data Unit4.16LSDULLC Service Data Unit4.17L1Layer 1 of DSRC (Physical Layer)4.18L2Layer 2 of DSRC (Data Link Layer)4.19L7Application Layer Core of DSRC4.20NENNederlands Normalisatie-instituut (see http://www.nen.nl/cen278)4.21OBUOn Board UnitNOTEEquipment usually residing on board a vehicle.4.22PDUProtocol Data Unit4.23PERPacked Encoding Rules[ISO/IEC 8825-2:2000]4.24RSURoad Side UnitNOTEOften referred to as beacon.4.25RTTTRoad Transport and Traffic TelematicsSIST EN 12834:2004
EN 12834:2003 (E)104.26T-APDUTransfer Application Protocol Data Unit4.27T-KernelTransfer Kernel4.28VSTVehicle Service Table5 Structure of the application layer coreThe application layer core shall consist of the Transfer Kernel (T-Kernel) and either the Initialisation Kernel (I-Kernel) or the Broadcast Kernel (B-Kernel), or both.Figure 2 shows the application layer kernels and the relationships to external entities.
The T-Kernel provides thebasic transportation facilities that can be used by the I-Kernel, by the B-Kernel, and by the applications.Figure 2 — Context and structure of the application layer coreSIST EN 12834:2004
EN 12834:2003 (E)116 Transfer-kernel6.1 GeneralThe T-Kernel shall transfer information between two peer kernels or applications, and shall abstract from therealisation of this transfer.The T-Kernel shall offer its services by means of service primitives defined in 6.2.The T-Kernel shall transfer the information by means of T-APDUs defined in annex A.The T-Kernel shall realise the transfer by a protocol with the behaviour defined in 6.3.The T-Kernel shall use the services of the Logical Link Control sub-layer of the DSRC Data Link Layer, [EN 12795].6.2 Services6.2.1 ScopeThe T-Kernel shall provide the following services:— GET: the invocation of the GET service by an application shall result in the retrieval (reading) of information (i.e.attributes) from a peer application. The service shall only be requested in a confirmed mode, and a reply isexpected;— SET: the invocation of the SET service by an application shall result in the modification (writing) of information(i.e. attributes) by a peer application. The service may be requested in confirmed or non-confirmed mode. Inconfirmed mode a reply is expected;— ACTION: the invocation of the ACTION service by an application shall result in the performance of an action bya peer application. An action is further qualified by the value of the ActionType, see [ENV ISO 14906] forexamples. The service may be requested in confirmed or non-confirmed mode. In confirmed mode a reply isexpected;— EVENT-REPORT: the invocation of the EVENT-REPORT service by an application or by the I-Kernel shallresult in the notification of an event to a peer application or I-Kernel. The service may be requested in confirmedor non-confirmed mode. In confirmed mode a reply is expected;— INITIALISATION: the invocation of the INITIALISATION service by the I-Kernel shall result in an attempt toinitialise the communication between an RSU and each OBU that has not yet established communication withthat RSU. The INITIALISATION service shall only be used by the I-Kernel.6.2.2 Service primitivesThe T-Kernel shall provide the services given in 6.2.1 by the following service primitives:— GET.request— GET.indication— GET.response— GET.confirm— SET.requestSIST EN 12834:2004
EN 12834:2003 (E)12— SET.indication— SET.response— SET.confirm— ACTION.request— ACTION.indication— ACTION.response— ACTION.confirm— EVENT-REPORT.request— EVENT-REPORT.indication— EVENT-REPORT.response— EVENT-REPORT.confirm— INITIALISATION.request— INITIALISATION.indication— INITIALISATION.response— INITIALISATION.confirmThe INITIALISATION.request and INITIALISATION.confirm primitives shall only be used on RSU side, theINITIALISATION.indication and INITIALISATION.response primitives shall only be used on OBU side.Figure 3 — Services used in confirmed modeFigure 4 — Services used in non-confirmed modeSIST EN 12834:2004
EN 12834:2003 (E)136.2.3 Format of service primitivesThe T-ASDUs for the service primitives shall have the formats as defined in Tables 2 to 6, with the notation asdefined in Table 1.Table 1 — Definition of the expressions used Tables 2 to 6iid / eidMandatory.
IID of related indication if present, else EID of related indication.optionalThe use of the optional fields is detailed by the underlying ASN.1 standards.=Same as in corresponding request / indicationNot applicableTable 2 — Format of the GET service primitivesParameter namerequest / indicationresponse / confirmASN.1 typeInvoker Identifier (IID)optional=Dsrc-EIDLink Identifier (LID)mandatory=BIT STRINGChainingmandatory=BooleanElement Identifier (EID)mandatoryiid / eidDsrc-EIDAccessCredentialsoptionalOCTET STRINGAttribute Id List (AttrIdList)optionalAttributeIdListFlowControlmandatorymandatoryINTEGERAttribute List (AttrList)optionalAttributeListReturn Code (Ret)optionalReturnStatusTable 3 — Format of the SET service primitivesParameter namerequest / indicationresponse / confirmASN.1 typeInvoker Identifier (IID)optional=Dsrc-EIDLink Identifier (LID)mandatory=BIT STRINGChainingmandatory=BooleanElement Identifier (EID)mandatoryiid / eidDsrc-EIDAccessCredentialsoptionalOCTET STRINGAttribute List (AttrList)mandatoryAttributeListModemandatoryBooleanFlowControlmandatorymandatoryINTEGERReturn Code (Ret)optionalReturnStatusSIST EN 12834:2004
EN 12834:2003 (E)14Table 4 — Format of the ACTION service primitivesParameter namerequest / indicationresponse / confirmASN.1 typeInvoker Identifier (IID)optional=Dsrc-EIDLink Identifier (LID)mandatory=BIT STRINGChainingmandatory=BooleanElement Identifier (EID)mandatoryiid / eidDsrc-EIDActionTypemandatoryINTEGER(0.127,.)AccessCredentialsoptionalOCTET STRINGActionParameteroptionalContainerModemandatoryBooleanFlowControlmandatorymandatoryINTEGERResponseParameteroptionalContainerReturn Code (Ret)optionalReturnStatusTable 5 — Format of the EVENT-REPORT service primitivesParameter namerequest / indicationresponse / confirmASN.1 typeInvoker Identifier (IID)optional=Dsrc-EIDLink Identifier (LID)mandatory=BIT STRINGChainingmandatory=BooleanElement Identifier (EID)mandatoryiid / eidDsrc-EIDEventTypemandatoryINTEGER(0.127,.)AccessCredentialsoptionalOCTET STRINGEventParameteroptionalContainerModemandatoryBooleanFlowControlmandatorymandatoryINTEGERReturn Code (Ret)optionalReturnStatusTable 6 — Format of the INITIALISATION service primitivesParameter namerequest / indicationresponse / confirmASN.1 typeLink Identifier (LID)mandatory (broadcast)mandatory (private)BIT STRINGInitialisation Parametermandatory (BST)mandatory (VST)BST / VST6.2.4 ParametersThe parameters shall be set and interpreted as follows:— IID shall be of ASN.1 type Dsrc-EID and carry the identifier of the element initiating the request or the response,respectively. This parameter is not needed if an answer shall be sent to a default invoker. If IID is used, it shallcontain the EID of the response to this primitive;— LID shall be the LID chosen by the I-Kernel on OBU side as specified in 7.3.2;— Chaining shall be a Boolean parameter. If true, “concatenation with chaining”, defined in 6.3.8, is performed;SIST EN 12834:2004
EN 12834:2003 (E)15— EID shall be of ASN.1 type Dsrc-EID and carry the identifier of the element that shall receive the indication orconfirm related to a request or response, respectively. This EID is used by the T-Kernel on the side of thereceiver to deliver an indication or a confirm to the addressed element. When the IID is used in a request theelement invoking a response shall use this IID as the EID;— AccessCredentials shall be of ASN.1 type OCTET STRING and carry security-related information needed tofulfil access conditions in order to perform the operation on the addressed element;— AttrIdList shall be a list of IDs of attributes of the element receiving a GET.indication. The values of theseattributes shall be sent via a GET.response and GET.confirm to the element invoking the GET.request, providedthat applicable access conditions have been fulfilled;— FlowControl shall be a parameter that represents the behaviour of the underlying communication service. Thisparameter shall be mapped by the T-Kernel on a certain LLC-service. The relation between FlowControlparameter, application layer behaviour and LLC-service shall be as defined in Table 7;Table 7 — Relation between FlowControl parameter, Application Layer behaviour and LLC service Flow-Control Application Layer LLC service 1 no Flow Control, no answer DL-UNITDATA.request without response request 2 no Flow Control, answer DL-UNITDATA.request with response request 3 no Flow Control DL-UNITDATA.indication 4 Flow Control, data unit transmission DL-DATA-ACK.request 5 Flow Control, data unit transmission DL-DATA-ACK.indication 6 Flow Control, data unit transmission status DL-DATA-ACK-STATUS.indication 7 Flow Control, data unit exchange DL-REPLY.request 8 Flow Control, data unit exchange DL-REPLY.indication 9 Flow Control, data unit exchange status DL-REPLY-STATUS.indication 10 Flow Control, data unit exchange preparation DL-REPLY-UPDATE.request 11 Flow Control, data unit exchange preparation status DL-REPLY-UPDATE-STATUS.indication— AttrList shall be a sequence of attributes sent by SET.request / SET.indication or GET.response / GET.confirm.The element receiving a SET.indication shall modify the values of the attributes identified in the AttrList to thevalues given in the AttrList, provided that applicable access conditions have been fulfilled. In the case ofGET.response / GET.confirm the element that received the corresponding GET.indication shall send the valuesof the attributes addressed in the AttrIdList of the GET.indication to the element invoking the GET.request,provided that applicable access conditions have been fulfilled;— Ret shall be a return code issued as an answer to a service.indication. The following codes are pre-defined:— noError:the requested operation was performed successfully;— accessDenied:the requested operation was not performed for reasons pertinent to the security of the system;— argumentError:one or more attribute values were not accessed because the identifier for the specified attribute was notrecognised or the attribute value specified was out of range or otherwise inappropriate for one or moreattributes, or the action or event-report invoked was not supported by the receiving entity;— complexityLimitation:the requested operation was not performed because a parameter was too complex;— processingFailure:a general failure in processing the operation was encountered;SIST EN 12834:2004
EN 12834:2003 (E)16— processing:the requested operation is being processed, and the result is not yet available;— chainingError:the requested operation was not performed in accordance with the rule defined in 6.3.8 “concatenation withchaining”;— Mode shall be a Boolean parameter.
If true, then there shall be a service.response to a service.indication(confirmed mode);— ActionType shall identify an operation of the element which receives an ACTION.indication and which shall beinvoked;— ActionParameter shall be the information needed for the invocation of an operation identified in anACTION.indication;— ResponseParameter may be information resulting from the execution of the operation invoked byACTION.indication;— EventType shall identify the message which shall be delivered to an element which receives an EVENT-REPORT.indication;— EventParameter shall be the additional information needed for the message sent via an EVENT-REPORT.request and EVENT-REPORT.indication, respectively;— Initialisation Parameter shall be the information needed for the initialisation of the communication (i.e. the BSTon the downlink and VST on the uplink) sent via an initialisation service.6.3 BehaviourThe transfer protocol shall consist of the following steps:a) translating SDU to PDU;b) encoding of PDU;c) fragmentation;d) octet alignment;e) multiplexing, concatenation, and access to LLC;f) demultiplexing;g) defragmentation;h) decoding of PDU, deconcatenation and removal of inserted bits;i) translating PDU to SDU and distribution to addressee.NOTE 1It is outside the scope of this European Standard how the above steps are implemented as long as an instantiation ofthe T-Kernel behaves according to the requirements below.NOTE 2The arrows shown in Figures 6 to 17 are indicating the conversion process.SIST EN 12834:2004
EN 12834:2003 (E)17Figure 5 — Functionality of the T-Kernel6.3.1 SDU to PDUThe T-Kernel shall translate the request and response service primitive into T-APDUs according to the followingrules:a service.request is translated into the corresponding service-request T-APDU defined in annex A. Aservice.response is translated into the corresponding service-response T-APDU defined in annex A. The LID shallbe removed and shall be given to the LLC in each LLC-service-primitive as defined in 6.3.6. In the case of theINITIALISATION.request the LID field shall be 1111 11112.Figure 6 — SDU to PDUSIST EN 12834:2004
EN 12834:2003 (E)186.3.2 EncodingThe T-Kernel shall encode the request and response PDUs according to ASN.1 BASIC-PER, UNALIGNED[ISO/IEC 8825-2]. The encodable ASN.1 types are specified in annex A.Figure 7 — Encoding6.3.3 FragmentationThe T-Kernel shall fragment encoded PDUs down to T-APDU fragments, which include a fragmentation header. Afragmentation header shall have a length of at least 1 octet and at most 3 octets. The length of the T-APDUfragments shall not exceed the maximum LLC frame length. The number of bits inside a fragment shall be amultiple of 8 bits for all but the last fragment. All but the last fragment shall have the same length. Fragmentationshall be made from the most significant bit down to the least significant bit according to ASN.1 BASIC-PER.Fragmentation of multiple PDUs shall be done in parallel.6.3.3.1 Fragmentation headerThe first octet of the fragmentation header shall be the first octet of the fragment. If the fragmentation headerconsists of more than one octet these octets are given in increasing order directly after the first octet.6.3.3.2 Structure of the fragmentation headerThe fragmentation header shall consist of one fragmentation indicator, one PDU number, one fragment counter,and one fragment number extension indi
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.