ETSI TS 119 524-2 V1.1.1 (2019-02)

TECHNICAL SPECIFICATION
Electronic Signatures and Infrastructures (ESI);
Testing Conformance and Interoperability of
Electronic Registered Delivery Services;
Part 2: Test suites for interoperability testing of
Electronic Registered Delivery Service Providers

2 ETSI TS 119 524-2 V1.1.1 (2019-02)

Reference
DTS/ESI-0019524-2
Keywords
electronic registered delivery, interoperability,
testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 119 524-2 V1.1.1 (2019-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Technical approach. 8
4.1 Components of test cases and their identifiers . 8
4.2 Adding new test cases to the test suite . 9
5 Scenarios . 10
5.1 Introduction . 10
5.2 Abbreviations used in tables defining scenarios . 11
5.3 Black-box model scenarios. 12
5.3.1 Introduction. 12
5.3.2 Scenarios without notification for acceptance . 12
5.3.3 Scenarios with notification for acceptance . 20
5.4 Scenarios for 4-corner model . 26
5.4.1 Introduction. 26
5.4.2 Scenarios where RERDS does not use notification for acceptance . 26
5.4.3 Scenarios where RERDS uses notification for acceptance . 34
5.5 Scenarios for extended model . 43
5.5.1 Introduction. 43
5.5.2 Scenarios where RERDS does not use notification for acceptance . 43
5.5.3 Scenarios where RERDS uses notification for acceptance . 52
6 ERD Messages instances . 60
6.1 Introduction and technical approach. 60
6.2 Combinations of fields for headers in ERD envelopes . 60
6.2.1 Introduction. 60
6.2.2 Combinations of AS4 metadata profiled in ETSI EN 319 522-4 . 60
6.2.3 Combinations of components of relay metadata . 61
6.2.4 Combinations of AS4 metadata profiled and relay metadata . 65
6.3 Instances of ERD payload . 66
6.4 Instances of ERDS receipts . 66
6.5 Instances of ERD dispatch. 66
7 Other named sets . 67
7.1 Named sets of participating ERDSs . 67
7.2 Named sets of additional requirements . 67
7.3 Named sets of entities in receiving side . 67
8 Test cases definition . 67
8.1 Introduction . 67
8.1.1 General . 67
8.1.2 Notation for black box model scenarios . 68
8.1.3 Notation for 4 corner and extended models scenarios . 68
8.1.4 Reasons for Failures. 70
8.2 Test cases for black box model . 70
8.3 Test cases for 4-cornel and extended models . 70
8.3.1 General . 70
ETSI
4 ETSI TS 119 524-2 V1.1.1 (2019-02)
8.3.2 Rules for parametrizing ERD dispatches . 70
8.3.3 Rules for parametrizing ERD payloads . 71
8.3.4 Rules for parametrizing ERDS receipts . 71
8.3.5 Rules for parametrizing entities at receiving side . 71
8.3.6 Rules for parametrizing failure reasons . 71
8.3.7 Rules for parametrizing additional requirements . 71
Annex A (informative): Bibliography . 72
History . 73

ETSI
5 ETSI TS 119 524-2 V1.1.1 (2019-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI).
The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.1].
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TS 119 524-2 V1.1.1 (2019-02)
1 Scope
The present document defines:
1) A test suite for supporting interoperability tests within the field of Electronic Registered Delivery Services
(ERD services or ERDS hereinafter) as specified in ETSI EN 319 522 parts 1 [1], 2 [2], 3 [3] and 4 [4], [5] and
[6]. The test suite defines test cases for the following environments:
- Environments that correspond to the basic model as defined in ETSI EN 319 522-1 [1] where sender and
all the entities at receiving side are subscribed to the same ERDS.
- Environments that correspond to the 4-corner model as defined in ETSI EN 319 522-1 [1] where sender
is subscribed to one ERDS and the entities at receiving side are subscribed to another one, and no
intermediate ERDS is required for relaying ERD messages between them.
- Environments that correspond to the extended model as defined in ETSI EN 319 522-1 [1] where sender
is subscribed to one ERDS and the entities at receiving side are subscribed to another one, and
intermediate ERDSs are required for relaying ERD messages between them.
2) A mechanism for documenting new test cases and expanding the aforementioned test suite.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[2] ETSI EN 319 522-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 2: Semantic contents".
[3] ETSI EN 319 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 3: Formats".
[4] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings".
[5] ETSI EN 319 522-4-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 2: Evidence and identification bindings".
[6] ETSI EN 319 522-4-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 3: Capability/requirements bindings".
[7] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[8] OASIS Standard (January 2013): "AS4 Profile of ebMS 3.0 Version 1.0".
ETSI
7 ETSI TS 119 524-2 V1.1.1 (2019-02)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 119 524-1: "Electronic Signatures and Infrastructures (ESI); Testing Conformance and
Interoperability of Electronic Registered Delivery Services; Part 1: Testing conformance".
[i.2] OASIS Standard (October 2007): "ebXML Messaging Services Version 3.0: Part 1, Core
Features".
NOTE: Available at http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.pdf.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI EN 319 522-1 [1] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACC_REJ_EXP ACCeptance REJection EXPiry
AS4 Applicability Statement 4
CONS_ACC CONSignment ACCeptance
CONS_NOT CONSignment NOTification
CONS_NOT_FAIL CONSignment NOTification FAILure
CONS_REJ CONSignment REJection
CONT_CONS CONTent CONSignment
CONT_CONS_FAIL CONTent CONSignment FAILure
CONT_HAND CONTent HANDover
CONT_HAND_FAIL CONTent HANDover FAILure
ebMS ebXML Messaging Services
ebXML Electronic Business using eXtensible Markup Language
ERD Electronic Registered Delivery
ERDS Electronic Registered Delivery Service
EV_SET Evidence - SET
IERDS Intermediate Electronic Registered Delivery Service
NOT_F_ACC NOTification For ACCceptance
OASIS Organization for the Advancement of Structured Information Standards
REC_F_NERDS RECeived From Non ERDS
REL_ACC RELay ACCeptance
REL_FAIL RELay FAILure
REL_REJ RELay REJection
REL_T_NERDS RELay To Non ERDS
REL_T_NERDS_FAIL RELay To Non ERDS FAILure
ETSI
8 ETSI TS 119 524-2 V1.1.1 (2019-02)
REM Registered Electronic Mail
REMS Registered Electronic Mail Service
RERDS Recipient's Electronic Registered Delivery Service
SCN_ID Scenario IDentifier
SERDS Sender's Electronic Registered Delivery Service
SUB_ACC SUBmission ACCeptance
SUB_REJ SUBmission REJection
URI Universal Resource Identifier
XML eXtensible Mark-up Language
4 Technical approach
4.1 Components of test cases and their identifiers
As it has been mentioned before the present document defines:
1) A test suite for supporting interoperability tests within the field of Electronic Registered Delivery (ERD
hereinafter) as specified in as specified in ETSI EN 319 522 parts 1 [1], 2 [2], 3 [3] and 4 [4], [5] and [6].
2) A mechanism for documenting new test cases and expanding the aforementioned test suite.
The present document follows a layered approach for building the definition of the test cases in the test suite, which can
be summarized as follows:
1) Clause 5 defines a number of parameterized scenarios. A scenario consists of a number of entities, namely:
sender, one or more ERDSs, and the entities at receiving side (one or more recipients and/or one or more
recipients' delegates), which exchange different ERD messages with time. Each scenario corresponds to one of
the three models presented in ETSI EN 319 522-1 [1]. This clause presents a template for defining one
scenario, in a way that resembles to some templates used for defining use cases scenarios in software
engineering.
This template:
- Includes the enumeration of the original message and all the ERD messages exchanged by the
participating entities. This list of exchanged ERD messages is one of the parameters of the scenario.
- Also includes a list of ERDS evidence sets, which, in the scenario, are incorporated in some ERD
messages.
One scenario may be used for defining several test cases depending on:
- The specific components of each exchanged ERD message (suppressing or adding an optional metadata
component, or changing the value of a certain metadata component results in a different ERD message
and consequently a different test case).
- The entities at receiving part (for instance, changing one recipient by one recipient's delegate, or two
recipients and one recipient's delegate results in a different the test case).
- A named set of additional requirements (for instance details of the original message, like whether it
contains or not attachments, is signed, is encrypted, etc.).
This means that one test case corresponds to one scenario where all the exchanged ERD messages have been
completely defined in terms of their components, all the participating entities have been established, and all the
additional requirements have also been defined. Taking the functional notation this can be expressed as
follows:
TestCase#i = Scenario_id(,, , details>, …, , Where:
- is the identifier assigned to a certain set of entities at receiving side;
ETSI
9 ETSI TS 119 524-2 V1.1.1 (2019-02)
- is the identifier of a specific instantiation of the aforementioned message, defined
in clauses 6.3, 6.4 and 6.5. These clauses define specific instantiations of ERD payloads, ERD receipts
and ERD dispatches respectively.
- is the identifier of a named set of additional requirements.
Clause 7.2 defines a number of these named sets.
2) Clauses 6.3, 6.4 and 6.5 define specific instantiations of ERD payloads, ERD receipts and ERD dispatches
respectively. Each type of ERD message is composed by several components, with their metadata components
and payloads as specified in ETSI EN 319 522-4-1 [4] and ETSI EN 319 522-4-2 [5]. The present document
defines a number of combinations of metadata components in clauses 6.2.2 and 6.2.3, and assigns to each one
a unique identifier. This allows to use again the functional notation, and define one instantiation of a certain
type of ERD message as follows:
ERD message instance = Sequence(Metadata(, for ERDS relay metadata combination details>) * Evidence>*)
Where '*' stands for 0 or more occurrences of the payload.
NOTE: The payloads for user content and for ERDS evidence can be present at certain types of ERD messages
but are forbidden in other types.
3) Clauses 6.2.2 and 6.2.3 define named combinations of metadata components defined in OASIS: "AS4 Profile
of ebMS 3.0 Version 1.0" [8] and profiled in ETSI EN 319 522-4-1 [4] and ETSI EN 319 522-4-2 [5], and the
relay metadata components defined in ETSI EN 319 522-3 [3] respectively. Each clause define different
instances of the aforementioned components and assigns them unique identifiers that are used for defining
specific instances of the different ERD messages as shown above. Once this level is reached, the specific test
case is fully defined as: a scenario where fully defined, ERD messages are exchanged between a specific set
participating entities, and where a specific set of additional requirements are imposed.
4.2 Adding new test cases to the test suite
The strategy followed for building the definitions of the test cases makes it easy to expand the test suite by
incorporation of new test cases.
For defining a new test case the following steps are required:
1) Identify the set of receiving entities. If none of the predefined set of entities at the receiving side is the one
required, assign a name to this set () and incorporate it to the repertoire of
named sets as specified in clause 7.3). The sender is always present by default.
2) Define the ERDSs that will participate in the test case.
3) If the set of participating ERDSs is not equal to none of the scenarios already identified in the present
document, the new scenario will require to be defined in a new template.
4) Identify the sequence of actions performed by each actor and their order of occurrence and assign a new
unique identifier () to the scenario.
5) Identify all the ERD messages generated by the actors as they go through the sequence of actions. For each
message:
a) Identify its ebMS payloads, e.g. the parts of the user content or XML document with relay meta-data.
b) Check if the combinations of metadata components have already been defined in the present document.
If not, add the required combination of metadata components to the repertoire of named combinations to
the corresponding clause (clause 6.2.2 or 6.2.3).
c) List all the ERD messages exchanged as parameters of the scenario.
d) Identify the ERDS evidence format and the set of ERDS evidence for each ERD message including them
and add the names of the ERDS evidence sets to the Var section of the template.
ETSI
10 ETSI TS 119 524-2 V1.1.1 (2019-02)
6) Identify and define any other additional requirement for completely define the test case. If the set of
requirements is different than all the sets already define, assign a name to it () and add
it to the repertoire of named sets of additional requirements in Table 12 (clause 7.2).
5 Scenarios
5.1 Introduction
The present clause defines a number of selected scenarios that will be used in clause 8.
Clause 5.3 defines scenarios where sender and recipient(s) are subscribed to the same ERDS (black-box model
described in ETSI EN 319 522-1 [1]).
Clause 5.4 defines scenarios where the sender and the recipient(s) are subscribed to different ERDSs and there are not
intermediate ERDSs between them (4-corner model described in ETSI EN 319 522-1 [1]).
Clause 5.5 defines scenarios where sender is subscribed to a ERDS and the recipient(s) is(are) not subscribed to the
same ERDS and there are one or more intermediate ERDSs (extended model described in ETSI EN 319 522-1 [1]).
Figure 1 of clause 4 of ETSI EN 319 522-2 [2] shows three structures being exchanged between ERD-UAs and ERDSs,
namely:
1) The structure {submission metadata, user content}, which receives the name of original message in Table 1 of
clause 4 of ETSI EN 319 522-2 [2].
2) The structure {ERDS handover metadata, ERDS evidence} for allowing access to ERDS evidences to users.
3) The structure {ERDS handover metadata, user content, ERDS evidence} for allowing the R-ERDS the
submission of the user content (and optionally ERDS evidences) to the recipient.
Because of that the following decisions have been adopted for building the scenarios:
1) Neither S-ERDS nor R-ERDS will submit {ERDS handover metadata, ERDS evidence} structures to their
users, except when the ERDS evidence is an evidence of some kind of relevant rejection by the ERDS (see the
first scenario, for instance). Identical scenarios including the submission of such structures can be easily
defined and used in interoperability test events.
2) The scenarios will show the R-ERDS submitting {ERDS handover metadata, user content, ERDS evidence} or
{ERDS handover metadata, user content} structures to the receiving side.
3) The acronym hndvMet is used for ERDS handover metadata.
Table 1 shows the template for defining one scenario.
ETSI
11 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 1: Template for the tabular definition of one scenario
Scenario id: Purpose
Parameter: _with_XML_SUB_REJ 1 that helps to fully the scenario. Their number depends on the Named sets of ERDS evidence used in
specific scenario> the definition of the scenario.
Parameter: Var SET_EV#2 = {… …}
Parameter: Var SET_EV#N = {… …}
Sequence of actions

# Sender ERDS Receiving side
The sequence is composed of a number of numerated steps, when the actors perform certain actions as
shown below.
Some frequent actions: send original message, accept submission, reject submission, consign, generate
one ERDS evidence, generate one ERD message, etc.
1 Sender sends original message
2 Rejects submission. Generates

XML_SUB_REJ ERDS evidence
3 Generates
_with_XML_SUB_REJ
4 Sends
_with_XML_SUB_REJ
5 Receives
_with_XML_SUB_REJ

Each scenario is assigned a unique identifier . The reasons why the scenario has been defined are shown in
column "Purpose".
The definition of each scenario requires that parties exchange a number of ERD messages, which appear listed as
parameters in the rows immediately below the headers row. Its number depends on the specific scenario.
Below the list of parameters, the table shows a sequence of actions performed by different involved entities, which
results in that a set of ERD messages is generated and exchanged.
The definition of each scenario also can use a number of named ERDS evidence sets, which are listed in cells started
with Var. Each ERDS evidence set is given a name EV_SET#, being a non-negative integer number.
The involved entities are sender (or sender's delegate, the scenario definition does not make any distinction between
them), one or more ERDSs, and the entities at the receiving side (for the same scenario there may be different sets of
entities, for instance one recipient, one recipient's delegate, one or more recipients, or one or more recipients and one or
more recipients' delegates).
Each step is assigned a positive integer number. The actions performed include: submission of messages, generation of
ERD messages, generation of ERDS evidence, acceptance of ERD messages, rejection of ERD messages, consignment
of ERD messages, retrieval of ERD messages by entities at receiving side, failures, etc.
5.2 Abbreviations used in tables defining scenarios
This clause shows some abbreviations (which have already been anticipated in clause 3.3) used in the tables that define
the scenarios.
Table 2 shows the abbreviations used for the different ERDS evidence.
ETSI
12 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 2: ERDS evidence abbreviations
ERDS Evidence name ERDS Evidence abbreviation
SubmissionAcceptance SUB_ACC
SubmissionRejection SUB_REJ
RelayAcceptance REL_ACC
RelayRejection REL_REJ
RelayFailure REL_FAIL
NotificationForAcceptance NOT_F_ACC
NotificationForAcceptanceFailure CONS_ACC
ConsignmentAcceptance CONS_REJ
ConsignmentRejection CONT_CONS
AcceptanceRejectionExpiry ACC_REJ_EXP
ContentConsignment CONT_CONS
ContentConsignmentFailure CONT_CONS_FAIL
ConsignmentNotification CONS_NOT
ConsignmentNotificationFailure CONS_NOT_FAIL
ContentHandover CONT_HAND
ContentHandoverFailure CONT_HAND_FAIL
RelayToNonERDS REL_T_NERDS
RelayToNonERDSFailure REL_T_NERDS_FAIL
ReceivedFromNonERDS REC_F_NERDS

ETSI EN 319 522-1 [1] specify a XML format for ERDS evidence, but also allows that ERDS Evidences are signed
PDF documents. The notation defined in the present document makes it clear that all the test cases are defined for XML
ERDS Evidence using the XML prefix for the ERDS evidence abbreviations.
EXAMPLE: The abbreviation for the XML SubmissionAcceptance ERDS evidence will be XML_SUB_ACC.
NOTE: In case some format for PDF ERDS Evidence is defined and ERDS providers need to test interoperability
with them, it is always possible to replace the test cases defined in the present document by identical test
cases where PDF ERDS Evidences are generated and exchanged instead XML ERDS Evidences.
The tables defining the Scenarios use the following abbreviations for the different participating ERDSs:
• SERDS stands for the ERDS serving the sender, in the scenarios where it is different than the ERDS serving
the entities at receiving side.
• RERDS stands for the ERDS serving the entities at receiving side, in the scenarios where it is different than
the ERDS serving the sender.
• IERDS stands for a ERDS that does not directly serves neither to the sender nor to the recipient(s)/recipient's
delegate, but instead is an intermediate ERDS that relies ERD messages from SERDS to RERDS and from
RERDS to SERDS.
5.3 Black-box model scenarios
5.3.1 Introduction
The present clause defines scenarios where the sender and the entities at the receiving side are subscribed to the same
ERDS and consequently the user content is not relayed between different ERDSs.
Clause 5.3.2 defines scenarios where the ERDS operates in Store and Forward style.
Clause 5.3.3 defines scenarios where the ERDS operates in Store and Notify style.
5.3.2 Scenarios without notification for acceptance
Table 3 defines a number of scenarios for the case where sender and the entities at the receiving side are subscribed to
the same ERDS and the ERDS does not send notification for acceptance to the entities at the receiving side.

ETSI
13 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 3: Scenarios for intra-ERDS without notifications for acceptance (1/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#1 Purpose
Parameter: {hndvMet,XML_SUB_REJ} The simplest scenario: the
ERDS rejects the original
Sequence of actions
message submitted by the
# Sender ERDS Receiving side
sender and sends back a {ERDS
1 Sender sends original message
handover metadata,
Rejects submission. Generates XML_SUB_REJ
2  XML_SUB_REJ} structure
ERDS evidence
SubmissionRejection ERDS
Sends {hndvMet, XML_SUB_REJ} structure to the
3  evidence.
sender
Receives {hndvMet, XML_SUB_REJ}
structure
Table 3a: : Scenarios for intra-ERDS without notifications for acceptance (2/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#2 Purpose
Parameter: {hndvMet, user content} The simplest successful
scenario. The ERDS:
Parameter: XML_SUB_ACC
1. Accepts the submission of
Parameter: XML_CONT_CONS
the original message.
Sequence of actions
2. Generates the
# Sender ERDS Receiving side
SubmissionAcceptance
1 Sender sends original message
ERDS evidence, and stores
2 Accepts submission
it.
3 Generates and stores XML_SUB_ACC ERDS evidence
3. Aggregates the user content
4 Generates {hndvMet, user content} structure
to ERDS handover metadata
5 Consigns {hndvMet, user content} structure to the N
and performs as many
entities at the receiving side
consignments as required by
6 {hndvMet, user content} structure
the number of entities in the
correctly consigned to the N entities at
receiving side.
the receiving side
4. Generates the
ContentConsignment ERDS
Generates and stores XML_CONT_CONS ERDS evidence
evidence.
ETSI
14 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 3b: Scenarios for intra-ERDS without notifications for acceptance (3/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#3 Purpose
Parameter: {hndvMet, user content} The ERDS:
Parameter: XML_SUB_ACC 1. Accepts the submission of
the original message.
Parameter: XML_CONT_CONS
2. Generates the
Parameter: XML_CONT_HAND
SubmissionAcceptance
Sequence of actions
ERDS evidence, and stores
# Sender ERDS Receiving side
it.
1 Sender sends original message
3. Aggregates the user content
2 Accepts submission.
to ERDS handover metadata
3 Generates and stores XML_SUB_ACC ERDS
and performs as many
evidence
consignments as required by
4 Generates {hndvMet, user content} structure
the number of entities in the
5 Consigns {hndvMet, user content} structure to the N
receiving side.
entities at the receiving side
4. Generates the
6 {hndvMet, user content} structure
ContentConsignment ERDS
Generates and stores XML_CONT_CONS ERDS
correctly consigned to N entities at
evidence.
evidence
receiving side
5. All entities at receiving side
7 All the entities retrieve the ERD
successfully handover the
dispatch
consigned structure.
6. ERDS Generates and stores
Generates and stores XML_CONT_HAND ERDS N handovers of {hndvMet, user content} XML_CONT_HAND ERDS

evidence for the N handover and stores structure succeed
evidence for the N
handovers and stores.
ETSI
15 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 3c: Scenarios for intra-ERDS without notifications for acceptance (4/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#4 Purpose
Parameter: {hndvMet, user content} As scenario
Parameter: XML_SUB_ACC ERDS_BB_NO_NOT_F_ACC#3,
but one of the handing over fails.
Parameter: XML_CONT_HAND
Hereinafter, the scenarios do not
Parameter: XML_CONT_HAND_FAIL
show handing over, but only
Sequence of actions
consignment. However, a set of
# Sender ERDS Receiving side
scenarios including handing over
1 Sender sends original message
could be easily built based on
2 Accepts submission. Generates and stores
them.
XML_SUB_ACC ERDS evidence
3 Generates {hndvMet, user
content}structure
4 Consigns {hndvMet, user content}
structure to the N entities at the receiving
side
5 {hndvMet, user content} structure
Generates and stores XML_CONT_CONS
successfully consigned to N entities at
ERDS evidence
the receiving side
6 Entities try to retrieve the ERD

dispatch, but one fails
7 Generates one XML_CONT_HAND ERDS
evidence for N-1 entities and one N-1 handovers of {hndvMet, user

XML_CONT_HAND_FAIL ERDS evidence content} structure succeed. One fails
for one entity and stores them

ETSI
16 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 3d: Scenarios for intra-ERDS without notifications for acceptance (5/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#5 Purpose
Parameter: {hndvMet, user content, XML_SUB_ACC} As scenario
Parameter: XML_CONT_CONS ERDS_BB_NO_NOT_F_ACC#2
but now the ERDS builds a
Sequence of actions
structure with the user content
# Sender ERDS Receiving side
and the ERDS evidence, and
1 Sender sends the original message
consigns it to the receiving side.
2 Accepts submission.
3 Generates and stores XML_SUB_ACC ERDS evidence
4 Generates {hndvMet, user content, XML_SUB_ACC}

structure
5 Consigns <{hndvMet, user content, XML_SUB_ACC}

structure to the receiving side
6 {hndvMet, user content,
XML_SUB_ACC} structure successfully
Generates and stores XML_CONT_CONS ERDS evidence
consigned to the N entities at the
receiving side
7 Generates and stores XML_CONT_CONS ERDS evidence

ETSI
17 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 3e: Scenarios for intra-ERDS without notifications for acceptance (6/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#6 Purpose
Parameter: {hndvMet, user content} As scenario
Parameter: XML_SUB_ACC ERDS_BB_NO_NOT_F_ACC#2
but now the ERDS sends a
Parameter: {NotificationOfConsignment}
ERDS notification of
Parameter: XML_CONS_NOT
consignment to receiving side.
Parameter: XML_CONT_CONS
Sequence of actions
# Sender ERDS Receiving side
1 Sender sends the original message
2 Accepts submission. Generates and stores

XML_SUB_ACC ERDS evidence
Generates {hndvMet, user content} structure
5 Consigns hndvMet, user content} structure to receiving

side
6 {hndvMet, user content} structure
successfully consigned to the N entities
of the receiving side
7 Generates and stores XML_CONT_CONS ERDS

evidence
8 Generates {NotificationOfConsignment} for N entities
9 Sends {NotificationOfConsignment} to receiving side
10 {NotificationOfConsignment} received
Generates and stores XML_CONS_NOT ERDS evidence
by N entities at the receiving side

ETSI
18 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 3f: Scenarios for intra-ERDS without notifications for acceptance (7/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#7 Purpose
Parameter: {hndvMet, user content} As scenario
Parameter: XML_SUB_ACC ERDS_BB_NO_NOT_F_ACC#2
but now one of the ERDS
Parameter: {NotificationOfConsignment}
notification of consignment fails
Parameter: XML_CONS_NOT
Parameter: XML_CONS_NOT_FAIL
Sequence of actions
# Sender ERDS Receiving side
1 Sender sends the original message
2 Accepts submission
3 Generates and stores XML_SUB_ACC

ERDS evidence
4 Generates {hndvMet, user content}

structure for N entities at the receiving side
5 Consigns {hndvMet, user content}

structure to receiving side
6 N consignments of {hndvMet, user

content} structure succeed
7 Generates {NotificationOfConsignment} for

N entities in receiving side
8 Consigns {NotificationOfConsignment} for

N entities in receiving side but one fails
9 N-1 {NotificationOfConsignment} are
Generates and stores XML_CONS_NOT successfully received; one is not
received
10 Generates and stores one
XML_CONS_NOT_FAIL ERDS evidence

for one entity and XML_CONS_NOT
ERDS evidence for N-1 entities

ETSI
19 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 3g: Scenarios for intra-ERDS without notifications for acceptance (8/8)
Scenario id: ERDS_BB_NO_NOT_F_ACC#8 Purpose
Parameter: {hndvMet, user content} As scenario
Parameter: XML_SUB_ACC ERDS_BB_NO_NOT_F_ACC#2
but now one of the ERD dispatch
Parameter: XML_CONT_CONS
consignments fails
Parameter: XML_CONS_FAIL
Sequence of actions
# Sender ERDS Receiving side
1 Sender sends original message
2 Accepts submission.
3 Generates and stores XML_SUB_ACC ERDS evidence
4 Generates {hndvMet, user content} structure
5 Consigns {hndvMet, user content} structure to receiving

side
6 N-1 {hndvMet, user content} structures

are successfully consigned. One fails
7 Generates XML_CONT_CONS ERDS evidence for N-1
entities and one XML_ CONS_FAIL ERDS evidence for
one entity and stores them
ETSI
20 ETSI TS 119 524-2 V1.1.1 (2019-02)
5.3.3 Scenarios with notification for acceptance
Table 4 defines a number of scenarios for the case where sender and the entities at receiving side are subscribed to the same ERDS and the ERDS sends notification for
acceptance to the entities at the receiving side.
Table 4: Scenarios for intra-ERDS with notifications for acceptance (1/6)
Scenario id: ERDS_BB_NOT_F_ACC#1 Purpose
Parameter: {hndvMet, user content} First scenario where the ERDS
Parameter: {NotificationForAcceptance} asks to receiving side for
acceptance, and all the entities
Parameter: XML_NOT_F_ACC
at receiving side accept.
Parameter: XML_CONS_ACC
Parameter: XML_CONT_CONS
Sequence of actions
# Sender ERDS Receiving side
Sender sends original
message
2 Accepts submission
3 Generates and stores XML_SUB_ACC ERDS
...