This clause describes examples of deployment models with respect to different DN implementations as follows:

• option 1. use of non-dedicated DN;
• option 2. use of Edge-dedicated DN; and
• option 3. use of LADN.

The PLMN supporting edge computing services provides connection to one or multiple DNs. The following clauses describes the detailed deployment models including relationships between EAS service areas, EES service areas, LADN service areas, and PLMN area.

There is no Edge-dedicated DN for support of edge computing service. A DN common to other services (e.g. internet access) is used to connect to the EASs. The PLMN supporting edge computing services provides connection to EASs located in EDNs that respectively corresponds to one or more DNAI(s), and each EDN is identified by DNN and one or more DNAI. UEs establishing PDU sessions for the EASs identify the DN using the same DNN and slice information as for PDU sessions for non-Edge services. Each EAS and EES can have a topological service area or a geographical service area that the EAS and EES serves, respectively. Within this service area, UEs can access an EAS or an EES regardless of their location within the PLMN area via local breakout.

The deployment uses Edge-dedicated DNs for support of edge computing service. Each Edge-dedicated DN is configured with unique DNNs. The PLMN supporting edge computing services provides connection to several EDNs that correspond to one or more DNAI(s), and each EDN is identified by DNN of the Edge-dedicated DN and one or more DNAI.

Edge computing services can be provided via Edge-dedicated Data Networks deployed as LADNs. With this option, the PLMN supports edge computing services in the EDN service areas which is equal to the LADN service area. The LADN service area is the service area that the Edge Computing is supported. Each individual EAS in the LADN can support the same or smaller service area than the LADN.

This clause shows some examples for how the ECS can be deployed in relation to the UE

In this scenario the UE can contain a single AC or multiple ACs, however the UE contains a single EEC which is configured with the address of a single ECS. This could for example be an IoT device that only supports a single AC or a smartphone device which contains many ACs which are served by a single ECS.

In this scenario the user is allowed to install multiple ACs in the UE where each AC can be served by an EAS which in turn served by a different ECSP's EES/ECS. One example is that multiple ACs are installed on a smartphone and the associated EASs are on-boarded onto different ECSP's EESs which are registered with different ECSs. Another example is a UE that supports Dual SIM. In this scenario the UE can support concurrent connection to two PLMNs.

The illustration of layered application architecture with the generic SEAL and Application Enabler server functions available in the cloud is shown in Figure A.4.1-1.

The examples of application specific client are V2X application specific client, FF application specific client, UAS application specific client or other vertical application specific client residing on the UE. Similarly, the application specific server could be e.g. V2X application specific server, FF application specific server, UAS application specific server or other vertical application specific server. The UE may consist of an application enabler client. The examples of application enabler client include V2X application enabler client, FF application enabler client, UAS application enabler client or other vertical application enabler client residing on the UE. Similarly, the application enabler server could be V2X application enabler server, FF application enabler Server, UAS application enabler server or other vertical application enabler server. The illustration of layered application architecture with generic SEAL and Application Enabler server functions available in the edge is shown in Figure A.4.1-2.

While the server functions of an application specific server can be made available only as an EAS, it is also possible that certain application specific server functions are available both at the edge and in the cloud. Similarly, the server functions of an application enabler server can be made available only as an EAS, it is also possible that certain application enabler server functions are available both at the edge and in the cloud. When the server functions of an application are both available at the edge and the cloud, there may be a need for interaction between the two corresponding application servers, which is out of scope of this specification.

There are several options to support SEAL service APIs to be exposed to the EAS. The EES can act as the CAPIF core function, and the SEAL servers acting the AEF and publish the SEAL service API to the EES. Further, the SEAL service APIs is discovered by the EASs acting as the API invoker during the service API discover procedure as specified in TS 23.222. The EES can act as the API topology hiding entry and re-expose SEAL service APIs as specified in TS 23.434 to EAS via EDGE-3 which utilizes the CAPIF-2/2e reference point as specified in TS 23.222.

There are several options to support vertical application enabler server (e.g., V2X application enabler server) APIs to be exposed to the EAS. The EES can act as the CAPIF core function, and the vertical application enabler server acting the AEF and publish the vertical application enabler server APIs to the EES. Further, the vertical application enabler server APIs is discovered by the EASs acting as the API invoker during the service API discover procedure as specified in TS 23.222. The EES can act as the API topology hiding entry and re-exposes vertical application enabler server APIs, e.g., VAE server APIs as specified in TS 23.286 to EAS via EDGE-3 which utilizes the CAPIF-2/2e reference point as specified in TS 23.222.

Void

The EES can support EAS's access to northbound APIs exposed by SCEF/NEF by providing distributed CAPIF functions as shown in Figure A.5.2-1.

The EDNs reside outside the PLMN trust domain as shown in Figure A.5.2-1. In EDN 2, the EAS and EES are within the same ECSP trust domain. While in EDN 1, the EES and the EAS are in the different ECSP trust domain. The EES of an EDN provides the following functions for network capability exposure:

• the CAPIF core function as specified in TS 23.222 to support onboarding of EASs (API invokers), publish of service APIs, discovery of service APIs and charging of service APIs invocations; and
• the API exposing function as specified in TS 23.222 to expose the service APIs from SCEF/NEF to the EASs via proxy or gateway function.

The following procedures are performed as specified in TS 23.222:

• The SCEF and NEF act as API exposing function and the service APIs from SCEF (T8) and NEF (Nnef) are published to the CAPIF core function 1. The service APIs are published to the EESs (CAPIF core function 2 and CAPIF core function 3) from the CAPIF core function 1.
• The EAS acts as an API invoker and is onboarded to the EES (CAPIF core function 2 or CAPIF core function 3) within the EDN.
• The EASs (API invokers) are authenticated with EES (CAPIF core function 2 or CAPIF core function 3).
• The EAS discovers the service APIs published by the SCEF and NEF via the EES (CAPIF core function 2 or CAPIF core function 3) within the EDN including the end point address of the API exposing function where the service API invocation is to be performed.
• The EAS obtains authorization to invoke the service APIs of the SCEF and NEF from the EES (CAPIF core function 2 or CAPIF core function 3).
• The EAS invokes the service APIs of the SCEF and NEF after authorization by the EES (API exposing function) and obtaining the UE identifier as specified in clause 8.6.5. The EES (API exposing function) further invokes the service APIs of the SCEF or NEF in the 3GPP core network. EDGE-2 supports CAPIF-7e interactions corresponding to T8 (for SCEF) and N33 (for NEF).

The EES can support EAS (owned by 3rd party or by PLMN operator) access to northbound APIs exposed by SCEF/NEF by providing centralized CAPIF functions as shown in Figure A.5.3-1.

The EDNs reside outside the PLMN trust domain as shown in Figure A.5.3-1. In EDN 2, the EAS and EES are within the same ECSP trust domain. While in EDN 1, the EES and the EAS are in the different ECSP trust domain. The EES of an EDN provides the following functions for network capability exposure:

• the centralized CAPIF core function as specified in TS 23.222 to support onboarding of EASs (API invokers), publish of service APIs, discovery of service APIs and charging of service APIs invocations; and
• the API exposing function as specified in TS 23.222 to expose the service APIs from SCEF/NEF to the EASs via proxy or gateway function.

The following procedures are performed as specified in TS 23.222:

• The SCEF and NEF act as API exposing function and the service APIs from SCEF (T8) and NEF (Nnef) are published to the centralized CAPIF core function. The service APIs exposed by the EESs are published to the centralized CAPIF core function.
• The EAS acts as an API invoker and is onboarded to the centralized CAPIF core function residing outside of the EDN.
• The EASs (API invokers) are authenticated with the centralized CAPIF core function.
• The EAS discovers the service APIs published by the SCEF and NEF via the centralized CAPIF core function including the end point address of the API exposing function where the service API invocation is to be performed.
• The EAS obtains authorization to invoke the service APIs of the SCEF and NEF from the centralized CAPIF core function.
• The EAS invokes the service APIs of the SCEF and NEF after authorization by the EES (API exposing function) and obtaining the UE identifier as specified in clause 8.6.5. The EES (API exposing function) further invokes the service APIs of the SCEF or NEF in the 3GPP core network. EDGE-2 supports CAPIF-7e interactions corresponding to T8 (for SCEF) and N33 (for NEF).