In order to avail edge computing services deployed in the Edge Data Network, a UE should be able to connect with the Edge Data Network. What is critical is whether the Application Client is able to find an Edge Application Server. Open issues:

• Whether some configuration information is needed by the UE in order to connect with the Edge Data Network or not? If yes, what are the configuration parameters?
• How the configuration information, if required, is provided to the UE in a secure manner?
• In the case that multiple Edge Application Servers are available in multiple Edge Data Networks, what application information is needed to determine the best suitable Edge Data Network?

The deployment of Edge Data Network may not be available at all the locations due to operational constraints. For certain applications, before attempting to avail edge computing services the UE needs to determine the availability of an Edge Data Network at the UE's location. Open issues:

• Whether and how a UE determines the availability of an Edge Data Network at the UE's location?
• Whether and how a UE determines the availability of an Edge Enabler Server at the UE's location?
• Whether and how the UE registers to the Edge Enabler Server before availing Edge Computing services?
• Whether and how the UE de-registers from the Edge Enabler Server?
• Whether and how the Edge Enabler Server detects an abnormal termination of the UE registration?
• If there are changes in the availability of the Edge Data Network, whether and how the UE is notified?
• If there are any changes in the availability of the Edge Enabler Server, whether and how the UE is notified?

Several application providers can use the Edge Data Network to provide their applications as Edge Application Servers. To enable such Edge Application Servers on the Edge Hosting Environment, the application providers may need to supply Edge Application Servers related information to the Edge Enabler Server. This information can include constraints on the availability of the Edge Application Server to certain geographical area or time of operation etc. Open Issues:

• How the Edge Application Servers are registered on the Edge Enabler Server? How the Edge Enabler Server identifies the registered Edge Application Servers?
• Whether and how the Edge Application Servers provide availability information such as, certain geographical area, time of operation etc. to the Edge Enabler Server?
• What are the parameters required for Edge Application Server's enablement on the Edge Enabler Server?
• How the Edge Application Servers de-register from the Edge Enabler Server?
• How the Edge Enabler Server can distribute EDN messages efficiently to a set of subscribed Edge Application Servers?
• Whether and how the Edge Enabler Server detects an abnormal termination of the Edge Application Server registration?

The deployment of Edge Application Servers may not be uniform across the Edge Data Networks due to operational constraints. For certain applications, before attempting to avail services from an Edge Application Servers, the UE needs to determine the availability of the Edge Application Server from the Edge Enabler Server. The meaning of availability of the Edge Application Server includes both the Edge Application Server running on the Edge Hosting Environment, and the Edge Application Server, which can be instantiated on the Edge Hosting Environment. Open Issues:

• Whether and how to discover the Edge Application Servers available on the Edge Hosting Environment within the Edge Data Network?
• How to check authorization to discover the Edge Application Servers?

3GPP Network capability exposure function (i.e. SCEF, NEF) provides northbound RESTful APIs which can be utilised by 3rd party applications (see TS 29.122 and TS 29.522 for information regarding available northbound APIs). In order for a 3rd party Edge Application Server to access such northbound APIs exposed by SCEF/NEF, the 3rd party application developer would need to onboard onto the MNO's platform (e.g., CAPIF) and accept MNO's SLA terms and conditions. On the other hand, it would be beneficial if the 3rd party Edge Application Servers in the Edge Data Network can utilize service API(s) exposed by the Edge Enabler Server, which may rely on the SCEF/NEF northbound APIs. Some of the service API(s) that are exposed by the Edge Enabler Server may facilitate communication between Application Client(s) and Edge Application Server(s). For example, in smart factory, Edge Application Server may have the demand to obtain location information of industrial robotics in order to activate corresponding actions or operations based on location. This kind of location-based service requires the Edge Application Server to be authorized to obtain the location information of the UE through the Edge Enabler Server. Open issues:

• Whether there is a need for new service API(s) provided by the Edge Enabler Server to the Edge Application Server, and how to support?
• How Edge Application Servers discover available service API(s) within the Edge Data Network?
• Whether and how to support the Edge Application Server to access the network capability exposure function directly, e.g., how CAPIF as specified in TS 23.222 can be utilized, and whether there is a need to enhance functionalities of CAPIF?
• Whether there is a need to support exposure of service API provided by the Edge Application Server to the other Edge Application Server within the Edge Data Network, and how to support?
• Whether there is a need to support exposure of service API provided by the Edge Application Server to the other Edge Application Server of the different Data Network, and how to support?
• How the Edge Enabling Server re-exposes service API(s) to the Edge Application Server, where the service API(s) are relying on the SCEF/NEF northbound API(s)?
• How to uniquely identify the UE between the Edge Application Server and the Edge Enabler Server for utilizing capability exposure API(s) which may rely on the SCEF/NEF northbound API(s)?
• Whether and how the location information of the UE can be exposed to the Edge Application Server from the Edge Enabler Server.
• How the Edge Enabler Server service API(s) are used to provide Edge Application Servers with information about the capabilities of Edge Enabler Clients that host the Edge Application Server's Application Client(s).
• How Edge Enabler Server service API(s) facilitate communication between Application Client(s) and Edge Application Server(s).

To support Edge Computing Service authorization, the following open issues need to be studied.

• How to enable the mobile network operator to authorize the usage of Edge Computing Service by UE?
• How to authorize the UE to use Edge Computing Service by non-MNOs, if required in specific deployments?
• How to enable the Edge Enabler Client to authenticate with the Edge Data Network Configuration Server?

To support flexible deployment for Edge Computing, the following open issues need to be studied.

• How to support the multiple Edge Computing Service Providers per PLMN operator network?
• How to identify Edge Data Network, in case of multiple Edge Data Networks within a single PLMN where one Edge Data Network is defined as a subarea (e.g. list of TAs or cells) in the PLMN coverage?

A UE may have access to more than one Edge Data Network including Edge Application Servers due to e.g. dual registration with 3GPP access and non-3GPP access. An Edge Enabler Client in the UE needs to discover not only available Edge Application Server(s) but first select the optimal Edge Data Network if more than one is available. Open issues:

• How to assist the UE to select the optimal Edge Data Network?

When a UE handoffs to a new location, different Edge Application Servers may be more suitable for serving the Application Clients in the UE. There needs to be a way for Application Clients in the UE to continue their service while replacing the serving Edge Application Server, with target Edge Application Server. Furthermore, similar service continuity requirements exist for the cases in which the Edge Application Servers are transferred from the Edge Data Network to Servers in the cloud and vice versa. Such transitions may occur as a result of a mobility event, or even as a result of other non-mobility events such as load balancing. This key issues proposes to study "upper layer enablers" for service continuity that are within the scope of the application architecture for Edge Application Servers (e.g. mechanisms for traffic redirection). Open Issues:

• How to detect the need to reroute traffic from the serving Edge Application Server instance to the target Edge Application Server?
• How to enable the required switch in the connection between the Application Client and the Edge Application Server while preserving service continuity?
• How to transfer any required context between Edge Application Servers within the Edge Data Network?
• How to transfer any required context from the serving Edge Application Server to the target Edge Application Server (or Server) regardless of their location: In the same Edge Data Network, in a different Edge Data Network or in the Cloud?

Availability of Edge Data Network and the Edge Application Servers can change dynamically due to multiple reasons, such as change in deployments, mobility of the UE etc. Such changes should be provided to the UE to fine tune the services provided accordingly. Open issues:

• How to keep the UE updated with information about Edge Data Network?
• How to keep the UE updated with information about Edge Application Servers?

User's consent is an important aspect while dealing with sensitive information about the user or the devices of the user. With the capabilities of the Edge Application Servers to request invocation of 3GPP network capability exposure APIs, such as location APIs, to obtain information about the user and the devices of the user, it is of utmost importance to capture the consent of the user. The user needs to be in full control of which applications are allowed to request and obtain what information pertaining to the user and the devices belonging to the user and how frequently. Such approvals by the end users ensure that only the legitimate applications, trusted by the user, are able to obtain and make use of the information and services involving the user or user's sensitive information. While capturing and using user consent is important, it is also important to ensure only authorized users are allowed to grant or modify consent. Open issues:

• How to obtain the user's consent to allow an Edge Application Server's service or information request?
• How to ensure that only an authorized user is able to grant or modify the consent?

In order to ensure efficient deployment of third-party applications in the Edge Data Network, the application provider should be able to invoke requests pertaining to the lifecycle of applications. These include on-boarding, instantiation, upgrade, scaling and termination of user applications deployed as Edge Application Servers in the Edge Data Network. The Edge Computing Service Provider should process the requests and authorise them when appropriate based on e.g. its own policies, resource availability, etc. Further, it should be possible for an Edge Computing Service Provider to manage the lifecycle of the Edge Enabler Server and Edge Data Network Configuration Server in order to deploy edge ecosystems dynamically. This should include the capability to manage the performance and fault of both entities. These actions may be the result of requests from the application provider. Open issues:

• A mechanism for the application providers to request lifecycle operations (e.g. instantiation, termination, scaling) for their Edge Application Servers.
• A mechanism for edge computing service providers to manage the lifecycle (e.g. instantiation, termination, scaling), performance assurance and fault supervision of Edge Enabler Servers.
• A mechanism for edge computing service providers to manage the lifecycle (e.g. instantiation, termination, scaling), performance assurance and fault supervision of Edge Data Network Configuration Servers.

Edge Application Servers of the same type may have different requirements in terms of QoS (e.g., guaranteed bitrate, maximum bitrate, priority). For instance, certain video streaming applications may be expected to provide higher QoS than other video streaming applications. Open Issues:

• Whether the information related with QoS (e.g., QoS parameters) can be exposed to the Edge Application Server? If yes, how to do it?
• Whether to differentiate the QoS requirements for the same type of Edge Application Servers? If yes, how to do it?
• Whether to define certain policy rules (e.g. QoS modification is forbidden) for certain Edge Application Servers? If yes, how to do it?

During service provisioning and Edge Data Network discovery it is critical that the Application Client is able to find an Edge Application Server in such a manner that the range of required Application Client KPIs (e.g. latency, compute resources) are satisfied. Application Client KPIs may be included in the application package that is initially onboarded and subsequently instantiated in the Edge Data Network, if they are present. When the Application Client is installed in the UE those KPIs, or a subset of them, can become resident in the UE. Open Issues:

• What are the specific application KPIs?
• Whether and how determination of the availability of a suitable Edge Data Network is based on a range of Application Client KPIs?
• Whether and how determination of the availability of a suitable Edge Enabler Server is based on a range of Application Client KPIs?
• What is the range of Application Client KPIs (e.g. latency, compute resources) needed in order for a UE to connect with the best suitable Edge Data Network (e.g., with Edge Application Server available that satisfies the KPIs)?
• How to assist the UE to select the optimal Edge Data Network when the serving EDN can no longer meet the performance required by one or more of the Application Client KPIs?