IEC/TS 62325-502

Framework for energy market communications - Part 502: Profile of ebXML

Specifies an energy market specific messaging profile based on the ISO 15000 series. The profile is intended to provide the basis for system configuration.

Krovni podatki za komunikacije na energijskem trgu - 502. del: Profil jezika ebXML

General Information

• Status: Not Published
• ICS: 33.200 - Telecontrol. Telemetering
• Technical Committee: TC 57 - Power systems management and associated information exchange
• Current Stage: PPUB - Publication issued
• Start Date: 07-Feb-2005
• Ref Project: oSIST-TS IEC/TS 62325-502:2009 - Framework for energy market communications - Part 502: Profile of ebXML

Standards Content (Sample)

SLOVENSKI STANDARD
oSIST-TS IEC/TS 62325-502:2009
01-december-2009
Krovni podatki za komunikacije na energijskem trgu - 502. del: Profil jezika ebXML
Framework for energy market communications - Part 502: Profile of ebXML
Ta slovenski standard je istoveten z: IEC/TS 62325-502
ICS:
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
oSIST-TS IEC/TS 62325-502:2009 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

oSIST-TS IEC/TS 62325-502:2009

---------------------- Page: 2 ----------------------

oSIST-TS IEC/TS 62325-502:2009


TECHNICAL IEC


SPECIFICATION TS 62325-502





First edition
2005-02


Framework for energy market communications –
Part 502:
Profile of ebXML

 IEC 2005  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: [phone] Telefax: [phone] E-mail: [e-mail] Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale
U

International Electrotechnical Commission
Международная Электротехническая Комиссия
For price, see current catalogue

---------------------- Page: 3 ----------------------

oSIST-TS IEC/TS 62325-502:2009
– 2 – TS 62325-502  IEC:2005(E)
CONTENTS
FOREWORD.3
INTRODUCTION.6
1 Scope .7
2 Normative references .7
3 Terms, definitions and abbreviations .7
3.1 Terms and definitions .7
3.2 Abbreviations .7
4 Guideline of how to use the architecture.9
4.1 Profile of the architecture.9
4.2 Security profile of the BPSS.10
4.3 Profile of the CPP/A.13
4.4 Messaging service profile .16
5 Implementation level.16

Annex A (normative) Message service profile .17
Annex B (informative) Implementation levels .29

Figure 1 – References and content of ebXML documents.9

Table 1 – BPSS Profiles for reliability, non-repudiation, and security.11
Table 2 – Message reliability.11
Table 3 – Non-repudiation and legally binding .12
Table 4 – Authorisation, Authentication and confidentiality.13
Table 5 – CPP/CPA options and choices .14
Table 6 – S/MIME v3 security parameters .15
Table 7 – OpenPGP/MIME security parameters .16
Table B.1 – Overview of implementation levels.29

---------------------- Page: 4 ----------------------

oSIST-TS IEC/TS 62325-502:2009
TS 62325-502  IEC:2005(E) – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________

FRAMEWORK FOR ENERGY MARKET COMMUNICATIONS –

Part 502: Profile of ebXML


FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. In
exceptional circumstances, a technical committee may propose the publication of a technical
specification when
• the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts, or
• the subject is still under technical development or where, for any other reason, there is the
future but no immediate possibility of an agreement on an International Standard.
Technical specifications are subject to review within three years of publication to decide
1
whether they can be transformed into International Standards.
IEC 62325-502, which is a technical specification, has been prepared by IEC technical
committee 57: Power systems management and associated information exchange.
———————
1
This would also include the specification of some options/parameters not yet specified in the profile, Annex A.

---------------------- Page: 5 ----------------------

oSIST-TS IEC/TS 62325-502:2009
– 4 – TS 62325-502  IEC:2005(E)
The IEC 62325 series cancels and replaces IEC 62195 (2000) and its amendment (2002).
It constitutes a technical revision.
IEC 62195 (2000) dealt with deregulated energy market communications at an early stage. Its
amendment 1 (2002) points out important technological advancements which make it possible
to use modern internet technologies based on XML for e-business in energy markets as an
alternative to traditional EDI with EDIFACT and X12. The new IEC 62325 framework series for
energy market communications currently consisting of IEC 62325-101, IEC 62325-102,
IEC 62325-501, and IEC 62325-502 follows this direction and replaces IEC 62195 together
with its amendment.
The text of this technical specification is based on the following documents:
Enquiry draft Report on voting
57/707/DTS 57/724/RVC

Full information on the voting for the approval of this technical specification can be found in
the report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
IEC 62325 consists of the following parts, under the general title Framework for energy
market communications:
Part 101: General guidelines
Part 102: Energy market model example
2
Part 201: Glossary
3
Part 3XX: (Titles are still to be determined)
4
Part 401: Abstract service model
Part 501: General guidelines for use of ebXML
Part 502: Profile of ebXML
4
Part 503: Abstract service mapping to ebXML
4
Part 601: General guidelines for use of web services
4
Part 602: Profile of Web Services
4
Part 603: Abstract service mapping to web services
———————
2
 Under consideration. Because the technologies have an inherent own glossary within their standard definitions,
2)
this glossary is a placeholder for a glossary for future parts indicated with including energy market specific
terms and definitions.
3
 Under consideration. These parts for business content are mentioned for completeness only with a number
space as placeholder. They extend the original scope and require an agreed new work item proposal for further
work based on an overall strategy how to proceed.
4
 Under consideration. These technical parts are mentioned for completeness with provisional title. They extend
the original scope and require an agreed new work item proposal for further work.

---------------------- Page: 6 ----------------------

oSIST-TS IEC/TS 62325-502:2009
TS 62325-502  IEC:2005(E) – 5 –
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• transformed into an International standard,
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual edition of this document may be issued at a later date.

---------------------- Page: 7 ----------------------

oSIST-TS IEC/TS 62325-502:2009
– 6 – TS 62325-502  IEC:2005(E)
INTRODUCTION
With the transition of monopoly energy supply structures to deregulated energy markets, the
function of the markets depends heavily on seamless e-business communication between
market participants. Compared with global e-business, e-business in the energy market is
only a small niche. Today EDIFACT or X12 messages, or propriety HTML and XML solutions
based on Internet technologies are being used.
The ‘electronic business Extensible Markup Language’ (ebXML) specification and architecture
stems from UN/CEFACT and OASIS and these are now partly standards within the ISO 15000
series being complemented in future to cover all aspects of ebXML. ebXML is a complete set
of specifications and standards to enable secure electronic business using proven, open
standards such as TCP/IP, HTTP, SOAP, XML, and SOAP signature and encryptation. ebXML
is also evolutionary in nature, built on 25 years of EDI experience, designed to work with
existing EDI solutions, or be used to develop an emerging class of internet based electronic
business applications based on XML. This means that with ebXML existing EDI messages
(EDIFACT, X.12) as well as XML messages can be exchanged.
Profiles of ebXML allow the re-use of proven core components and communication platforms
across markets, thus saving cost and implementation time.


.

---------------------- Page: 8 ----------------------

oSIST-TS IEC/TS 62325-502:2009
TS 62325-502  IEC:2005(E) – 7 –
FRAMEWORK FOR ENERGY MARKET COMMUNICATIONS –

Part 502: Profile of ebXML



1 Scope
This part of IEC 62325 specifies an energy market specific messaging profile based on the
ISO 15000 series. The profile is intended to provide the basis for system configuration.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
ISO/TS 15000-1:2004, Electronic business eXtensible Markup Language (ebXML) – Part 1:
Collaboration-protocol profile and agreement specification (ebCPP)
ISO/TS 15000-2:2004, Electronic business eXtensible Markup Language (ebXML) – Part 2:
Message service specification (ebMS)
UN/CEFACT, ebXML Business Process Specification Schema, v1.10 or higher
UN/CEFACT, ebXML Technical Architecture Specification, v1.04 or higher
In this part of IEC 62325, RFCs (Request for comments) from the Internet Engineering Task
Force (IETF) and recommendations from other Organisations such as the Word Wide Web
Consortium (W3C) and the Organization for the Advancement of Structured Information
Standards (OASIS) are mentioned which are not included here because these documents are
referenced in the references above.
3 Terms, definitions and abbreviations
3.1 Terms and definitions
None.
3.2 Abbreviations
A2A Application-to-Application
AES Advanced Encryption Standard
B2B Business-to-Business
BDS Business Document Specification (instance)
BDSS Business Document Specification Schema
BIE Business Information Entity
BOV Business Operational View
BPMS Business Process Management System
BPSS Business Process Specification Schema (or instance)
BSI Business Service Interface

---------------------- Page: 9 ----------------------

oSIST-TS IEC/TS 62325-502:2009
– 8 – TS 62325-502  IEC:2005(E)
CC Core Component (based on BIE)
CIM Common Information Model
CPA Collaboration Protocol Agreement
CPP Collaboration Protocol Profile
DSO Distribution System Operator (of power system
DUNS Data Universal Numbering System (North America)
EAN European Article Number (Europe)
ebMS ebXML Messaging Service
ebXML electronic business XML
EDI Electronic Data Exchange
EIA Enterprise Application Integration
EMS Energy Management Systems
ERP Enterprise Resource Planning
FOV Functional Service View
FTP File Transfer Protocol
HTTP Hypertext Transport Protocol
ICT Information and Communication Technology
ISO Independent System Operator
IT Information Technology
MIME Secure/Multipurpose Internet Mail Extensions
MIS Market Identification Schema
MOM Message-oriented middleware
MSH Message Service Handler
PKI Public Key Infrastructure
QoS Quality of Service
RPC Remote Procedure Call
RR Registry / Repository
SAML Security Assertion Mark-up Language
SCADA Supervision, Control, and Data Acquisition
SMTP Simple Mail Transfer Protocol
SO System Operator (of power system)
SOAP Simple Object Access Protocol
TLS Transport Layer Security
TSO Transmission System Operator (of power system)
UML Unified Modelling Language
UMM UN/CEFACT Modelling Methodology
VPN Virtual Private Network
WS Web Services
WSDL Web Services Definition Language
XML eXtensible Markup Language
XKMS XML Key Management Specification

---------------------- Page: 10 ----------------------

oSIST-TS IEC/TS 62325-502:2009
TS 62325-502  IEC:2005(E) – 9 –
4 Guideline of how to use the architecture
4.1 Profile of the architecture
Within the ebXML specification framework, two business partners agree on how to perform
e-business using machine-readable Trading Partner Agreements based on XML syntax and
named Collaboration Profile Agreements (CPA). In the general case of global e-business, the
CPA is negotiated as the intersection of the Collaboration Protocol Profiles (CPP) of these
two partners, who may have discovered each other using the registry partner-discovering
feature.
Energy markets normally exist in a specific geographical area or geopolitical region with
known business partners, agreed market rules and communication infrastructure. In this
environment, a simplification may be possible where alternatively pre-negotiated CPA’s of
each business process are stored pre-defined in the registry/repository and can be
downloaded for use.
Within each market, a profile or a limited set of profiles of the ebXML architecture should be
used to harmonise and simplify e-business. Since the ebXML specification framework does
not define any market specific profiles, the profile for energy markets has to be specified. In
the following business process driven BPSS “security profiles”, CPP/CPA “technical profiles”
and “messaging profiles” are specified.
For better understanding of the profiles defined below 4.2 to 4.4, Figure 1 shows the
configuration files used with its content structure.

Role
XML
documentation
Packaging
and
Service binding
(MIME)
configuration files
Delivery channel
CPP / CPA
includes
Document exchange
Transport
references
(reliability , security)
includes
BPSS
references
Multi party collaboration
Business document
overrides
Binary collaboration
references
Business transaction activity
Business document
schema
Document exchange
Business transaction
(reliability , security)
IEC  149/05

Figure 1 – References and content of ebXML documents

---------------------- Page: 11 ----------------------

oSIST-TS IEC/TS 62325-502:2009
– 10 – TS 62325-502  IEC:2005(E)
4.2 Security profile of the BPSS
The ebXML BPSS instance provides the possibility for a collaboration to specify message
reliability and message security, including non-repudiation with legally binding at the business
level.
The BPSS is used for more than one collaboration between market participants. Note that the
CPA for a specific collaboration may therefore override the reliability, non-repudiation and
security attribute values of a BPSS.
Table 1 shows the recommended profiles. Reliability is included in all profiles. Profile #1 only
provides reliability. Profile #2 adds non-persistent (transient) confidentiality and non-
persistent (transient) authentication (on transport or network level, for example TLS, IPsec).
Profile #3 adds persistent confidentiality, persistent authentication, and tamper-proof
messages (signed messages with keyed digest). The latter is sometimes also called
non-repudiation of origin. Profile #4 is for full persistent security including persistent
non-repudiation and invoked authorisation. The profiles #3 and #4 should be preferred
because only these profiles guarantee end-to-end persistent security and non-repudiation
within a market with established relationships.
The table also includes the mapping of the BPSS profiles to the MSH profiles 0, 3, 16, and 21.
The MSH profiles 16 and 21 can be optional, used with a trusted time stamp if this service is
available and needed.
For the sake of compatibility within a project or market, choices have to be made about:
• the location of the persistent security services. Persistent end-to-end security should be
implemented on application level by default. The optional use of MSH security services, if
supported, is a project or market decision;
• a single BPSS profile for each process. Different processes can have different BPSS
profiles, depending of the need for security.
In the following subclauses, the BBSS attribute options which have to be chosen according to
the recommended profiles in Table 1 are shown. The signature should apply to the whole
message, including the envelope where the Signature element is contained. The partial
signing of XML documents should not be used for sake of simplicity, because there is no
known requirement.

---------------------- Page: 12 ----------------------

oSIST-TS IEC/TS 62325-502:2009
TS 62325-502  IEC:2005(E) – 11 –
Table 1 – BPSS profiles for reliability, non-repudiation, and security
Feature Options Profile Profile Profile Profile
#1 #2 #3 #4
MSH profile Supported Security Services 0 3 16 21
Persistence Persistent Security and Non-repudiation NA NO YES YES
Reliability
1)
Guaranteed Delivery (acknowledgement, retry) X X X X
Intelligible Check (message validation with a schema) X X X X
Non-repudiation
2)
Non-Repudiation (saved audit trail of documents)  X
1) 2)

Non-Repudiation of Receipt (signed receipt)   X
Legally Binding (legal document)  X
Security
Authorization Required (validation of identity, e.g. SAML)  X
Tamper Proof (signed message and keyed digest)  X X
1)
Confidential (encryption)  X X X
1)
Authenticated (proof of identity) X X X
1) Service of the MSH.
2) Alternatively.

Message reliability
Messages are received, validated and accepted. This concept is based on acknowledgements
on the messaging level and validation of received messages with schemas. Table 2 shows the
reliability options and choices.
Within the reliability profile, all options should be true and all parameters should be filled in.
• Profile 1, 2, 3, 4: reliability with all attributes mandatory and true and parameters filled in.

Table 2 – Message reliability
Element Attribute m/o Options and choices or remark
BusinessTransaction/ m
isGuaranteedDeliveryRequired m “true”
RequestingBusinessActivity m > 0, e.g. “P2H”
isIntelligibleCheckRequired m “true”
timeToAcknowledgeReceipt m > 0, e.g. “P2H”
timeToAcknowledgeAcceptance m > 0, e.g. “P4H”
RespondingBusinessActivity
isIntelligibleCheckRequired m “true”
timeToAcknowledgeReceipt m > 0, e.g. “P2H”
BusinessTransactionActivity
timeToPerform m > 0, e.g. “P1D”
The column m/o means mandatory/optional.

---------------------- Page: 13 ----------------------

oSIST-TS IEC/TS 62325-502:2009
– 12 – TS 62325-502  IEC:2005(E)
Non-repudiation and legally binding security
Messages are signed in order to provide message and sending party authentication,
non-repudiation and to make them legally binding. Furthermore, authorisations can be
configured. Table 3 shows non-repudiation and legally binding options and choices.
Within the non-repudiation profile, the following should be used:
• Profile 1, 2, 3: Non-repudiation with all attributes “false”, or
• Profile 4: Non-repudiation with the “isNonRepudiationRequired” or the
“isNonRepudiationOfReceiptRequired” attribute “true”.
The attribute “isLegallyBinding” is “true” by default. If true, the market participants agree that
the business commitment of exchanged messages within a transaction can be enforced in
court.
Table 3 – Non-repudiation and legally binding
Element Attribute m/o Options and choices or remark
BusinessTransaction/ m
RequestingBusinessActivity
isNonRepudiationRequired o “false” or “true” (save an audit trail,
message digest)
isNonRepudiationOfReceiptRequired o “false” or “true” (signed receipt)
RespondingBusinessActivity
isNonRepudiationRequired o “false” or “true” (save an audit trail,
message digest)
isNonRepudiationOfReceiptRequired o “false” or “true” (signed receipt)
BusinessTransactionActivity
isLegallyBinding o Default “true”, “false”
The column m/o means mandatory/optional.


Message security
Security provides authorisation, authentication and confidentiality. Table 4 shows the security
options and attributes. The following should be used:
• Profile 1: no security with the isAuthorizationRequired attribute “false” and all other
attributes “none”, or
• Profile 2: security with the “isConfidential” and “isAuthenticated” attribute “transient”, or
• Profile 3: security with the “isConfidential”, “isAuthenticated”, and “isTemperProof”
attribute “persistent”, or
• Profile 4: security with the isAuthorizationRequired attribute “true” and all other attributes
“persistent”.

---------------------- Page: 14 ----------------------

oSIST-TS IEC/TS 62325-502:2009
TS 62325-502  IEC:2005(E) – 13 –
Table 4 – Authorisation, Authentication and confidentiality
Element Attribute m/o Options and choices or remark
BusinessTransaction/ m
RequestingBusinessActivity
isAuthorizationRequired o “false” or “true”
RequestingBusinessActivity/
DocumentEnvelope
isTamperProof o “none” or “persistent” (signed
message)
isConfidential o “none” or “transient”, “persistent”
isAuthenticated o “none” or “transient”, “persistent”
RespondingBusinessActivity
isAuthorizationRequired o “false” or “true”
RequestingBusinessActivity/
DocumentEnvelope
isTamperProof o “none” or “persistent” (signed
message)
isConfidential o “none” or “transient”, “persistent”
isAuthenticated o “none” or “transient”, “persistent”
The column m/o means mandatory/optional.

4.3 Profile of the CPP/A
The mandatory elements and possible choices and options of the CPP version 2.0 are shown
in Table 5.
Party identification and reference
Within the “PartyInfo” element, the sub element “PartyID” is used to unambiguously identify
the market participant. It has a string content attribute and a type attribute with a string value.
The string content provides the identifier based on a Market Identification Schema defined by
the type attribute string value. There can be multiple PartyIDs if different market identification
schemas identify a single organisation. The latter is also used for migration from several
market identification schemas to a future agreed single one.
The “PartyRef” element is an Xlink simple link, which can store references to other
(descriptive) information about the party. It typically would reference the organisation’s
website. It is not used in this framework.
Document security (optional)
The “Characteristics” sub element of “DeliveryChannel” specifies optional document security
and is normally empty, but can be used bilaterally to override the values specified in the
BPSS. If document security is used, all attributes or only the confidentiality option should be
set to “true” if not already done in the BPSS (4.3). In this case, within the element
“DocExchange”, the sub element “NonRepudiation” for digital signatures or “DigitalEnvelope”
for encryption becomes mandatory and all shown parameters should be filled in.
Transport security (optional)
The “Characteristics” sub element of “DeliveryChannel” specifies optional non-persistent
transport security and is normally empty but can be used bilaterally to override the value
specified in the BPSS. Secure transport depends on the security method and is chosen if
secure transport is used. In this case, the sub element “TransportSecurity” element of
Transport should be filled in.

---------------------- Page: 15 ----------------------

oSIST-TS IEC/TS 62325-502:2009
– 14 – TS 62325-502  IEC:2005(E)
Table 5 – CPP/CPA options and choices
Element Sub element Sub element n m/o Options and choices or
or attribute or attribute remark

 1 m
PartyID  m
PartyInfo
PartyRef  o Not used.
Certificate  o For public key-based
security
 1 m
ProcessSpecification  m Identifies BBSS
Role  m Initiating or responding role
of partner within BPSS
ServiceBinding  m Binds channel, packaging
CollaborationRole
- channelID m
- packageID m
- Service (…) n m Only 1
Override o
 1 m
- channelID  m Ref by ServiceBinding
- transportID  m References Transport
- docExchangeID  m References DocExchange
Characteristics (overrides BPSS!) m Normally empty
- synchReplyMode o Default “none”
DeliveryChannel

- nonrepudiationOfOrigin o Empty or “true” or “false”

- nonrepudiationOfReceipt o Empty or “true” or “false”
Document level security
- secureTransport o Default “false”
- confidentiality o Empty or “true” or “false”
- authenticated o Empty or “true” or “false”
- authorized o Empty or “true” or “false”
 n m Only 1. MIME.
- id  m Ref by ServiceBinding
ProcessingCapabilities
- parse m “true”
- generate m “true”
SimplePart n
Packaging
- id m
- mimetype m
- mimeparameters o
NamespaceSupported o
CompositeList 1
Composite (id, mimetype) n m
Transport  n m
- transportID
SendingProtocol 1
- version m Version of transport protocol
protocol (HTTP or SMTP, m “HTTP” or “SMTP”
...)
Protocols and ReceivingProtocol 1
Transport leve
...