ETSI GR MEC-DEC 025 V2.1.1 (2019-06)

Multi-access Edge Computing (MEC); MEC Testing Framework

DGR/MEC-DEC25TestingFramework

General Information

• Status: Published
• Publication Date: 23-Jun-2019
• Technical Committee: MEC DECODE - Deployment and ECOsystem DEvelopment
• Current Stage: 12 - Completion
• Due Date: 20-Jun-2019
• Completion Date: 24-Jun-2019

Standards Content (Sample)

ETSI GR MEC-DEC 025 V2.1.1 (2019-06)






GROUP REPORT
Multi-access Edge Computing (MEC);
MEC Testing Framework
Disclaimer
The present document has been produced and approved by the Multi-access Edge Computing (MEC) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

---------------------- Page: 1 ----------------------
2 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)



Reference
DGR/MEC-DEC25TestingFramework
Keywords
MEC, testing

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

---------------------- Page: 2 ----------------------
3 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
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 . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Testing Methodology Guidelines for MEC . 8
4.1 Introduction . 8
4.2 Basic concepts for conformance and interoperability testing . 9
4.3 Conformance Test Specifications . 9
4.3.1 Introduction. 9
4.3.2 Test architecture . 10
4.3.2.1 Selection of Implementation Under Test. 10
4.3.2.1.1 Definition. 10
4.3.2.1.2 MEC IUTs and Reference Points . 11
4.3.3 Development of Conformance Test Specifications . 11
4.3.3.1 Implementation Conformance Statement (ICS) . 11
4.3.3.2 Test Suite Structure & Test Purposes (TSS&TP). 12
4.3.3.2.1 Introduction . 12
4.3.3.2.2 Test Suite Structure . 12
4.3.3.2.3 Test Purpose . 13
4.3.3.2.4 Conventions for the expected behaviour in Test Purposes . 14
4.3.3.3 Abstract Test Method (ATM) . 15
4.3.3.3.1 Methodology . 15
4.3.3.3.2 Abstract PDU Transport Protocol . 16
4.4 Interoperability Test Specifications . 16
4.4.1 Introduction. 16
4.4.2 Basic concepts for interoperability testing . 16
4.4.3 Interoperability Test Specifications . 17
4.4.4 Interoperability Testing Process . 19
4.5 Interoperability Test Process . 19
5 Requirement assessment. 20
5.1 Introduction . 20
5.2 Generic requirements . 20
5.2.1 Framework Requirements . 20
5.2.2 Application lifecycle . 20
5.2.3 Applications environment . 20
5.2.4 Support of mobility . 21
5.3 Services requirements . 21
5.3.1 Platform essential functionality . 21
5.3.1.1 Mobile edge services . 21
5.3.1.2 Connectivity . 21
5.3.1.3 Storage . 21
5.3.1.4 Traffic routing . 22
5.3.1.5 DNS support . 22
5.3.1.6 Timing . 22
5.3.2 Features . 22
5.3.2.1 Feature UserApps . 22
5.3.2.2 Feature SmartRelocation . 23
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
5.3.2.3 Feature RadioNetworkInformation . 23
5.3.2.4 Feature LocationService . 23
5.3.2.5 Feature BandwidthManager . 24
5.3.2.6 Feature UEIdentity . 24
5.4 Operation and management requirements . 24
5.5 Security, regulation, charging requirements . 24
6 Architecture assessment . 25
6.1 MEC components compliance . 25
6.1.1 Mobile Edge Platform Manager. 25
6.1.2 Mobile Edge Orchestrator . 25
6.1.3 MEC Platform . 25
6.1.4 MEC Apps . 26
Annex A: Conformance Test Purposes examples . 27
A.1 Examples of test purposes . 27
A.1.1 Introduction . 27
A.1.2 Example of test purpose for querying DNS rules . 27
A.1.3 Example of test purpose for notification of an App Package enablement . 28
A.1.4 Example of test purpose for malformed App Package creation . 29
A.1.5 Example of test purpose for unauthorized creation of App Package . 30
Annex B: Interoperability Test Descriptions examples . 31
B.1 Examples of test descriptions for interoperability . 31
B.1.1 Introduction . 31
B.1.2 Example of test description for Mobile radio network information (TD_MEC002_A2) . 31
B.1.3 Example of test description for active device location tracking (TD_MEC002_A7) . 32
B.1.4 Example of test description for Edge data orchestration (TD_MEC002_A10) . 32
Annex C: Change History . 34
Annex D: Bibliography . 35
History . 36


ETSI

---------------------- Page: 4 ----------------------
5 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
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 Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge Computing
(MEC).
Modal verbs terminology
In the present document "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

---------------------- Page: 5 ----------------------
6 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
1 Scope
The present document lists the functionalities and capabilities required by a MEC compliant implementation. In
addition, the present document specifies a testing framework defining a methodology for development of
interoperability and/or conformance test strategies, test systems and the resulting test specifications for MEC standards.
In additional, the testable requirements are listed and prioritized.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
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 GS MEC 012: "Multi-access Edge Computing (MEC); Radio Network Information API".
[i.2] ETSI GS NFV-TST 002: "Network Functions Virtualisation (NFV); Testing Methodology; Report
on NFV Interoperability Testing Methodology".
[i.3] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
[i.4] ISO/IEC 9646-7:1995: "Information technology -- Open Systems Interconnection -- Conformance
testing methodology and framework -- Part 7: Implementation Conformance Statements".
NOTE: Available at https://www.iso.org/standard/3084.html.
[i.5] ISO/IEC 9646-1:1994: "Information technology -- Open Systems Interconnection -- Conformance
testing methodology and framework -- Part 1: General concepts".
NOTE: Available at https://www.iso.org/standard/17473.html.
[i.6] TTCN-3 abstract test language.
NOTE: Available at http://www.ttcn-3.org/index.php/downloads/standards.
[i.7] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[i.8] ETSI GS MEC 010-1: "Mobile Edge Computing (MEC); Mobile Edge Management;
Part 1: System, host and platform management".
[i.9] ETSI GS MEC 010-2: "Multi-access Edge Computing (MEC); MEC Management;
Part 2: Application lifecycle, rules and requirements management".
[i.10] ETSI GS MEC 011: "Multi-access Edge Computing (MEC); Edge Platform Application
Enablement".
[i.11] ETSI GS MEC 013: "Multi-access Edge Computing (MEC); Location API".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
[i.12] ETSI GS MEC 014: "Mobile Edge Computing (MEC); UE Identity API".
[i.13] ETSI GS MEC 015: "Mobile Edge Computing (MEC); Bandwidth Management API".
[i.14] ETSI GS MEC 016: "Multi-access Edge Computing (MEC); UE application interface".
[i.15] ETSI Test Description Language.
NOTE: Available at https://tdl.etsi.org/index.php/downloads.
[i.16] ETSI GS MEC 001: "Multi-access Edge Computing (MEC); Terminology".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS MEC 001 [i.16] and the following apply:
certification/compliance assessment: major goal of a compliance assessment is to ensure the interoperability of
implementations, and the conformance of implementations to the standard
conformance testing: purpose of conformance testing is to determine to what extent a single implementation of a
particular standard conforms to the individual requirements of that standard
interoperability testing: purpose of interoperability testing is to prove that end-to-end functionality between (at least)
two communicating systems is as required by the standard(s) on which those systems are based
Test Case (TC): complete and independent specification of the actions required to achieve a specific Test Purpose
NOTE: TCs are written in testing languages, e.g. TTCN-3.
Test Descriptions (TD): specify the sequence of actions required to realize the verdict identified in the TP and are
primarily intended for use in interoperability test specifications
NOTE: However, in some instances, particularly where there is a considerable difference in complexity between
the TPs and the TCs, it is worthwhile adding TDs as an extra design stage in a conformance test
specification.
Test Purpose (TP): should be written for each potential test of each identified requirement
NOTE: A TP defines in broad terms what the goal of a particular test should be. A TP is defined in prose.
test suite: collection of Test Cases
testing framework: provides guidance for development of conformance and interoperability test strategies, test
systems and the resulting test specifications
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [i.16] and the following apply:
API Application Programming Interface
ATM Abstract Test Method
ATS Abstract Test Suite
BWMS BandWidth Management Service
CON CONformance
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
CRS Conformance Requirement Statements
DUT Device Under Test
FUT Function Under Test
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
ICS Implementation Conformance Statement
IFS Interoperability Feature Statement
IOP InterOPerability
IUT Implementation Under Test
MEH MEC Host
OAM Operations And Maintaince
PDU Packet Data Unit
PICS Protocol Implementation Conformance Statement
PLMN Public Land Mobile Network
RAB Radio Access Bearer
RNI Radio Network Information
RNIS RNI Service
RP Reference Point
SAQ Service Availability Query
SUT System Under Test
TC Test Case
TCP Transmission Control Protocol
TDL Test Description Lanaguage
TP Test Purpose
TSS Test Suite Structure
TTCN Testing and Test Control Notation
URI Uniform Resource Identifier
4 Testing Methodology Guidelines for MEC
4.1 Introduction
Clause 4 provides:
• Identification of the implementations under test (IUT) for conformance testing and the device under test
(DUTs) for interoperability, i.e. answering the question "what is to be tested".
• Definition of the applicable test procedures, i.e. answering the question "how is it to be tested".
• Definition of the procedure for development of test specifications and deliverables (for instance: Test Purposes
(TP) in case of conformance testing and Test Descriptions (TD) in case of interoperability testing,
documentation, etc.).
The MEC testing framework contains:
• a documentation structure:
- catalogue of capabilities/features/functions (PICS or IFS);
- Test Suite Structure (TSS);
- individual tests in the form of TPs (Conformance) or TDs (Interoperability);
• a methodology linking the individual elements of a test specification together:
- style guidelines and examples;
- naming conventions;
- a structured notation for TPs or TDs.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
4.2 Basic concepts for conformance and interoperability testing
Conformance Testing and Interoperability Testing are the two main and complementary testing methodologies to test
devices implementing standardized services [i.2]. These two testing methodologies also apply to MEC.
The basic concepts for Conformance Testing and Interoperability Testing are defined as follows:
• Conformance Testing can show that a product correctly implements and meets the requirements in the ETSI
ISG MEC standards, which will include testing protocol message contents and formats as well as the permitted
sequence of messages for the interfaces defined by ETSI ISG MEC standards.
• Interoperability Testing can demonstrate that a product will work with other alike products. It proves that
end-to-end functionality between (at least) two functional elements is as required by the ETSI MEC
standards on which those functions are based.
For more details about the basic concepts for conformance and interoperability testing, please refer to clause 4.1 of
ETSI GS NFV-TST 002 [i.2].
4.3 Conformance Test Specifications
4.3.1 Introduction
Clause 4.3 explains how to apply the MEC conformance testing methodology in order to properly produce MEC
conformance test specifications.
The conformance testing can show that a product correctly implements a particular standardized protocol, that is, it
establishes whether or not the implementation under test meets the requirements specified for the protocol itself.
EXAMPLE: The scope of the testing is on protocol message content, format as well as the permitted sequences
of messages. In that context, tests are performed at open standardized interfaces that are not
(usually) accessible to an end user, and executed by a dedicated test system that has full control of
the system under test and the ability to observe all incoming and out coming communications; the
high degree of control of the test system over the sequence and contents of the protocol messages
allows to test both valid and invalid behaviour.

Figure 4.3.1-1: Conformance testing
Conformance test specifications should be produced following the methodology described in ISO/IEC 9646-1 [i.5]. In
summary, this methodology begins with the collation and categorization of the features and options to be tested into a
tabular form which is normally referred to as the "Implementation Conformance Statement" (ICS). All implemented
capabilities supported by the Implementation Under Test (IUT) are listed by the implementer in the ICS, so that the
tester knows which options have to be tested. This ensures that complete coverage is obtained.
The next step is to collect the requirements from the specification that is tested. For each requirement, one or more tests
should be identified and classified into a number of groups which will provide a structure to the overall test suite (TSS).
A brief Test Purpose (TP) should then be written for each identified test and this should make it clear what is to be
tested but not how this should be done. Finally, a detailed Test Case (TC) is written for each TP. In the interests of test
automation, TCs are usually combined into an Abstract Test Suite (ATS) using a specific testing language such as
TTCN-3 or others. The TCs in the ATS are then "Verified" against a number of IUTs for correct operation according to
some agreed procedures, before being released for use by the industry.
In summary, the MEC Conformance Testing methodology consists of:
• Selection of Implementations Under Test (IUT).
• Identification of reference points.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
• Development of test specifications, which includes:
- Development of "Implementation Conformance Statements" (ICS).
- Development of "Test Suite Structure and Test Purposes" (TSS&TP).
- Development of "Abstract Test Suite" (ATS).
4.3.2 Test architecture
4.3.2.1 Selection of Implementation Under Test
4.3.2.1.1 Definition
The "Implementation Under Test" (IUT) is a protocol implementation considered as an object for testing. This means
that the test process will focus on verifying the compliance of this protocol implementation (IUT) with requirements set
up in the related base standard. An IUT normally is implemented in a "System Under Test" (SUT). For testing, a SUT is
connected to a test system over at least a single interface. Such an interface is identified as "Reference Point" (RP) in
the present document. Further details on RPs are presented in clause 6.
NOTE: Other interfaces between the test system and the IUT may be used to control the behaviour of the IUT
during the test process.
Figure 4.3.2.1.1-1 shows the multi-access edge system reference architecture, see also clause 6 of ETSI
GS MEC 003 [i.3].

Figure 4.3.2.1.1-1: Multi-access edge system reference architecture
ETSI

---------------------- Page: 10 ----------------------
11 ETSI GR MEC-DEC 025 V2.1.1 (2019-06)
4.3.2.1.2 MEC IUTs
...