The support for EAS rediscovery indication procedure enables the UE to refresh stale EAS information stored locally so that the UE can trigger EAS discovery procedure to discover new EAS information.
For PDU Session with Session Breakout connectivity, the UE may indicate its support for refreshing stale EAS information to the SMF during the PDU Session Establishment procedure or, when the UE moves from EPS to 5GS for the first time, by using the PDU Session Modification procedure. If the UE indicates such support, the SMF may send to the UE the EAS rediscovery indication, with an optional impact field, so that the UE may trigger to re-discover the EAS (see the step 2 of Figure 18.104.22.168-1) after the insertion/change/removal of an L-PSA based on AF influence or its local configuration using the PDU Session Modification procedure, or based on the AF triggered EAS relocation.
This procedure is used by the SMF to trigger the EAS rediscovery procedure when a new connection to EAS need to be established. It applies to both Session Breakout using ULCL and Session Breakout using BP.
During a previous EAS Discovery procedure on this PDU Session the UE may have EAS information (i.e. EAS IP address corresponding to an EAS FQDN) locally stored, e.g. acquired during the previous connection with the EAS (for more information see Annex C UE considerations for EAS (re)discovery).
Due to the UE mobility the SMF triggers L-PSA insertion, change or removal for the PDU Session. The insertion, change or removal of L-PSA triggers EAS rediscovery.
The L-PSA insertion, change or removal for the PDU Session may be triggered due to update of a common DNAI.
The AF triggers EAS relocation e.g. due to EAS load balance or maintenance, etc. and informs the SMF the related information indicating the EAS relocation, as described in clause 4.3.6 AF influence on traffic routing procedure in TS 23.502.
This step may be performed as part of step 1a/1b. The SMF performs the network requested PDU Session Modification procedure from the step 3b-11b as defined in clause 22.214.171.124 of TS 23.502.
If the UE has indicated that it supports to refresh EAS information stored locally corresponding to the impact field per the EAS rediscovery indication from network, the SMF may send the impact field with the EAS rediscovery indication. SMF determines the impacted EAS(s) which need be rediscovered as the following:
If an L-PSA is inserted/relocated/removed, the SMF determines the impact field, which is associated with the L-DN to be inserted, relocated or removed and identified by FQDN(s) or IP address range(s) of the old EAS, based on the association between FQDN(s)/IP address range(s) and DNAI provided by AF or SMF local configuration on the L-DN.
For AF triggered EAS rediscovery, the AF may indicate the EAS rediscovery for the impacted applications, which are identified by Application Identifier(s), to the SMF via the AF influence on traffic routing procedure.
The SMF sends PDU Session Modification Command (EAS rediscovery indication, [impact field]) to UE. The EAS rediscovery indication indicates to refresh the cached EAS information. The impact field is used to identify which EAS(s) information need to be refreshed. The impact field includes the L-DN information corresponding to the impacted EAS(s), which are identified by FQDN(s) or IP address range(s) of the old EAS(s). If the impact field is not included, it means all EAS(s) information associated with this PDU Session need to be refreshed.
The SMF may choose new DNS settings for the PDU Session and if so, it provides them to the UE as new DNS server (see Option C in clause 126.96.36.199.3). Otherwise the UE uses the existing DNS server for EAS rediscovery.
For the following connection with the EAS(s) for which the EAS rediscovery needs to be executed per the received EAS rediscovery indication and impact field, the UE has been instructed not to use the old EAS information stored locally. Instead it should trigger EAS discovery procedure to get new EAS information as defined in clause 188.8.131.52.
For the Split-UE, it is not possible to provide the NAS level EAS rediscovery indication and the impact field to the TE. Annex C documents mitigations for this scenario.
EAS Deployment Information management refers to the capability to create, update or remove EAS Deployment Information from AF and the distribution to the SMF. The NEF is in charge of the management of EAS Deployment Information which may be stored in UDR.
The EAS Deployment Information indicates how edge services are deployed in each Local part of the DN, the description of EAS Deployment Information is shown in Table 184.108.40.206-1.
Addressing information of Application Function responsible for the DNAI in the record.
[optional]. See NOTE 1.
DNN for the EAS Deployment Information.
S-NSSAI for the EAS Deployment Information.
External Group Identifier/Internal Group Identifier
Group ID for the EAS Deployment information.
[optional]. See NOTE 2.
Identifies the application for which the EAS Deployment Information corresponds to.
Supported FQDN(s) for application(s) deployed in the Local part of the DN.
DNAI(s) for the EAS Deployment information.
DNS Server Information
list of DNS server identifier (consisting of IP address and port) for each DNAI.
EAS IP address range Information
IP address(es) of the EASs in the Local part of the DN or the IP address ranges (IPv4 subnetwork(s) and/or IPv6 prefix(es) of the Local part of the DN where the EAS is deployed for each DNAI.
N6 traffic routing information
Information about how to forward edge traffic in the local part of DN corresponding to DNAI.
When an AF ID is provided, all DNAI(s) correspond to the same EHE provider.
The AF may provide External Group Identifier, and NEF can map the External Group Identifier into Internal Group Identifier according to information received from UDM.
AF ID can be used in case of AF(s) involving different EHE providers, and the source EHE is unaware of other/target EHE specific deployment details.
The EAS Deployment Information management procedures are described in this clause, the procedures are independent of any PDU Session, including:
The procedure for EAS Deployment Information management from AF via the NEF.
The procedure for EAS Deployment Information management in the SMF.
The procedure for BaselineDNSPattern management in the EASDF.
NEF checks whether the AF is authorized to perform the request, and authorised to provision the EAS Deployment Information based on the operator policies. The NEF derives DNN and S-NSSAI from the AF Service Identifier if not received explicitly and translates received External Application Identifier to Application Identifier known inside MNO domain.
As pre-requisite condition, the SMF subscribes to EAS Deployment Information Change Notification from the NEF by sending Nnef_EASDeployment_Subscribe message. The SMF may indicate that the current status of EAS Deployment Information shall be notified immediately (if available). The SMF may indicate for which (list of) DNN and/or S-NSSAI and/or application identifier and/or Internal Group Identifier (if available) it subscribes.
The NEF invokes Nnef_EASDeployment_Notify (EAS Deployment Information) to the SMF(s) to which the EAS Deployment Information shall be provided. If there is EAS Deployment Information available and immediate report is required, the NEF notifies the SMF(s) with such information.
The SMF receives EAS Deployment Information as described in clause 220.127.116.11.1, and derives BaselineDNSPattern from the EAS Deployment Information. The BaselineDNSPattern is not dedicated to a specific PDU Session.
SMF may create/update/delete the BaselineDNSPattern in the EASDF.
The SMF invokes Neasdf_BaselineDNSPattern_Create/Update/Delete service operation of the EASDF to create/update/delete the BaselineDNSPattern. This interaction with the EASDF is a node level procedure, i.e. independent of any PDU Session.
In order to guarantee that the FQDN requested by the Application that intends to use EAS is resolved by the DNS Server (e.g. EASDF/DNS resolver) indicated by the SMF, the consumer in the UE uses the related EDC functionality to either:
Obtain the IP address of the DNS Server (e.g., EASDF/DNS resolver) indicated by the SMF (Optional).
The consumer in the UE requests the IP address of the DNS Server (e.g. EASDF/DNS resolver) indicated by the SMF. The EDC functionality shall send to the consumer in the UE the IP address of the DNS Server (e.g. EASDF/DNS resolver) or/and it shall notify the consumer in the UE of any update;
The consumer in the UE then generates and sends a DNS Query to the DNS Server (e.g. EASDF/DNS resolver) indicated via EDC functionality by the SMF.