ETSI GR MEC 038 V3.1.1 (2022-11)

Multi-access Edge Computing (MEC); MEC in Park Enterprises deployment scenario

DGR/MEC-0038ParkEnterprises

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 24-Nov-2022
• Completion Date: 17-Nov-2022

Standards Content (Sample)

GROUP REPORT
Multi-access Edge Computing (MEC);
MEC in Park Enterprises deployment scenario
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.

2 ETSI GR MEC 038 V3.1.1 (2022-11)

Reference
DGR/MEC-0038ParkEnterprises
Keywords
authentication, EDGE, location, MEC, UE identity

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

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2022.
All rights reserved.
ETSI
3 ETSI GR MEC 038 V3.1.1 (2022-11)
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 Overview . 8
5 Key issues and potential solutions . 8
5.1 Key issue #1: ULCL PSA insertion based on Location . 8
5.1.1 Description . 8
5.1.2 Solution proposal #1: AF detecting UE Location and report to PCF . 9
5.1.2.1 Description . 9
5.1.2.2 Backgrounds. 9
5.1.2.2.1 NEF service operations information flow . 9
5.1.2.2.2 The relationship between AF and MEC system . 12
5.1.2.3 AF requests to influence traffic routing for Sessions based on location detection . 12
5.1.3 Solution proposal #2: SMF detecting UE Location changing . 14
5.1.4 Evaluation . 14
5.2 Key issue #2: Unified AAA management of MEC system . 14
5.2.1 Description . 14
5.2.2 Solution proposal #1: Using UE Identity API . 15
5.2.3 Solution proposal #2: DN-AAA triggers Secondary authentication/authorization when ULCL
inserting . 16
5.2.4 Evaluation . 18
5.3 Key issue #3: Dynamic management according to user requirements . 18
5.3.1 Description . 18
5.3.2 Solution proposal #1: Defining the traffic gateway function of MEP . 19
5.3.3 Solution proposal #2: Add a time dimension to business attributes. 19
5.3.4 Solution proposal #3: Add UE Identity tags list to MEC platform . 20
5.3.5 Evaluation . 20
5.4 Key issue #4: Remote access of enterprise MEC applications . 20
5.4.1 Description . 20
5.4.2 Solution proposal #1: Remote access through Internet . 20
5.4.3 Solution proposal #2: Remote access through mobile backbone network . 21
5.4.4 Evaluation . 21
5.5 Key issue #5: MEC application Slicing support . 21
5.5.1 Description . 21
5.5.2 MEC application slice . 22
5.5.3 Solution proposal #1: Introducing MEC Slice Management . 22
5.5.4 Evaluation . 23
5.6 Key issue #6: MEC efficient consumption of 5GC exposure capability . 24
5.6.1 Description . 24
5.6.2 Solution proposal #1: Local NEF Deployment for (local) network information exposure to MEC
with Low Latency . 24
5.6.3 Solution proposal #2: Usage of Nupf_EventExposure to Report QoS Monitoring . 25
5.6.4 Evaluation . 26
6 Gap analysis and recommendations . 27
ETSI
4 ETSI GR MEC 038 V3.1.1 (2022-11)
Annex A: Change History . 28
History . 29

ETSI
5 ETSI GR MEC 038 V3.1.1 (2022-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 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.
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
6 ETSI GR MEC 038 V3.1.1 (2022-11)
1 Scope
The present document describes the key issues, solution proposals and recommendations needed to support MEC
deployment in Park Enterprise scenario.
The following aspects are addressed: How 3GPP and MEC system cooperate for UEs to access MEC system based on
location (e.g. based on ULCL insertion), including DN-AAA authentication and authorization, MEC application Slicing
support, MEC efficient consumption of 5GC exposure capability and dynamic management according to user
requirements, remote access of enterprise MEC applications.
In addition the present document considers the related work of other standard/industry bodies such as 3GPP and all
related work done in ETSI. The outcome is to generate recommendations for future standard work, e.g. enhancements to
current MEC system, interface enhancements, etc.
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 TS 123 501: "5G; System architecture for the 5G System (5GS) (3GPP TS 23.501
Release 17)".
[i.2] ETSI TS 123 502: "5G; Procedures for the 5G System (5GS) (3GPP TS 23.502 Release 17)".
[i.3] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
[i.4] ETSI GR MEC 031: "Multi-access Edge Computing (MEC); MEC 5G Integration".
[i.5] ETSI GS MEC 011: "Multi-access Edge Computing (MEC); Edge Platform Application
Enablement".
[i.6] ETSI GR MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.7] ETSI GS MEC 014: "Multi-Access Edge Computing (MEC); UE Identity API".
[i.8] ETSI GS MEC 021: "Multi-access Edge Computing (MEC); Application Mobility Service API".
[i.9] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[i.10] ETSI TS 133 501: "5G; Security architecture and procedures for 5G System (3GPP TS 33.501
Release 17)".
[i.11] ETSI GR MEC 024: "Multi-access Edge Computing (MEC); Support for network slicing".
ETSI
7 ETSI GR MEC 038 V3.1.1 (2022-11)
[i.12] ETSI GS MEC 010-2: "Multi-access Edge Computing (MEC); MEC Management; Part 2:
Application lifecycle, rules and requirements management".
[i.13] 3GPP TR 28.801: "Telecommunication management; Study on management and orchestration of
network slicing for next generation network".
[i.14] 3GPP TR 23.748: "Study on enhancement of support for Edge Computing in 5G Core network
(5GC)".
[i.15] ETSI TS 123 548: "5G; 5G System Enhancements for Edge Computing; Stage 2 (3GPP
TS 23.548)".
[i.16] ETSI TS 129 518: "5G; 5G System; Access and Mobility Management Services; Stage 3 (3GPP
TS 29.518)".
[i.17] ETSI GR MEC 044: "Multi-access Edge Computing (MEC); Study on MEC Application Slices".
[i.18] ETSI TS 123 558: "5G; Architecture for enabling Edge Applications (3GPP TS 23.558
Release 17)".
[i.19] ETSI TS 128 530: "5G; Management and orchestration; Concepts, use cases and requirements
(3GPP TS 28.530 Release 17)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR MEC 001 [i.6] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GR MEC 001 [i.6] and the following apply:
5GC 5G Core network
5GS 5G System
AF Application Function
AMF Access and Mobility management Function
CSMF Communication Service Management Function
DN Data Network
DNAI Data Network Access Identifier
DNN Data Network Name
FQDN Fully Qualified Domain Name
GPSI Generic Public Subscription Identifier
LADN Local Area Data Network
LBO Local Break Out
L-NEF Local Network Exposure Function
NEF Network Exposure Function
NF Network Function
NRF Network Repository Function
NSMF Network Slice Management Function
NSSAI Network Slice Selection Assistance Information
PCC Policy and Charging Control
PCF Policy Control Function
PDU Protocol Data Unit
PLMN Public Land Mobile Network
ETSI
8 ETSI GR MEC 038 V3.1.1 (2022-11)
PSA PDU Session Anchor
SMF Session Management Function
TA Tracking Area
UDR Unified Data Repository
UE User Equipment
UL UpLink
UL CL UpLink Classifier
UPF User Plane Function
4 Overview
The present document studies how MEC system can be used to provide MEC services for Park Enterprises' users
based on ULCL insertion from 3GPP 5G network.
Clause 4 provides the description of each identified study area.
Clause 5 proposes all identified key issues and their related solution proposals.
Clause 6 contains evaluation of proposed solutions. Based on identified gaps, recommendations for further work are
provided.
5 Key issues and potential solutions
5.1 Key issue #1: ULCL PSA insertion based on Location
5.1.1 Description
At present, with the development of the Internet and the intensification of innovation, similar enterprises in parks have
appeared all over the world. This type of company is small and relies on the unified communications services provided
by the park. As 5G/MEC is convenient and fast, it becomes the first choice of communication services in the park.
MEC system
Figure 5.1.1-1: MEC in Park Enterprises
It is known that MEC is a nearby service for users who subscribe to MEC services and move to MEC's service area.
3GPP defines three ways to enable MEC services/local access to a DN, such as:
1) Uplink Classifier (UL CL).
ETSI
9 ETSI GR MEC 038 V3.1.1 (2022-11)
2) IPv6 multi-homed PDU session.
3) Local Area Data Network (LADN).
For an industrial park, a location-based ULCL insertion is generally the preferred solution. The MEC service area of the
park is mapped into a new Tracking Area (TA). When the user enters this new TA from other areas, SMF is triggered to
insert ULCL PSA for the user. There are two types of operations:
1) If the user does not carry out the central business related to edge applications, SMF establishes edge UPF
anchor points in advance for users entering the park, so that the anchor points can be directly placed on the
edge DN when launching edge services.
2) If the user is engaged in services related to edge applications, the services will be transferred to the DN
deployed on MEC to improve user experience.
The extended question here is whether the user has subscribed to edge MEC service. If the user subscribing to the MEC
service has the permission to access to the MEC system, SMF will successfully insert ULCL. Therefore, this scenario is
one of the main scenarios in which 5G interacts with MEC, that is, SMF directly enables traffic steering to the MEC
system according to the users' location.
5.1.2 Solution proposal #1: AF detecting UE Location and report to PCF
5.1.2.1 Description
MEC system, as an Application Function (AF), can subscribe the location information of users served by MEC system
through the NEF network element defined by 3GPP as stated in clause 5.6.7 of ETSI TS 123 501 [i.1]. When the user's
location changes, the NEF will inform MEC system of the change.
More specifically, in the MEC system in Park Enterprise scenario, the process can be like the following: the end users
initially register to 5G network and go through the central PSA/UPF by default, and there is a central AF deployed in
the 5G network docking with all MEC systems at the edge to realize information exchange and enable system
configuration and adjustment. When end users enter the park area, the central AF will receive notifications from AMF if
the AF subscribes location event earlier. And then, the AF will enable the traffic guidance mode to instruct 3GPP
network to add new PSA anchor points and transfer the users' business from the centre to the MEC system.
5.1.2.2 Backgrounds
5.1.2.2.1 NEF service operations information flow
The procedure is used by the AF to subscribe to notifications and to explicitly cancel a previous subscription.
Cancelling is done by sending Nnef_EventExposure_Unsubscribe request identifying the subscription to cancel with
Subscription Correlation ID. The notification steps 6 to 8 are not applicable in cancellation case.
ETSI
10 ETSI GR MEC 038 V3.1.1 (2022-11)
AF NEF UDR UDM SMF AMF
1.Nnef_EventExposure_Subscribe/
Unsubscribe Request
2.Nudm_EventExposure_Subscribe/Unsubscribe Request
3a.Namf_EventExposure_Subscribe/
Unsubscribe Request
3b.Namf_EventExposure_Subscribe/
Unsubscribe Response
3c.Nsmf_EventExposure_Subscribe/
Unsubscribe Request
3d.Nsmf_EventExposure_Subscribe/
Unsubscribe Response
4.Nudm_EventExposure_Subscribe/Unsubscribe Request
5.Nnef_EventExposure_Subscribe/
Unsubscribe Response
6a.Nudm_EventExposure_Notify
6b.Nudr_DM_Create/Update
6c.Namf_EventExposure_Notify
6d.Nudr_DM_Create/Update
6e.Nsmf_EventExposure_Notify
6f.Nudr_DM_Create/Update
7.Nnef_EventExposure_Notify
8.Namf_EventExposure_Notify
Figure 5.1.2.2.1-1: Nnef_EventExposure_Subscribe, Unsubscribe and Notify operations
NOTE 1: The procedure is referenced from ETSI TS 123 502 [i.2], with the details described specifically for this
solution.
1. The AF subscribes to Location Reporting (identified by Event ID) and provides the associated notification
endpoint of the AF (IP address) by sending Nnef_EventExposure_Subscribe request.
Event Reporting Information defines the type of reporting requested (e.g. one-time reporting, periodic
reporting or event based reporting, for Monitoring Events). For this solution, Location Reporting is using
event based reporting.
AF is authenticated and authorized by the NEF if requested. The NEF records the association of the event
trigger and the requester identity. The subscription may also include maximum number of reports and/or
maximum duration of reporting IE.
2. [Conditional - depending on authorization in step 1] The NEF subscribes to received Event(s) (identified by
Event ID) and provides the associated notification endpoint of the NEF to UDM by sending
Nudm_EventExposure_Subscribe request. The NEF maps the AF-Identifier into DNN and S-NSSAI
combination based on local configuration, and include DNN, S-NSSAI in the request.
If the reporting event subscription is authorized by the UDM, the UDM records the association of the event
trigger and the requester identity. Otherwise, the UDM continues in step 4 indicating failure.
ETSI
11 ETSI GR MEC 038 V3.1.1 (2022-11)
3a. [Conditional] If the requested event (e.g. Location Reporting, monitoring of Loss of Connectivity) requires
AMF assistance, then the UDM sends the Namf_EventExposure_Subscribe to the AMF serving the
requested user. The UDM sends the Namf_EventExposure_Subscribe request to all serving AMF(s) (if
subscription applies to a UE or a group of UE(s)), or all the AMF(s) in the same PLMN as the UDM (if
subscription applies to any UE).
As the UDM itself is not the Event Receiving NF, the UDM should additionally provide the notification
endpoint of itself besides the notification endpoint of NEF. Each notification endpoint is associated with the
related (set of) Event ID(s). This is to assure the UDM can receive the notification of subscription change
related event.
If the subscription applies to a group of UE(s), the UDM should include the same notification endpoint of
itself, i.e. Notification Target Address (+ Notification Correlation Id), in the subscriptions to all UE's
serving AMF(s).
NOTE 2: Using the same notification endpoint of UDM is to help the AMF identify whether the subscription for
the requested group event is the same or not when a new group member UE is registered.
3b. [Conditional] AMF acknowledges the execution of Namf_EventExposure_Subscribe.
3c. [Conditional] If the requested event (e.g. PDU Session Status) requires SMF assistance, then the UDM
sends the Nsmf_EventExposure_Subscribe request message to each SMF where at least one UE identified
in step 2 has a PDU session established. The NEF notification endpoint received in step 2 is included in the
message.
NOTE 3: In the home routed case, the UDM sends the subscription to the V-SMF via the H-SMF.
3d. [Conditional] The SMF acknowledges the execution of Nsmf_EventExposure_Subscribe.
3c-3d are not needed for this solution.
4. [Conditional] UDM acknowledges the execution of Nudm_EventExposure_Subscribe.
If the subscription is applicable to a group of UE(s) and the maximum number of reports is included in the
Event Report information in step 1, the number of UEs is included in the acknowledgement.
5. NEF acknowledges the execution of Nnef_EventExposure_Subscribe to the requester that initiated the
request.
6a - 6b. [Conditional - depending on the Event] The UDM (depending on the Event) detects the event occurs and
sends the event report, by means of Nudm_EventExposure_Notify message to the associated notification
endpoint of the NEF along with the time stamp. NEF may store the information in the UDR along with the
time stamp using either Nudr_DM_Create or Nudr_DM_Update service operation as appropriate.
6a - 6b are not needed for this solution.
6c - 6d. [Conditional - depending on the Event] The AMF detects that the event occurs and sends the event report,
by means of Namf_EventExposure_Notify message to associated notification endpoint of the NEF along
with the time stamp. NEF may store the information in the UDR along with the time stamp using either
Nudr_DM_Create or Nudr_DM_Update service operation as appropriate.
If the AMF has a maximum number of reports stored for the UE or the individual member UE, the AMF
should decrease its value by one for the reported event.
For both step 6a and step 6b, when the maximum number of reports is reached and if the subscription is
applied to a UE, The NEF unsubscribes the monitoring event(s) to the UDM and the UDM unsubscribes the
monitoring event(s) to AMF serving for that UE.
For both step 6a and step 6b, when the maximum number of reports is reached for an individual group
member UE, the NEF uses the number of UEs received in step 4 to determine if reporting for the group is
complete. If the NEF determines that reporting for the group is complete, the NEF unsubscribes the
monitoring event(s) to the UDM and the UDM unsubscribes the monitoring event(s) to all AMF(s) serving
the UEs belonging to that group.
When the maximum duration of reporting expires in the NEF, the UDM and the AMF, then each of these
nodes should locally unsubscribe the monitoring event.
ETSI
12 ETSI GR MEC 038 V3.1.1 (2022-11)
6e - 6f. [Conditional - depending on the Event] When the SMF detects a subscribed event, the SMF sends the event
report, by means of Nsmf_EventExposure_Notify message, to the associated notification endpoint of the
NEF provided in step 3c. NEF may store the information in the UDR along with the time stamp using either
Nudr_DM_Create or Nudr_DM_Update service operation as appropriate.
6e - 6f. are not needed for this solution.
7. [Conditional - depending on the Event in steps 6a-6f] The NEF forwards to the AF the reporting event
received by either Nudm_EventExposure_Notify and/or Namf_EventExposure_Notify. In the case of the
PDU Session Status event, the NEF maps it to a PDN Connectivity Status notification when reporting to the
AF.
8. [Conditional - depending on the Event] The AMF detects the subscription change related event occurs, e.g.
Subscription Correlation ID change due to AMF reallocation or addition of new Subscription Correlation
ID due to a new group UE registered, it sends the event report, by means of Namf_EventExposure_Notify
message to the associated notification endpoint of the UDM.
5.1.2.2.2 The relationship between AF and MEC system
As described in clause 4.4 of ETSI GR MEC 031 [i.4], the MEC system appears as an Application Function or
Application Functions to a 5G system. Here, the relationship between AF and the MEC system are explained more in
detail.
In this solution, it is actually the control function unit of the MEC system that appears as the AF. It is centrally deployed
and the quantity is small. While other parts of the MEC system are distributed and edge oriented deployed, and the
quantity is very large.
The function of the AF is to serve the MEC system and 3GPP interaction, which includes subscribe information from
3GPP, realize traffic guidance, allocate optimal edge nodes for users according to user location, and load balancing, etc.
For this solution, AF and the MEC system can be considered as one entity, though they are responsible for different
functionalities, and deployed in different locations.
Therefore, in the following procedure AF and the MEC system will appear together as one entity (AF/MEC system).
5.1.2.3 AF requests to influence traffic routing for Sessions based on location
detection
Below is the solution procedure.
ETSI
13 ETSI GR MEC 038 V3.1.1 (2022-11)
PSA1+ULCL
UE AF/MEC
AMF PSA0 NEF
SMF
UDR
PCF(s)
0a、UE has established a PDU session with PSA0
0b、Location Reporting notification（UE is moving into MEC area，AF has subscribed location event）
1. Creation of the
AF request
2 Nnef_TrafficInfluence_
Create / Update /Delete
3a. Storing/Updating/
Removing the information
3b. Nnef_TrafficInfluence_
Create / Update / Delete Response
4. Nudr_DM_Notify
5. Npcf_SMPolicyControl_UpdateNotify
6. User Plane Reconfiguration，SMF
establishes ULCL+PSA1，removing PSA0
7. UE uses PSA1 to access the MEC system

Figure 5.1.2-3-1: AF requests to influence traffic routing for Sessions based on location detection
UE has established a PDU session with PSA0, when UE moves to MEC area (PSA1 serves this area as an Edge PSA),
AF/MEC system detects it and report to NEF, as described in clause 4.3.6.2 "Processing AF requests to influence traffic
routing for Sessions not identified by an UE address" and clause 4.3.5.7 "Simultaneous change of Branching Point or
ULCL and additional PSA for a PDU Session" of ETSI TS 123 502 [i.2].
The detailed description of the procedure is as follow:
0a. UE has established a PDU session with PSA0 (it is a central default UPF).
0b. AMF reports the UE location change to AF. UE is moving into MEC area (a new area), and AF/MEC system
has subscribed the location event before.
1. AF/MEC system receives UE location change notification and decides to apply traffic routing and create a new
request. The AF invokes a Nnef_TrafficInfluence_Create service operation. The content of this service
operation (AF request) is defined in clause 5.2.6.7 of ETSI TS 123 501 [i.1]. The request also contains an AF
Transaction Id.
2. The AF sends its request to the NEF. If the request is sent directly from the AF to the PCF, the AF reaches the
PCF selected for the existing PDU Session by configuration or by invoking Nbsf_management_Discovery
service.
The NEF ensures the necessary authorization control, including throttling of AF requests and mapping from
the information provided by the AF into information needed by the 5GC.
3. (in the case of Nnef_TrafficInfluence_Create or Update): The NEF stores the AF request information in the
UDR (Data Set = Application Data; Data Subset = AF traffic influence request information, Data Key = AF
Transaction Internal ID, S-NSSAI and DNN and/or Internal Group Identifier or SUPI.)
(in the case of Nnef_TrafficInfluence_Delete): The NEF deletes the AF requirements in the UDR (Data Set =
Application Data; Data Subset = AF traffic influence request information, Data Key = AF Transaction Internal
ID.)
The NEF responds to the AF.
ETSI
14 ETSI GR MEC 038 V3.1.1 (2022-11)
4. The PCF(s) that have subscribed to modifications of AF requests (Data Set = Application Data; Data Subset =
AF traffic influence request information, Data Key = S-NSSAI and DNN and/or Internal Group Identifier or
SUPI) receive(s) a Nudr_DM_Notify notification of data change from the UDR.
5. The PCF determines if existing PDU Sessions are potentially impacted by the AF request. For each of these
PDU Sessions, the PCF updates the SMF with corresponding new PCC rule(s) by invoking
Npcf_SMPolicyControl_UpdateNotify service operation.
The AF request includes a notification reporting request for UP path change, the PCF includes in the PCC
rule(s) the information required for reporting the event, including the Notification Target Address pointing to
the NEF or AF and the Notification Correlation ID containing the AF Transaction Internal ID.
6. When the PCC rule is received from the PCF to request for UP path change, the SMF takes appropriate actions
to reconfigure the User plane of the PDU Session as follows:
- Adding PSA1 as ULCL point as serving UPF.
- Removing PSA0 in the data path.
- Allocating a new Prefix to the UE (when IPv6 multi-Homing applies).
- Updating the UPF in the target DNAI with new traffic steering rules.
7. UE uses the PSA1 as the serving UPF to access to MEC system.
5.1.3 Solution proposal #2: SMF detecting UE Location changing
The SMF is the execution NF of ULCL insertion, based on instruction from PCF, but also based on information it
obtains from AMF directly. 5G is a service-based architecture, and SMF can subscribe location-Report event of UEs
from AMF. As stated in ETSI TS 129 518 [i.16], clause 6.1.3 "A NF subscribes to this event to receive the Last Known
Location or the Current Location of a UE or a group of UEs or any UE, and Updated Location of any of these UEs
when AMF becomes aware of a location change of any of these UEs with the granularity as requested."
SMF AMF
1. POST ./subscriptions (AmfCreateEventSubscription)
2a. 201 Created (AmfCreatedEventSubscription (with Location report))
2b. 4xx/5xx (Loation changing infos) or 3xx

NOTE: In this solution there is no impact expected in MEC system.

Figure 5.1.3-1: SMF Subscribe for Location Report from AMF
5.1.4 Evaluation
The proposed solution is technically feasible. The end user has subscribed to multiple services and the terminal will be
connected to the network via default UPF at the beginning. In this way, the MEC platform needs to subscribe to the UE
location notification through NEF. When UE moves to MEC's service area, additional UPF anchor points would be
added in time according to the user profile / subscription information to provide MEC services for UE.
5.2 Key issue #2: Unified AAA management of MEC system
5.2.1 Description
The unified AAA management of the park MEC system means that the MEC system serves as the entrance of
enterprises in the park, and all accesses need to be authenticated.
ETSI
15 ETSI GR MEC 038 V3.1.1 (2022-11)
When a user wants to access the MEC system to use its services, the MEC system will authenticate the user and confirm
the user's access permissions according to the application information deployed on the MEC platform, so as to ensure
that the user has subscribed the corresponding MEC service. After the authentication is completed, the user's service
request will be transferred to the corresponding MEC application.
MEC system
APP1
APP2
APP3
ęę
APPN
MEC entrance
entity
Infrastrusture
Authentication
and
5G/MEC users
Authorization
Figure 5.2.1-1: Unified AAA management of MEC system
5.2.2 Solution proposal #1: Using UE Identity API
As stated in ETSI GS MEC 014 [i.7], clause 5.1, when the MEC system supports the UE Identity feature, the MEC
platform provides the functionality for a MEC application to register a tag (representing a UE) or a list of tags. Each tag
has been mapped into a specific UE in the mobile network operator's system. And the purpose of the UE Identity feature
is to allow UE specific traffic rules in the MEC system.
However, a MEC application does not always have this UE ID. For example, in the location-based ULCL insertion
scenario, the access information at this time does not take GPSI, but other relevant information, such as IP address. For
security, the MEC system may need to authenticate the new access, but only in the case of IP address, a MEC
application cannot initiate secondary Re-authentication to SMF. Therefore, it may be necessary to obtain UE ID, such
as a UE's GPSI.
In ETSI TS 123 558 [i.18], clause 8.6.5, there is a procedure whereby an Edge Enabler Server (EES) is able to expose a
UE Identifier API to an Edge Application Server (EAS) to provide it with an identifier uniquely identifying a UE if the
EAS does not have it. Therefore, it is proposed to re-use this procedure within MEC, thereby enabling the MEC
platform to expose an UE Identity API to MEC APP instances in order to provide them with an identity uniquely
identifying a UE for subsequent procedures over Mp1.
Figure 5.2.2-1 describes the UE Identity API Request/Response interactions between the MEC application and MEC
platform to enable it to obtain a UE Identity.
ETSI
16 ETSI GR MEC 038 V3.1.1 (2022-11)
MEC APP Instance MEC Platform
1. UE Identity API request
2. Obtain UE
Identity
3. UE Identity API response
4. MEC APP Instance uses UE ID for subsequent steps.

Figure 5.2.2-1: UE Identity API Request/Response
1. The MEC APP Instance invokes the UE Identity API exposed by the MEP.
2. The MEP uses the received user information in the step 1 (e.g. IP address) and obtains the UE identity.
NOTE: It is outside of this study how the MEP determines the UE ID.
3. The MEP provides the obtained UE identity as UE ID to the MEC APP Instance. The UE ID is specific to the
given MEC APP Instance and may be assigned by the 3GPP Network.
4. The MEC APP Instance uses the UE ID received in step 3 to perform the subsequent next steps.
5.2.3 Solution proposal #2: DN-AAA triggers Secondary
authentication/authorization when ULCL inserting
The present document is aimed at the ULCL insertion scenario, that is, UE has completed the authentication with the
centre AAA, when UE wants to access the MEC system, according to the local policy (based on security considerations,
etc.), it still needs to carry out secondary re-authentication and authorization.
In other words, any new access to a MEC system needs to be authenticated by DN-AAA which resides in the MEC
system.
As the description from clause 5.6.6 of ETSI TS 123 501 [i.1]: at any time, a DN-AAA server or SMF may trigger
Secondary authentication procedure for a PDU Session established with Secondary Authentication as specified in
clause 11.1.3 of ETSI TS 133 501 [i.10].
Combined with this scenario, the related procedure of this solution is given in figure 5.2.3-1.
ETSI
17 ETSI GR MEC 038 V3.1.1 (2022-11)
MEC system
DN-AAA .
UE AMF C-UPF SMF E-UPF
0a.UE has registered in 5G network and Central DN-AAA
0b、UE moves into MEC area and access to MEC system via E-UPF
1、For it’s a new access,based on local policy,
DN-AAA Decision to Secondary authentication and
initiate EAP Authentication
2. Authentication Request
3. EAP-Request/Identity
4. EAP-Response/Fast Auth Identity
5.EAP-Response /Fast Re-Auth Identity
6、DN-AAA confirms if the authentication is
success or not by exchange EAP infos.
7、.EAP-Success
OR
7、.EAP-Failure
EAP-Success
8. SM Request Ack w/ Re-Auth Accept
EAP-Success
9. Re-Auth Accept, EAP-Success
UE enjoys the high speed and low delay service of MEC system
EAP-Failure
8a N4 Transport
Modification Request
8b N4 Transport
Modification Response
9.SM Request Ack w/ Re-Auth Failure
EAP-Failure
10. Re-Auth Failure, EAP-
Failure
UE Can’t uses the high speed and low delay service of MEC system

Figure 5.2.3-1: EAPAuthentication with 3GPP and MEC system
This procedure concerns only non-roaming scenario for MEC in Park. In the non-roaming and LBO roaming cases, only
one SMF is involved.
Preconditions:
0a. UE has registered in 5G network and Central DN-AAA.
0b. UE moves into MEC area and access to MEC system via E-UPF.
ETSI
18 ETSI GR MEC 038 V3.1.1 (2022-11)
1. Because it is a new access, based on local policy (any new access to the MEC system needs to be authenticated
by DN-AAA), DN-AAA decides to Secondary Re-authenticate and initiate EAP Re-Authentication.
2. The DN-AAA should send a Secondary Authentication request to UPF and the UPF forwards to SMF. The
Secondary authentication request contains the GPSI, if available, and the IP/MAC address of the UE allocated
to the PDU Session and the MAC address if the PDU session is of Ethernet PDU type.
3. The SMF should send an EAP Request/Identity message to the UE.
4. The UE should respond with an EAP Response/Identity message (with Fast-Auth Identity).
5. The SMF forwards the EAP Response/Identity to UPF, selected during initial authentication, over N4
interface. This establishes an end-to-end connection between the SMF and the external DN-AAA server for
EAP exchange.
The UPF should forward the EAP Response/Identity message to the DN-AAA Server.
The DN-AAA server and the UE should exchange EAP messages as required by the EAP m
...