Content for  TS 23.558  Word version:  19.3.0

The EEC sends an EAS discovery request to the EES. The EAS discovery request includes the requestor identifier [EECID] along with the security credentials and may include EAS discovery filters, EEC service continuity support, and may also include UE location to retrieve information about particular EAS(s) or a category of EASs, e.g. gaming applications, or Edge Applications Server(s) available in certain service areas, e.g. available on a UE's predicted or expected route. The request may include an EAS selection request indicator. If an e2e tunnel is used in the UE for applications (e.g. user configured tunnel service), and if the tunnel service provider and the ECSP are from the same organization and only if user grants the permission, then the EEC provides the tunnel information for the associated applications in the request to the EES considering user consent.

Upon receiving the request from the EEC, the EES checks if the EEC is authorized to discover the requested EAS(s). The authorization check may apply to an individual EAS, a category of EASs or to the EDN, i.e. to all the EASs. If UE's location information is not already available, the EES obtains the UE location by utilizing the capabilities of the 3GPP core network as specified in clause 8.10.3. If EAS discovery filters are provided by the EEC, but it does not contain Application group profile, the EES identifies the EAS(s) based on the provided EAS discovery filters and the UE location. When the bundle EAS information is provided, then;

• If bundle EAS information includes EAS bundle identifier, the EES identifies all or part of the EAS(s) associated with the same EAS bundle identifier.
• If bundle EAS information includes a list of EASIDs, the EES identifies the EASs which are all or part of the EAS bundle.

If the EEC indicates that service continuity support is required, when identifying the EAS, the EES shall take the indication which ACR scenarios are supported by the AC, the EEC, the EES and the EAS and which of these are preferred by the AC into consideration. The EES may select one EAS and determine whether to perform application traffic influence for this EAS in advance based on AC's service KPI or EAS's service KPI in desired response time, when the EAS does not perform traffic influence in advance. If the EES determines to perform application traffic influence for this EAS in advance, then the EES will applies the AF traffic influence of the EAS in the 3GPP Core Network before sending EAS discovery response. If the Prediction expiration time is provided then the EES may determine whether to identify the instantiable but not instantiated EAS as T-EAS based on Prediction expiration time and the predicted EAS deployment time information obtained from ADAES as specified in clause 8.11 of TS 23.436 or from local configured maximum EAS deployment time. The EES determines remaning EAS instantiation time or EAS instantiation completion time based on the timing receiving EAS instantiation is in progress from ECSP management system and the predicted EAS deployment time. Furthermore, if EES received the indication which the EAS instanitation is in progress, then the EES determines whether to identify the EAS which instantiation in progress as T-EAS based on Prediction expiration time and remaining EAS instantiation time information. When EAS discovery filters are not provided, then:

• if available, the EES identifies the EAS(s) based on the UE-specific service information at the EES and the UE location;
• EES identifies the EAS(s) by applying the ECSP policy (e.g. based only on the UE location);

When EAS discovery filters contain Application group profile, the EES checks whether information about common EAS and related Application Group ID is available or not. If the common EAS information related to the Application Group ID is:

• not available at the EES, then based on the policy if EES needs to select the common EAS, the EES identifies an EAS for the Application Group ID based on the provided EAS discovery filters such as KPIs, UE-specific service information or the ECSP policy. Furthermore, the EES stores the common EAS information and related Application Group ID.
• available at the EES, then the EES provides information of that EAS as result for EAS discovery, or the EES identifies the EAS based on the provided EAS discovery filters and the UE location when E2E response time is received, furthermore:
  • when the UE in the overlapping area between the EDNs of common EAS and EAS registered to this EES (e.g. UE can connect either common EAS or EAS registered to this EES which is UE is in the common EAS service area), the EES identifies either common EAS or EAS registered to this EES for the UE based on the UE location, EAS discovery filters, application group profile, common EAS KPI as specified in Table 8.2.5-1 and EDN information, registered EAS KPI as specified in Table 8.2.5-1 and EDN information, and inter-EAS communication performance of these EASs and checks whether the common EAS or EAS registered to this EES can provide better E2E response time.
  • When the UE is not in the overlapping area between the EDNs of common EAS and EAS registered to this EES (e.g. UE is not in the common EAS service area), then the EES identifies candidate EAS(s) for the group from its registered EASs based on UE location, EAS discovery filters and application group profile and checks if the candidate EAS(s) can satisfy the E2E response time considering the response time of the candidate EAS(s), the response time of available common EASs in other EDNs and the inter-EAS communication latency. If the E2E response time cannot be satisfied, the EES will respond the EEC in step 3 indicating such a rejection reason; otherwise, the EES selects a candidate EAS and interacts with the ECS-ER to store it as common EAS as described in clause 8.20.2.3.

When the ECS-ER is not available and the EES selects the common EAS, the selected common EAS shall be announced to other EES(s) as per procedure specified in clause 8.19. When the ECS-ER is available, if the common EAS information related to the Application Group ID is:

• not available at the ECS-ER, the EES identifies one EAS for the group and interacts with the ECS-ER to store the common EAS information as described in clause 8.20.2.3.
• available at the ECS-ER, then the ECS-ER returns the common EAS information to the EES as described in clause 8.20.2.3 , or the EES identifies the EAS based on the provided EAS discovery filters and the UE location when E2E response time is received, furthermore:
  • When the UE is in the overlapping area between the EDNs of common EAS and EAS registered to this EES (e.g. UE can connect either common EAS or EAS registered to this EES, which is UE is in the common EAS service area), the EES identifies either common EAS or EAS registered to this EES for the UE based on the UE location, EAS discovery filters, application group profile, common EAS KPI as specified in Table 8.2.5-1 and EDN information, registered EAS KPI as specified in Table 8.2.5-1 and EDN information, and inter-EAS communication performance of these EASs and checks whether the common EAS or EAS registered to this EES can provide better E2E response time.
• When the UE is not in the overlapping area between the EDNs of common EAS and EAS registered to this EES (e.g. UE is not in the common EAS service area), the EES checks with the ECS-ER about all available common EASs and their corresponding EDNs by using procedure defined in clause 8.20.2.2. If no common EAS is available for the group, EES identifies one EAS for the group and interacts with the ECS-ER to store the common EAS information as described in clause 8.20.2.3. If current EDN already has available common EAS, the EES selects such common EAS considering UE location, EAS discovery filters, application group profile and the required E2E response time. If there are available common EASs in other EDNs, the EES identifies candidate EAS(s) for the group from its registered EASs and checks if the candidate EAS(s) can satisfy the E2E response time considering UE location, EAS discovery filters, application group profile, and the response time of the candidate EAS(s), the response time of available common EASs in other EDNs and the inter-EAS communication latency. If the E2E response time cannot be satisfied, the EES will respond the EEC in step 3 indicating such a rejection reason; otherwise, the EES selects a candidate EAS and interacts with the ECS-ER to store it as common EAS as described in clause 8.20.2.3.

Upon receiving the request from the EEC, the EES may also collect edge load analytics from ADAES (as specified in clause 8.8.2 of TS 23.436) or performance data from OAM to find whether the EAS(s) satisfies the Expected AC service KPIs or the Minimum required AC Service KPIs. Upon receiving the request from the EEC, if the EEC does not indicate EAS Instantiation Triggering Suppress in the EAS Discovery request, the EES may trigger the ECSP management system to instantiate the EAS that matches with EAS discovery filter IEs (e.g. ACID) as in clause 8.12. Otherwise, upon receiving the request from the EEC, if the EEC indicates EAS Instantiation Triggering Suppress in the EAS Discovery request and the EES supports such capability, the EES determines not triggering the ECSP management system to instantiate the EAS and may determine Instantiable EAS Information for EAS(s) that are instantiable but not yet instantiated and match the EAS discovery filter IEs. Instantiable EAS Information is provided in the EAS Discovery response and includes the EASID(s) and, for each EASID, the status indicating whether the EAS is instantiated or instantiable but not yet instantiated. If the EEC provides in the EAS discovery request the EAS selection request indicator, the EES selects EAS satisfying the EAS discovery filter or based on other information (e.g. ECSP policy) as described above (if no EAS discovery filter received), and then provides the selected EAS information to the EEC in the discovered EAS list of EAS discovery response. If the tunnel information is received, the EES additionally takes it into consideration in identifying EAS(s). If no tunnel information is received, the EES additionally takes the N6 tunnel (e.g. L2TP) information from 3GPP core network (via NEF user plane path management service as described in clause 5.6.7 of TS 23.501) or NATed UE IP address (e.g. by local UPF) into consideration in identifying EAS(s). For instance, the IP address(es) of identified EAS(s) needs to be topologically close to the IP address of the tunnel server or NATed UE for optimal N6 route.

If the processing of the request was successful, the EES sends an EAS discovery response to the EEC, which includes information about the discovered EASs and Instantiable EAS Information. For discovered EASs, this includes endpoint information. If the EES perform traffic influence for EAS(s) in step 2, then the discovered EAS(s) is with optimized traffic route. Depending on the EAS discovery filters received in the EAS discovery request, the response may include additional information regarding matched capabilities, e.g. service permissions levels, KPIs, AC locations(s) that the EASs can support, ACR scenarios supported by the EAS, etc. The EAS discovery response may contain a list of EASs and Instantiable EAS Information with EAS instantiation completion time. This list may be based on EAS discovery filters containing a Geographical or Topological Service Area, e.g. a route, included in the EAS discovery request by the EEC. When the discovered EAS is for a certain application group, then the Application Group ID is also included in the response message. If the discovered EAS is registered to another EES, then the EES endpoint of the EES where the discovered EAS is registered is also included in the response message. When the EES accepts the request and determines to trigger the EAS instantiation, then the response may indicate that the EAS instantiation is in progress so that the detailed EAS profile information will be available later. Then the EES determines the remaining EAS instantiation time or EAS instantiation completion time based on the timing receiving EAS instantiation in progress ECSP management system and the predicted EAS deployment time. When EEC receives the EAS instantiation in progress indication, the EEC may send EAS discovery subscription request message if not subscribed yet or send EAS discovery request message later to the EES for obtaining updated EAS information. If the EES is unable to determine the EAS information using the inputs in the EAS discovery request, UE-specific service information at the EES or the ECSP policy, the EES shall reject the EAS discovery request and respond with an appropriate failure cause. If the EEC is not registered with the EES, and ECSP policy requires the EEC to perform EEC registration prior to EAS discovery, the EES shall include an appropriate failure cause in the EAS discovery response indicating that EEC registration is required. If the UE location and predicted/expected UE locations, provided in the EAS discovery request, are outside the Geographical or Topological Service Area of an EAS, then the EES shall not include that EAS in the discovery response. The discovery response may include EAS(s) that cannot serve the UE at its current location if a predicted/expected UE location was provided in the EAS discovery request.