ETSI GR MEC 017 V1.1.1 (2018-02)

Mobile Edge Computing (MEC); Deployment of Mobile Edge Computing in an NFV environment

DGR/MEC-0017MECinNFV

General Information

• Status: Published
• Publication Date: 20-Feb-2018
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 25-Feb-2018
• Completion Date: 21-Feb-2018

Standards Content (Sample)

GROUP REPORT
Mobile Edge Computing (MEC);
Deployment of Mobile Edge Computing in an NFV environment
Disclaimer
The present document has been produced and approved by the Mobile 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.

2 ETSI GR MEC 017 V1.1.1 (2018-02)

Reference
DGR/MEC-0017MECinNFV
Keywords
MEC, NFV
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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 2018.
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
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR MEC 017 V1.1.1 (2018-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 . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Introduction . 8
5 Reference Architecture . 8
5.1 Overview and assumptions . 8
5.2 MEC reference architecture in NFV environments . 9
5.3 Realization of the mobile edge platform as a VNF . 10
5.4 Realization of the Data Plane . 11
6 Key issues . 12
6.1 Issue #1: Mapping of ME app VNFs to Network Services . 12
6.1.1 Problem description . 12
6.1.2 Solution(s). 12
6.1.3 Evaluation . 13
6.1.4 Proposal . 13
6.2 Issue #2: Usage of NFV Network Service . 13
6.2.1 Problem description . 13
6.2.2 Solution(s). 14
6.2.3 Evaluation . 14
6.2.4 Proposal . 14
6.3 Issue #3: Communication between MEAO and NFVO via Mv1 . 14
6.3.1 Problem description . 14
6.3.2 Solution(s). 14
6.3.3 Evaluation . 16
6.3.4 Proposal . 16
6.4 Issue #4: Communication between VNFM and MEPM-V via Mv2 . 16
6.4.1 Problem description . 16
6.4.2 Solution(s). 16
6.4.3 Evaluation . 17
6.4.4 Proposal . 17
6.5 Issue #5: Communication between VNFM and ME app instance via Mv3. 18
6.5.1 Problem description . 18
6.5.2 Solution(s). 18
6.5.3 Evaluation . 18
6.5.4 Proposal . 19
6.6 Issue #6: AppD vs. VNFD for ME app VNFs . 19
6.6.1 Problem description . 19
6.6.2 Solution(s). 19
6.6.3 Evaluation . 20
6.6.4 Proposal . 20
6.7 Issue #7: VNF Package vs. MEC application package . 21
6.7.1 Problem description . 21
6.7.2 Solution(s). 21
6.7.3 Evaluation . 21
6.7.4 Proposal . 21
6.8 Issue #8: VNF package onboarding. 21
ETSI
4 ETSI GR MEC 017 V1.1.1 (2018-02)
6.8.1 Problem description . 21
6.8.2 Solution(s). 21
6.8.3 Evaluation . 22
6.8.4 Proposal . 22
6.9 Issue #9: Managing traffic redirection. 22
6.9.1 Problem description . 22
6.9.2 Solution(s). 23
6.9.3 Evaluation . 23
6.9.4 Proposal . 24
6.10 Issue #10: Comparison of AppD and VNFD data structures . 24
6.10.1 Problem description . 24
6.10.2 Solution(s). 24
6.10.3 Evaluation . 25
6.10.4 Proposal . 25
6.11 Issue #11: NFV construct that corresponds to Mobile Edge Host . 25
6.11.1 Problem description . 25
6.11.2 Solution(s). 26
6.11.3 Evaluation . 26
6.11.4 Proposal . 26
6.12 Issue #12 : ME App VNF Instance Relocation . 26
6.12.1 Problem description . 26
6.12.2 Solution(s). 26
6.12.3 Evaluation . 26
6.12.4 Proposal . 26
6.13 Issue #13: Application instantiation . 27
6.13.1 Problem description . 27
6.13.2 Solution(s). 27
6.13.3 Evaluation . 27
6.13.4 Proposal . 27
6.14 Issue #14: Application instance termination. 27
6.14.1 Problem description . 27
6.14.2 Solution(s). 28
6.14.3 Evaluation . 28
6.14.4 Proposal . 28
7 Recommendation . 28
7.1 Way forward . 28
7.2 Architecture impact . 29
7.3 Needed normative work . 29
7.3.1 General . 29
7.3.2 Normative work suggested to be performed in ETSI NFV . 29
7.3.3 Normative work suggested to be performed in ETSI MEC . 30
7.4 Items that require further study . 30
8 Conclusion . 31
History . 32

ETSI
5 ETSI GR MEC 017 V1.1.1 (2018-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 Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Mobile 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
6 ETSI GR MEC 017 V1.1.1 (2018-02)
1 Scope
The present document describes solutions that allow the deployment of MEC in a NFV environment. For each solution,
it describes the motivation for the solution, its architectural impacts and the necessary work to enable it. The document
provides recommendations as for where the specification work needs to be done.
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 NFV-MAN 001: "Network Functions Virtualisation (NFV); Management and
Orchestration".
[i.2] ETSI GS NFV-INF 003: "Network Functions Virtualisation (NFV); Infrastructure; Compute
Domain".
[i.3] ETSI GS NFV-INF 004: "Network Functions Virtualisation (NFV); Infrastructure; Hypervisor
Domain".
[i.4] ETSI GS NFV-INF 005: "Network Functions Virtualisation (NFV); Infrastructure; Network
Domain".
[i.5] ETSI GS MEC 003: "Mobile Edge Computing (MEC); Framework and Reference Architecture".
[i.6] ETSI GS NFV-IFA 013: "Network Functions Virtualisation (NFV); Management and
Orchestration; Os-Ma-Nfvo reference point - Interface and Information Model Specification".
[i.7] ETSI GS NFV-IFA 011: "Network Functions Virtualisation (NFV); Management and
Orchestration; VNF Packaging Specification".
[i.8] 3GPP TR 32.842: "Telecommunication management; Study on network management of
virtualised networks".
[i.9] ETSI GS NFV-IFA 009: "Network Functions Virtualisation (NFV); Management and
Orchestration; Report on Architectural Options".
[i.10] ETSI GS MEC 010-2: "Mobile Edge Computing (MEC); Mobile Edge Management; Part 2:
Application lifecycle, rules and requirements management".
[i.11] ETSI GS NFV-IFA 014: "Network Functions Virtualisation (NFV); Management and
Orchestration; Network Service Templates Specification".
[i.12] ETSI GS NFV-IFA 008: "Network Functions Virtualisation (NFV); Management and
Orchestration; Ve-Vnfm reference point - Interface and Information Model Specification".
ETSI
7 ETSI GR MEC 017 V1.1.1 (2018-02)
[i.13] ETSI GS MEC 010-1: "Mobile Edge Computing (MEC); Mobile Edge Management; Part 1:
System, host and platform management".
[i.14] ETSI GS NFV-SOL 002: "Network Functions Virtualisation (NFV); Protocols and Data Models;
RESTful protocols specification for the Ve-Vnfm Reference Point".
[i.15] IETF RFC 6241: "Network Configuration Protocol (NETCONF)".
[i.16] IETF RFC 8040: "RESTCONF Protocol".
[i.17] ETSI GS MEC 002: "Mobile Edge Computing (MEC); Technical Requirements".
[i.18] ETSI GS NFV-IFA 006: "Network Functions Virtualisation (NFV); Management and
Orchestration; Vi-Vnfm reference point - Interface and Information Model Specification".
[i.19] ETSI GS NFV-IFA 007: "Network Functions Virtualisation (NFV); Management and
Orchestration; Or-Vnfm reference point - Interface and Information Model Specification".
[i.20] ETSI GS NFV-IFA 018: "Network Functions Virtualisation (NFV); Acceleration Technologies;
Network Acceleration Interface Specification; Release 3".
[i.21] OpenStack documentation, Service function chaining.
NOTE: Available at: https://docs.openstack.org/newton/networking-guide/config-sfc.html.
[i.22] ETSI GS NFV-SOL 005: "Network Functions Virtualisation (NFV) Release 2; Protocols and Data
Models; RESTful protocols specification for the Os-Ma-nfvo Reference Point".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
ME app VNF: mobile edge application that appears like a VNF towards the ETSI NFV MANO components
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
DNS Domain Name System
DOPFR Dynamic Optimization of Packet Flow Routing
EM Element Manager
ETSI European Telecommunications Standards Institute
GS Group Specification
GTP GPRS Tunnelling Protocol
HOT Heat Orchestration Template
IP Internet Protocol
LCM Life Cycle Management
MANO Management and Orchestration
ME Mobile Edge
MEAO Mobile Edge Application Orchestrator
MEC Mobile Edge Computing
MEO Mobile Edge Orchestrator
MEPM Mobile Edge Platform Manager
MEPM-V Mobile Edge Platform Manager - NFV
NFP Network Forwarding Path
NFV Network Functions Virtualisation
NFVI Network Functions Virtualisation Infrastructure
NFVO Network Functions Virtualisation Orchestrator
ETSI
8 ETSI GR MEC 017 V1.1.1 (2018-02)
NS Network Service
NSD Network Service Descriptor
OASIS Organization for the Advancement of Structured Information Standards
OSS Operations Support System
PM Performance Management
PNF Physical Network Function
PNFD Physical Network Function Descriptor
PoP Point of Presence
QCI Quality Class Indicator
SFC Service Function Chaining
SPID Subscriber Profile ID
TEID Tunnel Endpoint ID
TOSCA Topology and Orchestration Specification for Cloud Applications
UE User Equipment
VIM Virtualised Infrastructure Manager
VL Virtual Link
VM Virtual Machine
VNF Virtualised Network Function
VNFC VNF Component
VNFD VNF Descriptor
VNFFG VNF Forwarding Graph
VNFM Virtual Network Function Manager
YAML YAML Ain't Markup Language
4 Introduction
Mobile network operators are expected to virtualise their networks using Network Functions Virtualisation (NFV), and
want to use the introduced virtualisation infrastructure to consolidate network elements (Virtualised Network Functions
- VNFs), Mobile Edge Computing (MEC) components and Mobile Edge (ME) applications on top of that infrastructure.
Sharing the introduced elements (infrastructure, but also management functions) to the maximum possible degree
allows to make maximum use of the investments into virtualisation. The present document will analyse different
scenarios of MEC deployments in NFV environments w.r.t. their architectural impact and the needed specification
work. The present document will help to identify normative specification work to enable MEC deployments in NFV
environments. It will also help operators that plan to deploy MEC and NFV feature at the same time, to make the right
decision by providing detailed information around solution aspects.
5 Reference Architecture
5.1 Overview and assumptions
This clause defines a reference architecture of how ETSI MEC can be deployed in a NFV environment. The basic
assumptions are:
1) The ME platform is deployed as a VNF. For that purpose, the procedures defined by ETSI NFV are used. It is
not expected that these procedures need to be modified for use with ETSI MEC. Clause 5.2 further elaborates
on this.
2) The ME applications appear like VNFs towards the ETSI NFV MANO components. This allows re-use of
ETSI NFV MANO functionality. It is, however, expected that ETSI MEC might not use the full set of MANO
functionality, and requires certain additional functionality. Such a specific ME application is denoted by the
name "ME app VNF" in the remainder of the present document.
3) The virtualisation infrastructure is deployed as a NFVI and its virtualised resources are managed by the VIM.
For that purpose, the procedures defined by ETSI NFV Infrastructure specifications, i.e. ETSI
GS NFV-INF 003 [i.2], ETSI GS NFV-INF 004 [i.3], ETSI GS NFV-INF 005 [i.4], can be used. It is not
expected that these procedures need to be modified for use with ETSI MEC.
ETSI
9 ETSI GR MEC 017 V1.1.1 (2018-02)
5.2 MEC reference architecture in NFV environments
It is assumed that the ME app VNFs will be managed like individual VNFs, allowing that a MECinNFV deployment
can delegate certain orchestration and Life Cycle Management (LCM) tasks to the NFVO and VNFM functional blocks,
as defined by ETSI NFV MANO.
One goal of the present study is to describe that actual mapping, to elaborate on a high level how MEC orchestration
procedures and ME application LCM procedures can be realized in such an environment.
The Mobile Edge Platform Manager (MEPM), as defined in the MEC reference architecture ETSI GS MEC 003 [i.5], is
transformed into a "Mobile Edge Platform Manager - NFV" (MEPM-V) that delegates the LCM part to one or more
VNFM(s). The Mobile Edge Orchestrator (MEO), as defined in the MEC reference architecture ETSI GS MEC 003
[i.5], is transformed into a "Mobile Edge Application Orchestrator" (MEAO) that uses the NFVO for resource
orchestration, and for orchestration of the set of ME app VNFs as one or more NFV Network Services (NSs).
Figure 5.2-1 illustrates the realization of the ETSI MEC reference architecture in an ETSI NFV environment.

Figure 5.2-1: MEC reference architecture in a NFV environment
NOTE 1: It is assumed that the Mobile Edge Platform VNF, the MEPM-V and VNFM (ME platform LCM) will be
deployed as a single package as per the ensemble concept in 3GPP TR 32.842 [i.8], or that the VNFM is a
Generic VNFM as per ETSI GS NFV-IFA 009 [i.9] and the Mobile Edge Platform VNF and the
MEPM-V are provided by a single vendor.
ETSI
10 ETSI GR MEC 017 V1.1.1 (2018-02)
NOTE 2: The Mp1 reference point between an ME application and the ME platform is optional for the ME
application, unless it is an application that provides and/or consumes a ME service (ETSI GS MEC 003
[i.5], Figure 6-1).
NOTE 3: The Mm3* reference point between MEAO and MEPM-V is based on the Mm3 reference point, as
defined by ETSI GS MEC 003 [i.5]. Changes will be needed to this reference point to cater for the split
between MEPM-V and VNFM (ME applications LCM).
The following new reference points (Mv1, Mv2 and Mv3) are introduced between elements of the ETSI MEC
architecture and the ETSI NFV architecture to support the management of ME app VNFs. These are related to existing
NFV reference points, but it is expected that only a subset of the functionality will be used for ETSI MEC, and that
extensions may be necessary:
• Mv1: This reference point connects the MEAO and the NFVO. It is related to the Os-Ma-nfvo reference point,
as defined in ETSI NFV.
• Mv2: This reference point connects the VNF Manager that performs the LCM of the ME app VNFs with the
MEPM-V to allow LCM related notifications to be exchanged between these entities. It is related to the Ve-
Vnfm-em reference point as defined in ETSI NFV, but will possibly include additions, and might not use all
functionality offered by Ve-Vnfm-em.
• Mv3: This reference point connects the VNF Manager with the ME app VNF instance, to allow the exchange
of messages e.g. related to ME application LCM or initial deployment-specific configuration. It is related to
the Ve-Vnfm-vnf reference point, as defined in ETSI NFV, but will possibly include additions, and might not
use all functionality offered by Ve-Vnfm-vnf.
The following reference points are used as they are defined by ETSI NFV:
• Nf-Vn: This reference point connects each ME app VNF with the NFVI.
• Nf-Vi: This reference point connects the NFVI and the VIM.
• Os-Ma-nfvo: This reference point connects the OSS and the NFVO. It is primarily used to manage NSs, i.e. a
number of VNFs connected and orchestrated to deliver a service.
• Or-Vnfm: This reference point connects the NFVO and the VNFM. It is primarily used for the NFVO to
invoke VNF LCM operations.
• Vi-Vnfm: This reference point connects the VIM and the VNFM. It is primarily used by the VNFM to invoke
resource management operations to manage the cloud resources that are needed by the VNF. It is assumed in a
NFV-based MEC deployment that this reference point corresponds 1:1 to Mm6.
• Or-Vi: This reference point connects the NFVO and the VIM. It is primarily used by the NFVO to manage
cloud resources capacity.
5.3 Realization of the mobile edge platform as a VNF
It is assumed that the ME platform will be realized as a VNF and will be managed according to ETSI NFV procedures.
It is not assumed that ETSI MEC needs to define any modification to this.
This means:
• the MEPM-V will act as the Element Manager (EM) of the ME platform VNF;
• a VNF Manager, according to ETSI NFV (e.g. Specific VNFM, Generic VNFM), is used to perform LCM of
the ME platform VNF;
• the scope of the Mp2 reference point will need to be redefined. ETSI GS MEC 003 [i.5] states that this
reference point is considered outside the scope of standardization but the introduction of the ME platform as a
VNF introduces a potential multivendor deployment of the ME Platform VNF and the NFVI, which contains
the Data Plane.
Figure 5.3-1 illustrates this set-up, mapping the applicable components into the ETSI NFV MANO architecture defined
in ETSI GS NFV-MAN 001 [i.1].
ETSI
11 ETSI GR MEC 017 V1.1.1 (2018-02)
Operations Support System NFVO
Os-Ma-nfvo
Mm2
Or-Vnfm
Ve-Vnfm-em
MEPM-V (EM)
Mm5 VNFM
Mobile edge
platform (VNF)
Ve-Vnfm-vnf
Vn-Nf
Vi-Vnfm
NFVI VIM
Nf-Vi
Figure 5.3-1: Management of the ME platform as a VNF
The following reference points are used as they are defined by ETSI NFV:
• Ve-Vnfm-em: This reference point connects the VNF Manager (VNFM) that manages the lifecycle of the ME
platform with the Mobile Edge Platform Manager - NFV (MEPM-V). It is the Ve-Vnfm-em reference point as
defined in ETSI NFV. Since the Mobile Edge Platform VNF is considered as a network function, it is not
expected that there are any impacts to the Ve-Vnfm-em procedures as defined by ETSI NFV.
• Ve-Vnfm-vnf: This reference point connects the VNFM that manages the lifecycle of the ME platform with
the Mobile Edge Platform VNF. It is the Ve-Vnfm-vnf reference point as defined in ETSI NFV. Since the
Mobile Edge Platform VNF is considered as a network function, it is not expected that there are any impacts to
the Ve-Vnfm-vnf procedures as defined by ETSI NFV.
• Nf-Vn: This reference point connects the Mobile Edge Platform VNF and the NFVI.
• Nf-Vi: This reference point connects the NFVI and the VIM.
• Os-Ma-nfvo: This reference point connects the OSS and the NFVO. It is primarily used to manage NSs, i.e. a
number of VNFs connected and orchestrated to deliver a service.
• Or-Vnfm: This reference point connects the NFVO and the VNFM that manages the lifecycle of the ME
platform. It is primarily used for the NFVO to invoke VNF LCM operations.
• Vi-Vnfm: This reference point connects the VIM and the VNFM that manages the lifecycle of the ME
platform. It is primarily used by the VNFM to invoke resource management operations to manage the cloud
resources that are needed by the VNF.
• Or-Vi: This reference point connects the NFVO and the VIM. It is primarily used by the NFVO to manage
cloud resources capacity.
5.4 Realization of the Data Plane
When MEC is deployed in a NFV environment, there are two different possibilities to realize the Data Plane, both are
valid and need to be supported.
Option 1: Realize the Data Plane as a PNF or VNF or combination thereof, and connect it to the NS that contains the
ME app VNFs. In this option, Mp2 is kept as a MEC-internal reference point also in the NFV-based deployment of
MEC; the option is agnostic to the way MEC is deployed.
ETSI
12 ETSI GR MEC 017 V1.1.1 (2018-02)
Option 2: For performance enhancements, it can make sense to re-use the SFC functionality provided by the underlying
NFVI for traffic routing. In such a deployment, the Data Plane as a dedicated component is not needed, and
consequently, also the Mp2 reference point does not exist. The SFC functionality in the NFVI will be configured by the
NFVO in the VIM based on the NFP of the NFV NS, using the Or-Vi reference point. The MEAO will need to translate
the traffic rules into an NFP and send it to the NFVO. The ME platform will not control the traffic redirection directly
via Mp2 will pass requests to activate / deactivate / update for traffic rules to the MEPM-V which will forward them to
the MEAO. When receiving such a request, the MEAO will request the NFVO to update the NFP accordingly.
6 Key issues
6.1 Issue #1: Mapping of ME app VNFs to Network Services
6.1.1 Problem description
As indicated in point 2 of clause 5.1, the ME applications appear like VNFs towards the ETSI NFV MANO
components. As stated in clause 5.2:
• The Mobile Edge Orchestrator (MEO), as defined in the MEC reference architecture ETSI GS MEC 003 [i.5],
is transformed into a "Mobile Edge Application Orchestrator" (MEAO) that uses the NFVO for resource
orchestration, and for orchestration of the set of ME app VNFs as one or more NFV NSs.
This is consistent with how NFV conceptualizes NFVO: as an entity that operates on NSs. For example,
ETSI GS NFV-IFA 013 [i.6], Annex A states as "Principle #3":
• With respect to the Os-Ma-nfvo reference point, any interaction concerning a VNF is associated with at least
one NS instance.
The issue is related to the mapping of ME app VNFs to NFV NSs. The MEAO would need to have a mapping from ME
app VNFs to NSs.
The assumption is that Mv1 looks similar to Os-Ma-nfvo and that MEAO is creating the needed NSs for the ME app
VNFs.
This assumption should be clearly stated in the document and the mapping of NS to ME app VNFs be explained.
Functional blocks of the architecture request the creation/LCM of ME app VNF instances from the MEAO using the 2
reference points Mm1 and Mm9.
The Mm1 reference point between the MEO and the OSS is used for triggering the instantiation and the termination of
ME app VNFs in the ME system.
The Mm9 reference point between the user application LCM proxy and the MEO of the ME system is used to manage
ME applications requested by UE application.
None of those 2 reference points are dealing with services, while the MEAO would need NS knowledge, as well as the
mapping of ME app VNF to NS.
6.1.2 Solution(s)
It is assumed that the MEAO would perform the following tasks:
1) Request the NFVO to set one or more NSs to manage the ME app VNFs, which includes:
Generation and onboarding of an NSD
Requesting the instantiation of a NS
2) When a new ME app VNF package is onboarded:
Updating of the NSD to reference the new package, and onboarding of the updated NSD
ETSI
13 ETSI GR MEC 017 V1.1.1 (2018-02)
3) When the instantiation of a ME app VNF is requested (see also key issue #13):
Request the NFVO to perform the UpdateNs operation, adding a new ME app VNF instance, and possibly, if
the ME app VNF package was not included in the NSD on which the NS is built, updating the NS to use
the new updated NSD
Once this was successful, trigger the MEPM-V to perform additional configuration
4) When the termination of a ME app VNF is requested (see also key issue #14):
Request the NFVO to perform the UpdateNs operation, removing the ME app VNF instance
The MEAO would need to track for every ME app VNF instance the following information:
1) Identifier NS instance of which the ME app instance is part
2) Identifier of the ME app VNF instance
3) Responsible MEPM-V instance
4) Responsible MEC Platform instance
This information can be obtained for various sources:
• 1) is available to the MEAO as part of managing the NSs
• 2) is available via notifications on Mv1 regarding the result of the UpdateNs operation
• 3) can be derived from 4)
• 4) is configured into the ME app VNF instance upon instantiation, as per decision of the MEAO
6.1.3 Evaluation
The solution described above allows to manage a ME app VNF instance as part of a NS. Creating and terminating ME
app VNF instances always includes the NFVO in the path that the request travels, thereby mixing aspects of host-level
management and system-level management. This is an inherent consequence of the choice to manage ME app VNFs as
VNFs, which means that they have to be part of a NS when using ETSI NFV. As NSs are managed in NFV by the
orchestration layer, the orchestrator needs to be involved in every single ME app instantiation, and there is not much
that can be done about it in the chosen "MECinNFV" architectural framework.
6.1.4 Proposal
It is suggested that the MEAO arranges with the NFVO via Mv1 to manage the ME app VNF instances as part of one or
more NSs.
6.2 Issue #2: Usage of NFV Network Service
6.2.1 Problem description
NFV decouples software implementations of Network Functions from the computation, storage, and networking
resources they use. The virtualisation insulates the Network Functions from those resources through a virtualisation
layer. VNFs can be chained with other VNFs and/or Physical Network Functions (PNFs) to realize a NS.
As defined in the ETSI GS NFV-IFA 014 [i.11], the NS describes the relationship between VNFs and possibly PNFs
that it contains and the links needed to connect VNFs that are implemented in the NFVI network. Besides the VNF
information, the NS information element also includes PNF information element, Virtual Link (VL) information
element and VNF Forwarding Graph (VNFFG) information element. The VNFFG describes the topology of the NS by
referencing VNFs and PNFs and VLs that connect them.
ETSI
14 ETSI GR MEC 017 V1.1.1 (2018-02)
The Network Service Descriptor (NSD) can also be used to describe dependencies between VNFs, e.g. to ensure the
ME Platform VNF is instantiated before any ME App VNF that uses it is instantiated.
In the present document, the concept of NS needs to be considered to deploy MEC in a NFV environment. Besides
describing the dependencies between VNFs, it also defines the topology of the connections between the VNFs using the
VNFFG.
6.2.2 Solution(s)
It is recommended to introduce the NS concept in support of MEC deployment in NFV environment, while keeping the
assumptions that both ME platform and ME applications are considered VNFs. The set of ME platform VNF and ME
app VNFs can be grouped into one or more (possibly nested) NSs. In an example deployment, a NS could contain a ME
platform VNF and one or more ME app VNFs, with which the following scenarios can be addressed:
• the dependency between a ME app VNF and the ME platform VNF serving it are defined in the NSD;
• the connectivity between ME app VNFs, and/or between ME app VNFs and the ME platform VNF, are
defined in the VNFFG.
The service chaining aspects between multiple ME app VNFs are to be determined. It is further to be determined how to
realize MEC in a NFV environment with multiple NFVI Points of Presence (PoPs), and how the service chaining works
in such environment.
It is also to be determined whether or not additional functions would be needed for the NS defined in ETSI ISG NFV.
6.2.3 Evaluation
The conception of NS needs to be introduced to represent MEC in NFV. Further investigation should identify any
additional functions needed for the NS defined in ETSI ISG NFV.
6.2.4 Proposal
Use the concept of NSs to represent the set of ME app VNFs and ME platform VNFs and their
interconnection/dependency.
It is to be determined if updates to the NSD and to the NS LCM procedures in ETSI NFV are required to address
specific MEC use cases such as mobility.
6.3 Issue #3: Communication between MEAO and NFVO via
Mv1
6.3.1 Problem description
The Mv1 reference point needs to allow the MEAO to invoke operations towards the NFVO to manage ME app VNFs.
It also needs to allow the MEAO to onboard ME application packages into the NFVO. According to ETSI NFV
standards, VNFs are always included in NSs (se
...