6.2 EAS Discovery and Re-discovery

23.5483GPP5G System Enhancements for Edge ComputingRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.2.1 General

In Edge Computing deployment, an application service may be served by multiple Edge Application Servers typically deployed in different sites. These multiple Edge Application Servers that host service may use a single IP address (anycast address) or different IP addresses. To start such a service, the UE needs to know the IP address(es) of the Application Server(s) serving the service. The UE may do a discovery to get the IP address(es) of a suitable Edge Application Server (e.g. the closest one), so that the traffic can be locally routed to the Edge Application Server and service latency, traffic routing path and user service experience can be optimized.

EAS discovery is the procedure by which a UE discovers the IP address(es) of a suitable Edge Application Server(s) using Domain Name System (DNS). EAS Re-discovery is the EAS Discovery procedure that takes place when the previously discovered Edge Application Server cannot be used or may have become non-optimal (e.g. at edge relocation).

The DNS server to be used for EAS (re-)discovery may be deployed in different locations in the network as Central DNS (C-DNS) server or as Local DNS (L-DNS) resolver/server.

NOTE 1: The C-DNS servers and/or L-DNS resolvers/servers can use an anycast address.

NOTE 2: The C-DNS servers or L-DNS resolvers/servers can contact any other DNS servers for recursive queries, which is out of scope of this specification.

NOTE 3: This specification describes the discovery procedure based on 5GS NFs as to ensure the UE is served by the application service closest to the UE’s point of attachment. However, this does not exclude other upper layer solution that can be adopted by operator or service provider, like the EAS Discovery procedure defined in TS 23.558 [5], or other alternatives shown in Annex A and Annex B. How those other solutions work, or whether they are able to guarantee the closest application service for the UE, is out of the scope of this specification.

In order to provide a translation of the FQDN of an EAS into the address of an EAS as topologically close as possible to the UE, the Domain Name System may use following information:

– The source IP address of the incoming DNS Query; and/or,

– an EDNS Client Subnet (ECS) option (as defined in RFC 7871 [6]).

NOTE 4: UE IP address can be subject to privacy restrictions, which means that it is not to be sent to Authoritative DNS / DNS Resolvers outside the network operator within EDNS Client Subnet option or as Source IP address of the DNS Query. UE source IP address can be protected by using NAT mechanism.

EAS (re-)discovery procedures described in this specification should use the top level domains (TLDs) in the public namespace by default.

If a private namespace is used, an Edge Computing Service Provider (ECSP) can provision DNS information in the EAS Deployment information via AF request with its Application Identifier, or DNN and NSSAI. Since private namespaces do not have a common root server or naming, the DNS information for each ECSP should be stored individually to prevent any overwriting of resolution entries.

NOTE 5: The DNS information provided by ECSP in the EAS Deployment Information can be used to select the DNS settings for a PDU Session mainly if the PDU Session is specific for the ECSP services.

If the UE applications want to discover/access EAS by using the mechanisms defined in this TS, the UE shall support receiving DNS settings in PCO during PDU Session Establishment and PDU Session Modification, and the DNS Queries generated by the UE for these applications shall be sent to the DNS server/resolver (e.g. EASDF) indicated by the SMF. To ensure this, the application in the UE either requests the EDC functionality to send a DNS Query or, alternatively, uses the EDC functionality to get the IP address of the DNS Server (e.g. EASDF/DNS resolver) indicated by the SMF (see clause 6.2.4) then resolves the FQDN by its own DNS mechanism.

NOTE 6: It is the decision of the application in the UE whether to use the EDC functionality or not to resolve the FQDN. If it does not use the EDC functionality, the usage of the EAS (re-)discovery procedures defined in clause 6.2 cannot be ensured.

The case of EAS (Re-)discovery over Distributed Anchor connectivity model is described in clause 6.2.2. For Multiple PDU Sessions connectivity model, the description in clause 6.2.2 also applies to the PDU Session(s) with Local PSA. The case of EAS (Re-)discovery over Session Breakout connectivity model is described in clause 6.2.3.

6.2.2 EAS (Re-)discovery over Distributed Anchor Connectivity Model

6.2.2.1 General

6.2.2.2 EAS Discovery Procedure

For the Distributed Anchor connectivity model, in PDU Session Establishment procedure, the SMF selects a DNS Server for the PDU Session. The DNS Server is configured to UE via PCO, and may also be configured via DHCP and/or IPv6 RA. The SMF determines the DNS server address for the PDU Session based on local configuration and EAS Deployment Information provided by AF when applicable.

In order to provide a translation of the FQDN of an EAS into the address of an EAS as close as possible to the UE (where closeness relates to IP forwarding distance), the DNS system uses mechanisms described in clause 6.2.1.

For Distributed Anchor Point connectivity model, in order to provide addressing information to the DNS system that is related to the UE topological location, when a DNS Query is sent via the Local PSA UPF,

– either the DNS Query is resolved by a DNS resolver, which then adds a DNS EDNS Client Subnet option that may be built based on a locally pre-configured value or based on the source IP address of the DNS Query; then send the DNS Query to the Authoritative DNS server, which may take into account the DNS EDNS Client Subnet option as defined in RFC 7871 [6], or

– the DNS Query is resolved by a DNS server that is close to the PSA UPF: the Authoritative DNS server may take into account the source IP address of the DNS Query.

6.2.2.3 EAS Re-discovery Procedure at Edge Relocation

In order to change the PDU Session Anchor serving a PDU Session of SSC mode 2/3 for a UE, SMF triggers session continuity, service continuity and UP path management procedures as indicated in clause 4.3.5.1, 4.3.5.2 and 4.3.5.3 of TS 23.502 [3]. During these procedures, for SSC mode 2/3, it is recommended that the UE applies the following behaviour:

The UE DNS cache should be bound to the IP connection. When the UE detects the PDU Session release or new IP prefix is allocated within the PDU Session, the UE removes the old DNS cache related to old/removed IP address/prefix, for example, the old Edge Application Server address information.

NOTE 1: UE DNS cache refers to cache at any level (OS and Application). Whether the DNS cache of Application is included or influenced depends on application’s behaviour and UE implementation.

With this behaviour, when the establishment of a new PDU Session triggers EAS rediscovery for an FQDN, the UE can reselect a new EAS for that FQDN.

For SSC mode 2, the procedure in clause 4.3.5.1 of TS 23.502 [3] applies with following differences:

– In step 3, when the new PDU Session has been established, UE can reselect a new EAS for the FQDN with an EAS Discovery procedure if the recommended UE behaviour has been followed.

For SSC mode 3 with multiple PDU Sessions, the procedure in clause 4.3.5.2 of TS 23.502 [3] applies with following difference:

– In step 5, the UE can reselect a new EAS for the FQDN with an EAS Discovery procedure if the recommended UE behaviour has been followed.

For SSC mode 3 with IPv6 Multi-homed PDU Session that all new traffic going via new IPv6 prefix, the procedure in clause 4.3.5.3 of TS 23.502 [3] applies with following difference:

– After steps 10-11 where SMF notifies the UE of the availability of the new IP prefix, the UE starts using it for all new traffic, including DNS Queries. The UE can reselect a new EAS for the FQDN with an EAS Discovery procedure if the recommended UE behaviour has been followed.

Then UE can reselect a new EAS for the FQDN with an EAS discovery procedure as defined in clause 6.2.2.2.

NOTE 2: For SSC mode 3 with Multi-homed PDU Sessions, an EAS re-discovery indication may as well be sent as described in clause 6.2.3.3.

The SMF may also trigger EAS rediscovery as defined in clause 6.2.3.3 when new connection to EAS needs to be established in case the UE indicate support for this. This trigger may also be used by the SMF based on the AF trigged EAS relocation as described in clause 6.3.7.

6.2.2.4 Procedure for EAS Discovery with Dynamic PSA Distribution

5GC supports an EAS discovery procedure that allows that at PDU Session Establishment the SMF selects a Central PSA, regardless if a Local PSA is available to the SMF and then, it allows to dynamically re-anchor the PDU Session and transition to a Distributed Anchor Point connectivity model when needed. This is applicable to PDU Sessions of both SSC mode 2 and SSC mode 3.

This procedure relies on EASDF capability to influence the DNS Query of a FQDN so that the EAS Discovery considers a candidate UE topological location of a PSA further out in the network than current PSA. The PDU Session re-anchoring to the edge is performed as part of the EAS Discovery procedure.

This procedure requires that the DNS settings provided to the UE for the PDU Session are respected.

Figure 6.2.2.4-1 Application server discovery with Dynamic PSA distribution using EASDF

The EAS Discovery procedure with Dynamic PSA distribution for both SSC mode 2 and SSC mode 3 PDU Sessions using EASDF is described in Figure 6.2.2.4.-1.

The procedure is as follows:

1. PDU Session Establishment, allocation of an EASDF and sending rules to the EASDF. Steps 1-6 in the procedure 6.2.3.2.2-1 for EAS Discovery Procedure with EASDF for Session Breakout connectivity model are applied. If Dynamic PSA distribution applies to the PDU Session based on SMF local configuration, the SMF may have selected a Central PSA at PDU Session Establishment, regardless of whether a Local PSA is available.

2. The UE sends a DNS Query message for an FQDN to the EASDF via Central PSA. Steps 7-12 in the procedure in figure 6.2.3.2.2-1 for EAS Discovery Procedure with EASDF for Session breakout Connectivity are applied. That is, the EASDF checks the DNS Query against the DNS Handling Rules in the DNS Context and reports to SMF and/or forwards to DNS for resolution as instructed by these rules. For resolution, it applies Option A or option B in the procedure 6.2.3.2.2-1 or sends the DNS Query to a pre-configured DNS server/resolver if none of them applies.

When the DNS Response is received, EASDF checks it against the DNS context matching conditions for reporting. If applicable, it reports to SMF the selected EAS and handles the DNS Response as instructed by SMF DNS handling rules: when there is a change of PDU Session Anchor per SSC mode 2 or 3, the SMF indicates to EASDF to discard the DNS Response.

When no DNS Response is sent to the UE, the UE is expected to restart the DNS Query over the new PDU Session).

For further details see clause 6.2.3.2.2.

SMF determines that the central UPF (PSA) needs to be changed to an Edge UPF (L-PSA) and it triggers one of the procedures to change the PSA of the PDU Session to a distributed anchor. Which procedure is triggered depends on the SSC mode of the PDU Session and also on SMF configuration:

– Change of SSC mode 2 PDU Session Anchor with different PDU Sessions as in clause 4.3.5.1 of TS 23.502 [3]. The procedure applies with the following differences:

In step 2, the DNS context for the session is removed from EASDF as part of the PDU Session Release procedure (in step 12 of the PDU Session release procedure in TS 23.502 [3] in 4.3.4.2).

In step 3, SMF selects and provisions the DNS settings for the new PDU Session as required by the procedure for EAS Discovery on Distributed anchor as described in clause 6.2.2.2.

– Change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions as in clause 4.3.5.2 of TS 23.502 [3]. The procedure applies with the following differences:

In step 4 in clause 4.3.5.2 of TS 23.502 [3], SMF selects and provisions the DNS settings for the new PDU Session as required by the procedure for EAS Discovery on Distributed anchor as described in clause 6.2.2. Step 3 in 6.2.2.4 could happen any time after this step.

In step 6 in clause 4.3.5.2 of TS 23.502 [3], the old DNS context for the old session and old UE IP address/prefix of UE are removed from EASDF as part of the PDU Session Release procedure (in step 12 of the PDU Session Release procedure in TS 23.502 [3] in 4.3.4.2).

– Change of SSC mode 3 PDU Session Anchor with IPv6 Multi-homed PDU Session as in clause 4.3.5.3 of TS 23.502 [3]. The procedure applies with the following differences:

In steps 10-11 in clause 4.3.5.3 of TS 23.502 [3], SMF also manages the EASDF context and provides new DNS settings to the UE if needed:

– If EASDF is not going to be used, SMF sends the UE the new DNS settings in a PDU Session Modification Command and removes the EASDF context.

– If EASDF is going to be used, SMF may update existing EASDF context or it may remove it and create a new one, for example, to select a new EASDF. If a new EASDF is selected, SMF sends the UE the new DNS settings in a PDU Session Modification Command and may also send them in Router Advertisement.

After steps 10-11 in clause 4.3.5.3 of TS 23.502 [3], UE starts using IP@2 for all new traffic, including DNS messages, and SMF can already perform from step 3 in figure 6.2.2.4-1.

The PDU Session establishment in this step includes the actions described above in step 1 in figure 6.2.2.4-1 if DNS Queries should be able to trigger re-anchoring of the session to a more distributed PSA.

NOTE 1: When new DNS settings do not involve EASDF, new DNS Query will not trigger re-anchoring of the PDU Session to a L-PSA deployed even further out in the network.

To remove the Session context in EASDF, SMF invokes Neasdf_DNSContext_Delete Request/Response.

NOTE 2: Dynamic re-anchoring to an edge PSA implies that the UE IP address is changed from a UE IP address corresponding to the old (central) PSA to a UE IP address corresponding to the new (edge) PSA for all applications on the PDU Session.

NOTE 3: Further re-anchoring (to a central UPF) can be triggered if activity is monitored e.g. if EC application traffic ceases. In that case, EASDF is provided again in the DNS settings for the PDU Session. New EAS Discovery will go to EASDF and be handled as described in step 1.

3. A new discovery procedure is triggered for the application over the new PSA: the UE resends a DNS Query targeting the application. (Re)discovery follows the EAS (re)Discovery procedure for distributed anchor connectivity model as in clauses 6.2.2.2 and 6.2.2.3.

NOTE 4: Clause 6.2.2.3 describes the UE behaviour that makes it possible to reselect a new EAS over the new PSA. With change of SSC mode 3 PDU Session Anchor with IPv6 Multi-homed PDU Session, an EAS rediscovery indication can as well be sent as described in clause 6.2.3.3.

4. Application traffic starts via the PDU Session Edge PSA to the EAS selected in step 3.

6.2.3 EAS (Re-)discovery over Session Breakout Connectivity Model

6.2.3.1 General

This clause describes the EAS discovery and re-discovery procedures for PDU Session with Session Breakout connectivity model.

The following Session breakout models are defined:

– Dynamic Session Breakout: ULCL/BP/Local PSA (and their associated traffic filters and forwarding rules) are inserted based on DNS Response provided by the EASDF. The detail of the ULCL/BP/Local PSA insertion or relocation triggered by the DNS Response message received for the EAS (Re-)discovery is described in the procedure in clause 6.2.3.2.2.

– Pre-established Session Breakout: ULCL/BP/Local PSA (and their associated traffic filters and forwarding rules) are inserted without dependency on the DNS Response(s) for the EAS (Re-)discovery. They are typically inserted based on local configuration or per traffic routing information from AF request within AF influence on traffic routing procedure. For the ULCL/BP/Local PSA insertion or relocation triggered by traffic routing information from AF request, the traffic routing information from AF request is received by the SMF via the SM policy which is created during the procedure PDU Session establishment or is updated during the lifetime of the PDU Session (e.g. updating the SM policy with the traffic routing information based on the detected application identifier based on the received application traffic like DNS Query or service data for the application). The details are described in clauses 4.3.5 and 6.2.1.2 of TS 23.503 [4] and in clause 5.6.7.1 of TS 23.501 [2] and in clause 4.3.6.2 of TS 23.502 [3].

6.2.3.2 EAS Discovery Procedure

6.2.3.2.1 General

For PDU Session with Session Breakout connectivity model, based on UE subscription (e.g. DNN) and/or the operator’s configuration, the DNS Query sent by UE may be handled by an EASDF (see clause 6.2.3.2.2), or by a local or central DNS resolver/server (see clause 6.2.3.2.3).

NOTE 1: For the scenario where the TE and MT are separated, information provided by the SMF in the NAS message during the PDU Session Establishment or Modification may not be provided to the TE. Annex C documents mitigations for this scenario.

NOTE 2: The DNS Query sent by UE may or may not carry EDNS Client Subnet option in the DNS message.

6.2.3.2.2 EAS Discovery Procedure with EASDF

For the case that the UE DNS Query is to be handled by EASDF, the following applies.

– The AF may provide EAS Deployment Information to NEF which may store it in UDR, as defined in clause 6.2.3.4. SMF may retrieve EAS Deployment Information from NEF as described in clause 6.2.3.4 or has locally preconfigured information. EAS Deployment Information is used for creating DNS message handling rule on EASDF and it is not dedicated to specific UE session(s).

EAS Deployment Information may apply to all PDU Sessions with a certain DNN, S-NSSAI and/or specific Internal Group Identifier(s).

– The SMF may provide BaselineDNSPattern to EASDF, the BaselineDNSPattern are derived from EAS Deployment Information provided by AF and are not dedicated to specific PDU Session; SMF configures EASDF with BaselineDNSPattern according to the procedures defined in clause 6.2.3.4.

The Baseline DNS message detection template ID may be used by the EASDF to refer to Baseline DNS message detection template, and derive array of FQDN ranges and/or array of EAS IP address ranges. The Baseline DNS handling actions ID may be used by the EASDF to refer to Baseline DNS handling actions information, and derive actions related parameters.

The Baseline DNS message detection template ID and the Baseline DNS handling actions ID are unique per SMF set when a SMF set controls an EASDF and shall be unique per SMF otherwise, within an EASDF Baseline

BaselineDNSPattern may contain one or several items, where each item is either a Baseline DNS message detection template or a Baseline DNS handling actions information. Each BaselineDNSPattern item may be updated or deleted using Baseline DNS message detection template ID or Baseline DNS handling actions ID to identify the updated or deleted item

– Baseline DNS message detection template

– Baseline DNS message detection template ID

– DNS message type = DNS Query or DNS Response:

– If DNS message type = DNS Query:

– Array of (FQDN ranges).

– If DNS message type = DNS Response:

– Array of FQDN ranges and/or array of EAS IP address ranges.

– Baseline DNS handling actions information:

– Baseline DNS handling actions ID:

– ECS option.

– Local DNS server IP address.

NOTE 1: The FQDN can be set to wildcard to indicate the default DNS Server (e.g. the C-DNS), for the case in which the DNS message should be forwarded to the default DNS Server.

NOTE 2: The BaselineDNSPattern can be configured for a specific application with the related FQDN set in the detection template.

NOTE 3: The definition of structure of Baseline DNS handling actions ID and Detection template ID is left to stage 3. As an example, Baseline DNS handling action ID and Detection template ID could contain a concatenation of the SMF ID or SMF set Id and of SMF implementation selected information such as the DNAI or a sequence number. The EASDF is not meant to understand the structure of Baseline DNS handling actions ID and Detection template ID.

– During the PDU Session establishment procedure, the SMF may obtain the EAS Deployment Information from the NEF if not already retrieved (by subscription of such information to the NEF as described in clause 6.2.3.4.3) or the SMF is preconfigure with the EAS Deployment Information and the SMF selects an EASDF and provides its address to the UE as the DNS Server to be used for the PDU Session.

The SMF configures the EASDF with DNS message handling rules to handle DNS messages related to the UE(s). The DNS message handling rule has a unique identifier and includes information used for DNS message detection and associated action(s). The DNS handling rules is defined as following:

– Precedence of the DNS message handling rule;

– DNS Handling Rule Identity;

– A Baseline DNS message detection template ID and/or a DNS message detection template (optional and includes at least one of the following, if existing):

– DNS message type = DNS Query or DNS Response:

– If DNS message type = DNS Query:

– Source IP address (i.e. UE IP address).

– Array of (FQDN ranges) (optional).

– If DNS message type = DNS Response:

– Array of FQDN ranges and/or array of EAS IP address ranges (optional).

– DNS message Identifier (if received from EASDF);

NOTE 4: For DNS message type = Query, the UE IP address provided at DNS context creation (Neasdf_DNSContext_Create Request) is considered if not provided explicitly as part of the DNS message detection template.

NOTE 5: DNS message Identifier is used by EASDF for matching between the message reported in the Neasdf_DNSContext_Notify and the corresponding DNS message handling rule included in Neasdf_DNSContext_Update.

– Action(s) (includes at least one action); the possible actions include:

– Reporting Action: Report DNS message content to SMF (i.e. target FQDN and if available: IP address information provided back by the DNS server). This reporting action may include reporting-once indication. If this indication is included, the EASDF reports the DNS message content to the SMF once if the DNS message detection template matches the first incoming DNS Query or DNS Response message.

NOTE 6: With reporting-once indication, the DNS message detection template should contain the EAS IP address ranges corresponding to the same DNAI. Resetting the Reporting-once indication can be used by the SMF to allow reporting associated with a DNS handling rule when the SMF has removed the UL-CL/BP e.g. when the UE has moved out of the area associated with the current DNAI and thus insertion of a new UPF offloading capability can be considered.

– Forwarding Action: Send the DNS message(s) to a DNS server/resolver(s) as follows:

A. Including the information to build optional EDNS Client Subnet option to be included in the DNS message, or to be used for replacing the EDNS Client Subnet option received in the DNS Query message from the UE. (The information for the EASDF to build the EDNS Client Subnet option is either included in the DNS handling rule, or Baseline DNS handling actions ID acts as a reference to the Baseline DNS handling actions Information. This corresponds to the option A defined below.

B. the information for the DNS message target address is either included as DNS Server Address indicated in the DNS handling rule, or the Baseline DNS handling actions ID included in the DNS handling rules refers to DNS message target address information; if no DNS Server Address is provided by the SMF in the rule, then the EASDF is to forward the DNS message to a locally preconfigured default DNS server/resolver. This corresponds to the option B defined below.

NOTE 7: The forwarding action can include either A or B.

– Control Action: Performs at least one of control actions on the DNS message(s) as follows:

– Buffer the DNS message(s).

– Send the buffered DNS Response(s) message to UE.

– Discard cached DNS Response message(s).

When the EASDF forwards a DNS message (to the UE or towards a DNS server over N6), it uses its own address as the source address of the DNS message. When the EASDF forwards the DNS message to the UE the EASDF based on configuration either replace the received EDNS Client Subnet option with the one provided by the UE (i.e. if provided by the UE) or remove any received EDNS Client Subnet.

The SMF may use following information to create DNS message handling rules associated with a PDU Session:

– Local configuration associated with the (DNN, S-NSSAI, Internal Group Identifier) of the PDU Session; and/or

– EAS Deployment Information provided by the AF or preconfigured in the SMF; and/or

– Information derived from the UE location such as candidate L-PSA(s); and/or

– PDU Session information, like PDU Session L-PSA(s) and ULCL/BP; and/or

– Internal Group Identifier received in the Session Management Subscription data from the UDM;

NOTE 7: For example, the SMF can derive the IP address for ECS based on the N6 IP address(es) associated with serving L-PSA(s) locally configured or in the NRF.

NOTE 8: Providing in DNS EDNS Client Subnet option an IP address associated with the L-PSA UPF protects the privacy of the (IP address of the) UE.

– If the FQDN in a DNS Query matches the FQDN(s) provided by the SMF in a DNS message detection template, based on instructions by SMF, one of the following options is executed by the EASDF based on a corresponding DNS message handling rule:

– Option A: The EASDF includes or replaces an EDNS Client Subnet (ECS) option into the DNS Query message as defined in RFC 7871[6] and sends the DNS Query message to the DNS server for resolving the FQDN. The DNS server may resolve the EAS IP address considering the EDNS Client Subnet option and sends the DNS Response to the EASDF;

– Option B: The EASDF sends the DNS Query message to a Local DNS server which is responsible for resolving the FQDN within the corresponding L-DN. The EASDF receives the DNS Response message from the Local DNS server.

NOTE 9: Option B does not support the scenario where the PSA UPF for transferring DNS Query between EASDF and DNS server, or the EASDF has no direct connectivity with the Local DNS servers.

The SMF instructions for a matching FQDN may as well indicate EASDF to contact SMF. SMF then provides the EASDF with a DNS message handling rule;

– If the DNS Query from the UE does not match a DNS message handling rules set by the SMF, then the EASDF may simply forward the DNS Query towards a preconfigured DNS server/resolver for DNS resolution;

– When the EASDF receives a DNS Response message, the EASDF notifies the EAS information (i.e. EAS IP address(es), the EAS FQDN and if available the corresponding IP address within the ECS DNS option) to the SMF if the DNS message reporting condition provided by the SMF is met (i.e. the EAS IP address or FQDN is within the IP/FQDN range). The SMF may then select the target DNAI based on the EAS information and trigger UL CL/BP and L-PSA insertion as specified in clause 6.3.3 in TS 23.501 [2] based on the Notification.

NOTE 10: To avoid SMF overloading caused by massive reporting, the overload control mechanisms defined in clause 6.4 of TS 29.500 [9] can be used.

The information to build the EDNS Client Subnet option or the Local DNS server address provided by the SMF to the EASDF are part of the DNS message handling rules to handle DNS Queries from the UE. This information is related to DNAI(s) for that FQDN(s) for the UE location. The SMF may provide DNS message handling rules to handle DNS Queries from the UE to the EASDF when the SMF establishes the association with the EASDF for the UE and may update the rules at any time when the association exists. For the selection of the candidate DNAI for a FQDN for the UE, the SMF may consider the UE location, network topology, EAS Deployment Information and related policy information for the PDU Session provided as defined in clause 6.4 of TS 23.503 [4] or be preconfigured into the SMF. After the UE mobility, if the provided Information for EDNS Client Subnet option or the Local DNS server address needs to be updated, the SMF may send an update of DNS message handling rules to the EASDF.

NOTE 11: If multiple candidate DNAIs are available after considering the UE location, network topology and EAS deployment, the SMF selects one DNAI from the multiple ones based on operator’s policy. For examples, the SMF can select the DNAI randomly, or based on selection weight factor if provided by AF, or select the DNAI closest to the UE location.

NOTE 12: To protect the SMF (e.g. to block DOS from the EASDF), the EASDF IP address for DNS Query Request is only accessible from the UE IP address via UPF.

Once the UL CL/BP and L-PSA have been inserted, the SMF may decide that the DNS messages for the FQDN are to be handled by Local DNS resolver/server from now on. This option is further described in clause 6.2.3.2.3.

To avoid EASDF sending redundant DNS message reports triggering UL CL/BP insertion corresponding to the same DNAI, the SMF may send reporting-once control information (i.e. DNS message handling rule with DNS message detection template containing EAS IP address ranges with reporting-once indication set) to EASDF to instruct the EASDF to report only once for the DNS messages matching with the DNS message detection template of the reporting-once control information for the DNS message detection template. In addition, the SMF may instruct the EASDF not to report DNS Responses to SMF corresponding to some FQDN ranges and/or EAS IP address ranges e.g. once the UL CL/BP and L-PSA have been inserted for the corresponding EAS IP address ranges for Pre-established session breakout while there is configuration for the related EASDF reporting DNS Responses. After the removal or change of the L-PSA, the SMF may instruct the EASDF to restart the reports of the DNS messages.

If the SMF, based on local configuration, decides that the interaction between EASDF and DNS Server in the DN shall go via an UPF, the SMF sends corresponding N4 rules to this UPF to instruct this UPF to forward DNS message between EASDF and the external DNS server. In this case, DNS messages between EASDF and DNS Server described in this clause are transferred via this UPF transparently.

NOTE 13: Based network configuration, one UPF is used to transmit DNS signalling between EASDF and DNS servers. The N4 session between the SMF and this UPF is not related to a specific PDU Session but provides rules targeting Downlink traffic from DNS servers to the EASDF and associated with the traffic of multiple UE(s); the traffic forwarding between EASDF and this UPF is realized by IP in IP tunnelling .The EASDF provides the SMF with the source address it uses to contact DNS servers and with the destination address where it expects to receive the tunnelled traffic.

Figure 6.2.3.2.2-1: EAS discovery procedure with EASDF

1. UE sends PDU Session Establishment Request to the SMF as shown in step 1 of clause 4.3.2.2.1 of TS 23.502 [3]. The SMF retrieves the UE subscription information from the UDM (which may optionally include an indication on UE authorization for EAS discovery via EASDF) and checks if the UE is authorized to discover the EAS via EASDF. If not authorized, this procedure is terminated, and the subsequent steps are skipped.

2. During the PDU Session Establishment procedure, the SMF selects EASDF as described clause 6.3 of TS 23.501 [2]. The SMF may consider the UE subscription information to select an EASDF as the DNS server of the PDU Session.

The SMF may indicate to the UE either that for the PDU Session the use of the EDC functionality is allowed or that for the PDU Session the use of the EDC functionality is required.

If the SMF, based on local configuration, decides that the interaction between EASDF and DNS Server in the DN shall go via the PSA UPF, the SMF configures PSA UPF within N4 rules to forward the DNS message between EASDF and DN.

3. The SMF invokes Neasdf_DNSContext_Create Request (UE IP address, SUPI, DNN, notification endpoint, (DNS message handling rules)) to the selected EASDF.

This step is performed before step 11 of PDU Session Establishment procedure in clause 4.3.2.2.1 of TS 23.502 [3].

The EASDF creates a DNS context for the PDU Session and stores the UE IP address, SUPI, the notification endpoint and potentially provided DNS message handling rule(s) into the context.

The EASDF is provisioned with the DNS message handling rule(s), before the DNS Query message is received at the EASDF or as a consequence of the DNS Query reporting.

4. The EASDF invokes the service operation Neasdf_DNSContext_Create Response.

After this step, the SMF includes the IP address of the EASDF as DNS server/resolver for the UE in the PDU Session Establishment Accept message as defined in step 11 of clause 4.3.2.2.1 of TS 23.502 [3]. The UE configures the EASDF as DNS server for that PDU Session.

If the UE requested to obtain UE IP address via DHCP and the SMF supports DHCP based IP address configuration, the SMF responds to the UE via DHCP response with the allocated UE IP address and/or the DNS server address containing the IP address of the EASDF.

5. The SMF may invoke Neasdf_DNSContext_Update Request (EASDF Context ID, (DNS message handling rules)) to EASDF. The update may be triggered by UE mobility, e.g. when UE moves to a new location, or by a reporting by EASDF of a DNS Query with certain FQDN, or, the update may be triggered by insertion/removal of Local PSA, e.g. to update rules to handle DNS messages from the UE or by new PCC rule information.

6. The EASDF responds with Neasdf_DNSContext_Update Response.

7. If required (see clause 5.2.1), the Application in the UE uses the EDC functionality as described in clause 6.2.4 to send the DNS Query to the EASDF. The UE sends a DNS Query message to the EASDF.

8. If the DNS Query message matches a DNS message detection template of DNS message handling rule for reporting, the EASDF sends the DNS message report to SMF by invoking Neasdf_DNSContext_Notify Request (information from the DNS Query e.g. target FQDN of the DNS Query). The EASDF may add a DNS message identifier in the Neasdf_DNSContext_Notify. The DNS message identifier uniquely identifies the DNS message reported and is used to associate the corresponding DNS message handling rule included in Neasdf_DNSContext_Update Request with the identified DNS message. The DNS message identifier is generated by EASDF.

9. The SMF responds with Neasdf_DNSContext_Notify Response.

10. If DNS message handling rule for the FQDN received in the report need to be updated, e.g. provide updates to information to build/replace the EDNS Client Subnet option information, the SMF invokes Neasdf_DNSContext_Update Request (DNS message handling rules) to EASDF. If the EASDF provided a DNS message identifier, the SMF adds this DNS message identifier to the corresponding DNS message handling rule included in Neasdf_DNSContext_Update. If the EASDF did not provide a DNS message identifier, the SMF may use the DNS message type (Request) and the target FQDN to uniquely identify the DNS message.

For Option A, the DNS handling rule includes corresponding IP address to be used to build/replace the EDNS Client Subnet option. For Option B, the DNS handling rule includes corresponding Local DNS Server IP address. The EASDF may as well be instructed by the DNS handling rule to simply forward the DNS Query to a pre-configured DNS server/resolver.

11. If the SMF provided a DNS message handling rule with DNS message identifier, the EASDF only applies the DNS message handling rule to the corresponding DNS message. The EASDF responds with Neasdf_DNSContext_Update Response.

12. The EASDF handles the DNS Query message received from the UE as the following:

– For Option A, the EASDF adds/replaces the EDNS Client Subnet option into the DNS Query message as specified in RFC 7871[6] and sends it to C-DNS server;

– For Option B, the EASDF removes EDNS Client Subnet option if received in the DNS query and sends the DNS Query message to the Local DNS server.

If no DNS message detection template within the DNS message handling rule provided by the SMF matches the requested FQDN in the DNS Query, the EASDF may simply send a DNS Query to a pre-configured DNS server/resolver.

13. EASDF receives the DNS Response including EAS IP addresses which is determined by the DNS system and determines that the DNS Response can be sent to the UE.

14. The EASDF sends DNS message reporting to the SMF by invoking Neasdf_DNSContext_Notify request including EAS information if the EAS IP address or the FQDN in the DNS Response message matches the DNS message detection template provided by the SMF. The DNS message reporting may contain multiple EAS IP address if the EASDF has received multiple EAS IP address(es) from the DNS server it has contacted. The DNS message reporting may contain the FQDN and the EDNS Client Subnet option received in the DNS Response message. The EASDF may also add DNS message identifier to the reporting. The DNS message identifier uniquely identifies the DNS response reported, and the EASDF can associate the corresponding DNS message handling rule included in Neasdf_DNSContext_Update Request with the identified DNS response. The DNS message identifier is generated by EASDF.

Per the received DNS message handling rule, the EASDF does not send the DNS Response message to the UE but waits for SMF instructions (in step 17), i.e. buffering the DNS Response message.

If the DNS Response(s) is required to be buffered and reported to the SMF, when the reporting-once control information is set, EASDF only reports to SMF once by invoking Neasdf_DNSContext_Notify request for DNS Responses matching with the DNS message detection template.

15. The SMF invokes Neasdf_DNSContext_Notify Response service operation.

16. The SMF may perform UL CL/BP and Local PSA selection and insert UL CL/BP and Local PSA.

Based on EAS information received from the EASDF in Neasdf_DNSContext_Notify, other UPF selection criteria, as specified in clause 6.3.3 in TS 23.501 [2], and possibly Service Experience or DN performance analytics for an Edge Application as described in TS 23.288 [10], the SMF may determine the DNAI and determine the associated N6 traffic routing information for the DNAI. The SMF may perform UL CL/BP and Local PSA selection and insertion as described in TS 23.502 [3]. In case of UL CL, the traffic detection rules and traffic routing rules are determined by the SMF based on IP address range(s) per DNAI included in the EAS Deployment Information or according to PCC rule received from PCF or according to preconfigured information.

17. The SMF invokes Neasdf_DNSContext_Update Request (DNS message handling rules). If the EASDF provided a DNS message identifier, the SMF adds this to the corresponding DNS message handling rule included in Neasdf_DNSContext_Update Request. If the EASDF did not provide a DNS message identifier, the SMF may use the DNS message type (Response) and the FQDN to uniquely identify the DNS response message.

The DNS message handling rule with the Control Action "Send the buffered DNS response(s) message to UE" indicates the EASDF to send DNS Response(s) buffered in step 14 to UE. Other DNS message handling rule may indicate the EASDF not to send further DNS Response message(s) corresponding to FQDN ranges and/or EAS IP address ranges.

18. If the SMF provided a DNS message handling rule with DNS message identifier, the EASDF only applies the DNS message handling rule to the corresponding DNS response. The EASDF responds with Neasdf_DNSContext_Update Response.

19. If indicated to send the buffered DNS response(s) to UE in step 17, the EASDF sends the DNS Response(s) to the UE and handles the EDNS Client Subnet option as described above.

During PDU Session Release procedure, the SMF removes the DNS context by invoking Neasdf_DNSContext_Delete service.

6.2.3.2.3 EAS Discovery Procedure with Local DNS Server/Resolver

For the case that the DNS message is to be handled by Local DNS resolver/server, the DNS Query is routed to the Local DNS resolver/server corresponding to the DNAI where the L-PSA connects. The SMF selects the Local DNS server address based on the DNAI corresponding to the inserted local PSA, local configuration and based on EAS Deployment Information in AF request as specified in clause 6.2.3.4.2. Based on the operator’s configuration, one of the following options may apply when UL CL/BP and Local PSA have been inserted (during or after PDU Session Establishment):

– Option C: The SMF configures the local DNS server to the UE as new DNS server. The SMF may indicate to the UE either that for the PDU Session the use of the EDC functionality is allowed or that for the PDU Session the use of the EDC functionality is required. In addition, the SMF also configures traffic routing rule on the UL CL (including e.g. Local DNS server address) or the BP (e.g. the new IP prefix @ Local PSA) to route traffic destined to the L-DN including the DNS Query messages to the L-PSA. The L-DNS server resolves the DNS Query either locally or recursively by communicating with other DNS servers.

– Option D: If the SMF has been configured that DNS Queries for an FQDN (range) query can be locally routed on the UL CL, then the subsequent DNS Queries for the FQDN (range) will be locally routed to a Local DNS server.

NOTE 1: Option D assumes that ULCL steering is based on L4 information (i.e. DNS port number) and that ULCL has visibility of the DNS traffic (i.e. FQDN in the DNS Query message). The UPF may be instructed by the SMF to apply different forwarding of non-ciphered UL DNS traffic based on the target domain of the DNS Query. Option D requests modification of destination IP address of DNS messages. Whether this is allowed or not is subject to local regulations. Option D does not apply to DoH or DoT messages.

Figure 6.2.3.2.3-1: EAS discovery with Local DNS server/resolver

0. UE sends a PDU Session Establishment Request to the SMF as shown in step 1 of clause 4.3.2.2.1 of TS 23.502 [3]. The SMF retrieves the UE subscription information from the UDM (which may optionally include an indication on UE authorization for EAS discovery via EASDF) and checks if the UE is authorized to discover the EAS via EASDF. If not authorized, the actions related to EASDF in this procedure are skipped.

1. The SMF inserts UL CL/BP and Local PSA.

UL CL/BP/Local PSA insertion can be triggered by DNS messages as described in clause 6.2.3.2.2. Or, the SMF may pre-establish the UL CL/BP and Local PSA before the UE sends out any DNS Query message (e.g. upon UE mobility). In this case, the SMF includes the IP address of Local DNS Server in PDU Session Establishment Accept message as in step 11 of clause 4.3.2.2.1 of TS 23.502 [3] or in a network initiated PDU Session Modification procedure. The UE configures the Local DNS Server as DNS server for that PDU Session.

NOTE 2: If the new DNS server address is provided to the UE, the UE can refresh all EAS(s) information (e.g. DNS cache) bound to the PDU Session, based on UE implementation.

The UL CL/BP and Local PSA are inserted or changed as described in TS 23.502 [3]. In the case of IPv6 multi-homing, the SMF may also send an IPv6 multi-homed routing rule along with the IPv6 prefix to the UE to influence the selection of the source Prefix for the subsequent DNS Queries as described in clause 5.8.2.2.2 of TS 23.501 [2].

When the UL CL/BP and Local PSA are inserted or simultaneously changed, the SMF configure the UL CL/BP for DNS Query handling:

– For Option C, the SMF configures traffic routing rule on the UL CL (including e.g. Local DNS server address) or the BP (e.g. the new IP prefix @ Local PSA) to forward UE packets destined to the L-DN to the Local PSA. The packets destined to L-DN includes DNS Query messages destined to Local DNS Server.

Steps 2 and 3 are performed for option C:

2. If the UL CL/BP and Local PSA are inserted after PDU Session Establishment, the SMF sends PDU Session Modification Command (Local DNS Server Address) to UE.

If, based on operator’s policy or UE’s mobility, the Local DNS Server IP address in the local Data Network needs to be notified or updated to UE, the SMF sends PDU Session Modification Command (Local DNS Server Address) to UE.

3. The UE responds with PDU Session Modification Command Ack.

The UE configures the Local DNS Server as the DNS server for the PDU Session. The UE sends the following DNS Queries to the indicated Local DNS Server.

If EASDF was used as the DNS server for the PDU Session, the SMF may invoke Neasdf_DNSContext_Delete service to remove the DNS context in the EASDF.

NOTE 3: The UE does not need to know that the new DNS server is "local".

For the Split-UE in the option C case, the new address of Local DNS Server cannot be provided to the TE or the TE OS from the MT, Annex C documents mitigations for this scenario.

4. If required (see clause 5.2.1), the application in the UE uses the EDC functionality as described in clause 6.2.4 to send the DNS Query to the DNS Resolver/DNS Server indicated by the SMF in Step 0. UE sends a DNS Query message. In the case of IPv6 multi-homing the UE selects the source IP prefix based on the IPv6 multi-homed routing rule provided by SMF.

5. The DNS Query message is forwarded to the Local DNS Server and handled as described in following:

– For Option C, the target address of the DNS Query is the IP address of the Local DNS Server. The DNS Query is forwarded to the Local DNS Server by UL CL/BP and Local PSA. The Local DNS Server resolves the FQDN of the DNS Query by itself or communicates with other DNS server to recursively resolve the EAS IP address.

– For Option D: The Local PSA sends the DNS traffic to the Local DNS Server that resolves the FQDN target of the DNS Query by itself or that communicates with a C-DNS server to recursively resolve the EAS IP address.

NOTE 4: The Local PSA can send the DNS traffic to the Local DNS Server via tunnelling or via IP address replacement. If IP address replacement is used, the SMF sends the IP address of the Local DNS Server to the Local PSA and instructs the Local PSA to modify the packet’s destination IP address (corresponding to EASDF) to that of the Local DNS Server.

6. The Local PSA receives DNS Response message from Local DNS server, it forwards it to the UL CL/BP and the UL CL/BP forwards the DNS Response message to UE.

NOTE 5: If IP address replacement has been enforced at step 5, the Local PSA replaces the source IP address to EASDF IP according to SMF instruction.

If SMF decides to remove the UL CL/BP and Local PSA as defined in clause 4.3.5.5 of TS 23.502 [3], e.g. due to UE mobility, the SMF sends a PDU Session Modification Command to configure the new address of the DNS server on UE (e.g. to set it to the address of EASDF).

6.2.3.3 EAS Re-discovery Procedure at Edge Relocation

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 6.2.3.3-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.

Figure 6.2.3.3-1: EAS re-discovery procedure at Edge relocation

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).

1a. 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.

1b. 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 [3].

2. 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 4.3.3.2 TS 23.502 [3].

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 6.2.3.2.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 6.2.3.2.

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.

NOTE 1: In case of EAS IP Replacement (see 6.3.3.1) the support for EAS rediscovery indication procedure is not required.

NOTE 2: Depending on the UE implementation, the EAS rediscovery indication triggers an EAS Rediscovery procedure. If the EAS rediscovery indication is not sent to the UE Application Layer or to the UE OS, then the DNS Query to discover a new EAS is triggered only if the IP flows are terminated or via application/OS implementation means, e.g. based on application redirection, other application server information or DNS cache time-to-live. If DNS cache has not expired in the Application Layer or the OS, the triggered re-discovery can lead to the old EAS. For more information see Annex C.

NOTE 3: The active connection(s) between the UE and the EAS(s) are not impacted.

6.2.3.4 EAS Deployment Information Management

6.2.3.4.1 General

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 6.2.3.4-1.

Table 6.2.3.4-1 Description of EAS Deployment Information

Parameters	Description
DNN	DNN for the EAS Deployment Information. [optional]
S-NSSAI	S-NSSAI for the EAS Deployment Information. [optional]
External Group Identifier/Internal Group Identifier	Group ID for the EAS Deployment information. [optional] NOTE: 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.
Application ID	Identifies the application for which the EAS Deployment Information corresponds to. [optional]
FQDN(s)	Supported FQDN(s) for application(s) deployed in the Local part of the DN.
DNAI(s)	DNAI(s) for the EAS Deployment information. [optional]
DNS Server Information	list of DNS server identifier (consisting of IP address and port) for each DNAI. [optional]
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. [optional]

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.

6.2.3.4.2 EAS Deployment Information Provision from AF via NEF

The AF provides non-PDU Session specific EAS Deployment information to 5GC via the procedure defined in this clause.

Figure 6.2.3.4.2-1 EAS Deployment Information management in the AF procedure

1. The AF invokes the Nnef_EASDeployment_Create/Update/Delete service operation.

2. 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.

3. The NEF invokes the Nudr_DM_Create/Update/Delete to the UDR if it is authorized.

4. The UDR stores/updates/removes the corresponding information (and responds a Nudr_DM_Create/Update/Delete Response to the NEF.

5. The NEF sends Nnef_EASDeployment_Create/Update/Delete Response to the AF.

6.2.3.4.3 EAS Deployment Information Management in the SMF

The SMF may receive the EAS Deployment Information from NEF via Subscribe /Notify procedure defined in this clause. NEF may have stored the information in UDR.

Figure 6.2.3.4.3-1: EAS Deployment Information management in the SMF procedure

1-2. 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.

3-4. 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.

6.2.3.4.4 BaselineDNSPattern Management in the EASDF

The SMF receives EAS Deployment Information as described in clause 6.2.3.4.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.

Figure 6.2.3.4.4-1: BaselineDNSPattern management in the EASDF procedure

1. The SMF may triggered to create/update/delete the BaselineDNSPattern.

– When new EAS Deployment Information is received by the SMF.

– When any update of the EAS Deployment Information is received by the SMF.

The BaselineDNSPattern is deducted from the EAS Deployment Information. The BaselineDNSPattern has the form as per clause 6.2.3.2.2.

2. 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.

3. The EASDF updates the BaselineDNSPattern and acknowledges the SMF.

6.2.4 EDC Functionality based DNS Query to reach EASDF/DNS Resolver/DNS Server indicated by the SMF

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:

1) Send a DNS Query to the DNS Server (e.g., EASDF/DNS resolver) indicated by the SMF.

– The consumer in the UE provides to the EDC functionality the Domain Name to be resolved,

– The EDC functionality shall send the DNS Query to the DNS Server (e.g., EASDF/DNS resolver) indicated by the SMF,

– Once received, the EDC functionality shall forward the result of the DNS response (i.e., the IP address provided by the DNS resolver) to the consumer.

or:

2) 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.