5 Services offered by the EASDF

29.5563GPPEdge Application Server Discovery ServicesRelease 17Stage 3TS

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

5.1 Introduction

The EASDF offers to other NFs the following service:

Table 5.1-1: NF Service provided by EASDF

Service Name	Description	Example Consumer
Neasdf_DNSContext	This service enables the consumer to create, update and delete DNS context in EASDF, or subscribe to DNS message reporting from EASDF.	SMF
Neasdf_BaselineDNSPattern	This service enables the consumer to create, update and delete Baseline DNS pattern in EASDF.	SMF

The Neasdf_DNSContext service and Neasdf_BaselineDNSPattern service are specified in 3GPP TS 23.548 [14].

Table 5.1-2 summarizes the corresponding APIs defined for this specification.

Table 5.1-2: API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
Neasdf_DNSContext	6.1	EASDF DNSContext Service	TS29556_Neasdf_DNSContext.yaml	neasdf-dnscontext	A.2
Neasdf_BaselineDNSPattern	6.2	EASDF BaselineDNSPattern Service	TS29556_Neasdf_BaselineDNSPattern.yaml	neasdf-baselinednspattern	A.3

5.2 Neasdf_DNSContext Service

5.2.1 Service Description

The Neasdf_DNSContext service operates on the DNS contexts. The EASDF is acting as NF Service Producer, while the SMF is the NF Service Consumer.

Following functionalities are provided by the Neasdf_DNSContext service:

– Create a DNS context in EASDF;

– Update a DNS context in EASDF;

– Delete a DNS context in EASDF;

– Enable the EASDF to report DNS signalling related information to the NF service consumer when receiving DNS Query or DNS Response.

The Neasdf_DNSContext service supports the following service operations.

Table 5.2.1-1: Service operations supported by the Neasdf_DNSContext service

Service Operations	Description	Operation Semantics	Example Consumer(s)
Create	Create a DNS context in EASDF.	Request/Response	SMF
Update	Update a DNS context in EASDF.	Request/Response	SMF
Delete	Delete a DNS context in EASDF.	Request/Response	SMF
Notify	EASDF reports DNS signalling related information to the NF service consumer when receiving DNS Query or DNS Response.	Subscribe/Notify	SMF

5.2.2 Service Operations

5.2.2.1 Introduction

See Table 5.2.1-1 for an overview of the service operations supported by the Neasdf_DNSContext service.

5.2.2.2 Create

5.2.2.2.1 General

The Create service operation shall be used to create an individual DNS context for a given PDU Session in the EASDF.

It is used in the following procedures:

– EAS Discovery Procedure with EASDF (see clause 6.2.3.2.2 of 3GPP TS 23.548 [14]).

There shall be only one individual DNS context created in an EASDF per PDU session.

The NF Service Consumer (e.g. SMF) shall create a DNS context by using the HTTP POST method as shown in Figure 5.2.2.2.1-1.

Figure 5.2.2.2.1-1: DNS context creation

1. The NF Service Consumer shall send a POST request to the resource representing the DNS contexts collection resource of the EASDF. The payload body of the POST request shall contain:

– the UE IP address, S-NSSAI and the DNN of the related PDU session;

– a notification URI for receiving DNS context related event notifications, if notifications are requested;

– one or more DNS rules.

2a. On success, a "201 Created" response shall be returned with the "Location" header containing the URI of the created resource.

The POST response body shall include:

– the IP address of the EASDF (to be sent by the SMF to the UE).

2b. On failure, or redirection, one of the HTTP status code listed in Table 6.1.3.2.3.1-3 shall be returned.

5.2.2.3 Update

5.2.2.3.1 General

The Update service operation shall be used to update an individual DNS context previously created in the EASDF. The update operation may apply to the whole DNS context (complete replacement of the data of the existing DNS context by new data), or it may apply to modify a subset of the parameters of the DNS context.

It is used in the following procedures:

– EAS Discovery Procedure with EASDF (see clause 6.2.3.2.2 of 3GPP TS 23.548 [14]).

To perform a partial update of the DNS context of a given DNS context Id, the NF Service Consumer shall issue an HTTP PATCH request, as shown in Figure 5.2.2.3.1-1. This partial update shall be used to add, delete and/or replace individual parameters of the DNS context.

Figure 5.2.2.3.1-1: DNS context Partial Update

1. The NF Service Consumer (e.g. SMF) shall send a PATCH request to the resource URI representing the individual DNS context, identified by the {dnsContextId}. The payload body of the PATCH request shall contain the list of operations (add/delete/replace) to be applied to parameters in the individual DNS context.

2a. On success, if all the modification instructions in the PATCH request have been implemented, "204 No Content" shall be returned.

2b. If some of the modification instructions for unknown attribute(s) in the PATCH request have been ignored, the EASDF shall respond with "200 OK" with the response body containing PatchResult, as specified in clause 5.2.7.2 of 3GPP TS 29.500 [4].

2c. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.2-3 shall be returned.

To perform a complete replacement of the data of the DNS context of a given DNS context Id, the NF Service Consumer shall issue an HTTP PUT request, as shown in Figure 5.2.2.3.1-2:

Figure 5.2.2.3.1-2: DNS context Complete Replacement

1. The NF service consumer (e.g. SMF) shall send a PUT request to the resource URI representing the individual DNS context, identified by the {dnsContextId}. The payload body of the PUT request shall contain a representation of the individual DNS context to be completely replaced in the EASDF.

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.3-3 shall be returned.

5.2.2.4 Delete

5.2.2.4.1 General

The Delete Service operation shall be used by the NF service consumer (e.g. SMF) to delete the individual DNS context in the EASDF.

Figure 5.2.2.4.1-1: DNS context deletion

1. The NF Service Consumer (e.g. SMF) shall send a DELETE request to delete the individual DNS context represented by the {dnsContextId}. The request body shall be empty.

2a. On success, "204 No Content" shall be returned. The response body shall be empty.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.1-3 shall be returned.

5.2.2.5 Notify

5.2.2.5.1 General

The Notify service operation shall be used to notify the NF Service Consumer (e.g. SMF) about a DNS context related event, e.g. if a received DNS Query message or DNS response message matches a DNS detection template of an DNS rule and the associated action requires to report the message to the NF service producer.

It is used in the following procedures:

– EAS Discovery Procedure with EASDF (see clause 6.2.3.2.2 of 3GPP TS 23.548 [14]).

The EASDF shall send an HTTP POST request targeting the DNS context notification URI provided by the NF Service Consumer in the Create or Update service operation (see clause 5.2.2.2.1). See also Figure 5.2.2.5.1-1.

Figure 5.2.2.5.1-1: DNS Context Notify

1. The EASDF shall send a HTTP POST request to the DNS context notification URI, and the payload body of the POST request shall contain a DnsContextNotification data structure, with the DNS message report that was subscribed by the NF Service Consumer.

2a. On success, "204 No Content" shall be returned and the payload body of the POST response shall be empty.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.5.2.3.1-3 shall be returned.

5.2.3 DNS messages processing by EASDF

5.2.3.1 Introduction

This clause specifies how the EASDF shall process DNS messages according to the instructions received from the SMF.

5.2.3.2 DNS message processing model

5.2.3.2.1 DNS Context

The SMF shall control how the EASDF processes DNS messages received for a particular UE’s PDU session by creating one single DNS context per PDU session including the following information:

– the UE IP address, S-NSSAI and DNN of the PDU session; and

– one or more DNS rules.

There shall be at most one DNS context created in the EASDF with the same UE IP address, S-NSSAI and DNN. If the EASDF receives a request to create a DNS context for which another DNS context already exists with the same UE IP address, S-NSSAI and DNN, the EASDF shall proceed with creating the DNS context and shall delete the earlier existing DNS context with the same UE IP address, S-NSSAI and DNN.

5.2.3.2.2 DNS Rule

A DNS rule shall apply either to DNS Query messages or DNS Response messages. A DNS rule shall contain:

– the DNS Rule ID uniquely identifying the DNS rule within the DNS context, for a DNS rule other than a One-Time DNS rule;

– precedence information, indicating the order in which the EASDF shall attempt to match DNS messages against all the DNS rules provisioned in the DNS context, for a DNS rule other than a One-Time DNS rule;

– for a DNS rule provisioned for DNS Query messages:

– for a DNS rule other than a One-Time DNS rule:

– at least one DNS Query Message Detection Template (MDT) or Baseline DNS Query Message Detection Template (BD MDT) ID referring to a BD MDT provisioned in a baseline DNS pattern; such a DNS rule may contain one or more DNS Query MDTs and/or BD MDT IDs referring to BD MDTs provisioned in one or more baseline DNS patterns; or

– for a One-Time DNS rule:

– the DNS message identifier uniquely identifying the DNS message buffered in the EASDF;

– for a DNS rule provisioned for DNS Response messages:

– for a DNS rule other than a One-Time DNS rule:

– at least one DNS Response MDT or Baseline DNS Response MDT ID referring to a BD MDT provisioned in a baseline DNS pattern; a DNS rule may contain one or more DNS Response MDTs and/or BD MDT IDs referring to BD MDTs provisioned in one or more baseline DNS patterns;

– for a One-Time DNS rule:

– the DNS message identifier uniquely identifying the DNS message buffered in the EASDF;

– a list of actions to apply to all DNS messages matching at least one DNS MDT of the DNS rule or one BD MDT referred by the DNS rule.

See clauses 5.2.3.5 and 5.2.3.2.4 for the description of baseline DNS patterns and One-Time DNS rules respectively.

Figure 5.2.3.2-1 provides an overview of DNS contexts, DNS rules (other than One-Time DNS rules) and baseline DNS patterns, depicting one DNS context created with N DNS rules, some of them referring to baseline DNS patterns.

Figure 5.2.3.2-1: Overview of DNS contexts, DNS rules and Baseline DNS Patterns

5.2.3.2.3 Processing flow for incoming DNS messages

Upon receipt of a DNS message, the EASDF shall first identify the DNS context corresponding to the DNS message as follows:

– for DNS Query message: by using the source IP address of the DNS Query message and by matching it with the UE IP address provisioned in the DNS Query MDTs if any or with the UE IP address provisioned in the DNS context; and

– for a DNS Response message: by matching the DNS response with the DNS Query (either by the EASDF assigning a specific Transaction ID when forwarding the DNS Query message and by matching the Transaction ID in the DNS Query and DNS Response, or by the EASDF using a unique couple of source IP address and UDP port per DNS context when forwarding the DNS Query message and by matching the DNS Response message using the destination IP address and UDP port) and by retrieving the DNS context that is associated with the DNS query.

NOTE 1: The EASDF has direct user plane connectivity (i.e., without any NAT) with the PSA UPF over N6 for the transmission of DNS signalling exchanged with the UE. The deployment of a NAT between EASDF and PSA UPF is not supported.

If there is no DNS context matching a DNS Query or Response message, the EASDF should forward the DNS Query message towards a preconfigured DNS server and the DNS response towards the UE.

After finding the DNS context, the EASDF shall look up for a DNS rule matching the DNS message, among all DNS rules provisioned in the DNS Context, starting with the DNS rules with the highest precedence and continuing then with DNS rules with a lower precedence, in decreasing order of precedence. If there is no DNS rule matching the DNS message, the EASDF should forward the DNS Query message towards a preconfigured DNS server/resolver for resolution.

NOTE 2: The SMF can provision in the DNS context a DNS rule with the lowest precedence and with a DNS Query MDT or a DNS Response MDT containing a wildcard FQDN, such as to associate a default behavior to all DNS messages not matching any other DNS rule, e.g. forward DNS Query messages to a specific DNS Server.

After having found a matching DNS rule, the EASDF shall stop looking up for other DNS rules and shall apply the list of actions provisioned in the matching DNS rule.

A DNS message matches a DNS rule if it matches at least one MDT of the DNS Rule or one BD MDT referred by the DNS rule.

The DNS message processing models for DNS Query and DNS Response are depicted in Figure 5.2.3.2-2 and 5.2.3.2-3 respectively.

Figure 5.2.3.2-2: DNS Query processing flow in the EASDF

Figure 5.2.3.2-3: DNS Response processing flow in the EASDF

5.2.3.2.4 Processing of a One-Time DNS Rule applicable to a specific DNS message earlier buffered in the EASDF

The SMF may instruct the EASDF to apply certain actions (e.g. forward or drop a DNS message) to a specific DNS message, that has been earlier buffered in the EASDF and reported to the SMF, by creating a new DNS rule in the DNS context that includes:

– the DNS message identifier uniquely identifying the DNS message within the DNS context, as reported earlier by the EASDF in the DNSContext Notify request; and

– the requested actions to apply to the DNS message.

Such a DNS rule shall not contain any DNS Rule ID, precedence, MBT nor BD MDT.

Upon receipt of an DNSContext Update request that creates such a DNS rule, the EASDF shall apply the requested actions to the specific DNS message identified by the DNS message identifier and then delete the DNS Rule. If there is no buffered DNS message corresponding to the DNS message identifier received in the DNS rule, the EASDF shall reject the request with an error.

NOTE: A DNS rule that includes a DNS message identifier is referred as a "One-Time" DNS rule throughout this specification since the DNS rule is applied only once for the indicated DNS message and the DNS rule is not further stored by the EASDF.

5.2.3.3 DNS Message Detection Template

5.2.3.3.1 General

The contents of a DNS Query MDT or a DNS Response MDT may be provisioned directly in a DNS rule itself or in a BD MDT provisioned in a baseline DNS pattern. In the latter case, a DNS rule may refer to one or more BD MDTs (that are all either DNS Query MDTs or DNS Response MDTs) of one or more baseline DNS patterns by referencing the BD MDT IDs of the BD MDTs of the baseline DNS patterns.

The following clauses define the contents of DNS Query MDTs and DNS Response MDTs, provisioned in a DNS rule or in a BD MDT.

5.2.3.3.2 DNS Query MDT

A DNS Query Message Detection Template may include:

– a UE IP address;

– a list of FQDN ranges or a wildcard FQDN representing "any FQDN" (see clauses 6.1.6.2.5 and 6.1.6.2.6).

A UE IP address may only be provisioned in a DNS Query MDT, i.e. it cannot be provisioned in a Baseline DNS MDT. However, a DNS rule may be provisioned with a reference to one or more Baseline DNS Query MDTs together with a UE IP address (see clause 6.1.6.2.20), in which case the referenced Baseline DNS Query MDTs shall be matched for the specific UE IP address.

When present in a DNS Query MDT, or together with the reference to a Baseline DNS Query MDT, the UE IP address shall be used for matching the DNS Query message with the related DNS rule (see clause 5.2.3.2). Otherwise, the UE IP address provisioned in the DNS context shall be used.

FQDNs shall be matched against the Query Domain Name of DNS Query messages.

5.2.3.3.3 DNS Response MDT

A DNS Response Message Detection Template may include:

– a list of FQDN ranges or a wildcard FQDN representing "any FQDN"; and/or

– a list of EAS IP addresses ranges.

FQDNs shall be matched against the Domain Names in the Answers of DNS Response messages.

EAS IP addresses ranges shall be matched against the IP addresses returned in the Answers of DNS Response messages.

5.2.3.4 Actions applicable to DNS message

5.2.3.4.1 General

Each DNS rule shall be provisioned with the list of actions to apply to all DNS messages matching the DNS rule.

The SMF may request the EASDF to apply one or more of the following actions:

1) REPORT DNS message content to the SMF.

The SMF may further request the EASDF to send a report only once to the SMF, i.e. only when a first DNS message matches any MDT of the DNS rule. If so, the EASDF shall skip this action (i.e. report to SMF) for any subsequent DNS message matching the DNS rule.

The SMF may further request the EASDF to reset the reporting-once indication, in which case the EASDF shall send (only) one more report at the next DNS message that matches the DNS rule.

2) BUFFER DNS message.

3) FORWARD DNS message.

The SMF may further request the EASDF to set the destination IP address of the DNS Query message to a specific DNS Server address. The DNS Server address may either be included in the DNS rule or in a Baseline DNS Action Information Template (BD AIT); in the latter case, the DNS rule shall refer to the corresponding BD AIT ID. If no DNS Server address is provided by the SMF, the EASDF shall forward the DNS message to a locally pre-configured DNS server/resolver.

The SMF may request the EASDF to build an EDNS Client Subnet (ECS) option to be included in the DNS Query message as defined in IETF RFC 7871 [18], or to be used for replacing the ECS option if an ECS option is received in the DNS Query message from the UE. The information for the EASDF to build the ECS option may either be included in the DNS rule or in a Baseline DNS Action Information Template (BD AIT); in the latter case, the DNS rule shall refer to the corresponding BD AIT ID.

When forwarding a DNS Query message, if the SMF did not request the EASDF to build an ECS option, the EASDF shall remove the ECS option received from the UE in the DNS Query, if any.

When forwarding a DNS Response message to the UE, based on configuration, the EASDF shall either remove any received ECS option or, if an ECS option was received in the DNS Query from the UE, replace it with the latter ECS option.

4) DISCARD DNS message.

The SMF may change the list of actions associated to a DNS rule (other than a One-Time DNS rule), e.g. to replace the actions to REPORT and BUFFER DNS Query messages to the SMF by the action to FORWARD the DNS messages. In such a case, any earlier buffered DNS message (matching the DNS rule) and any further incoming DNS message shall be processed according to the new instructions received from the SMF, e.g. they shall all be forwarded. The SMF may alternatively request the EASDF to apply certain actions to a specific DNS message by creating a One-Time DNS rule as defined in clause 5.2.3.2.4.

5.2.3.4.2 Event reporting by EASDF

The EASDF shall send a report to the SMF:

– to report the contents of DNS (Query or Response) messages matching a DNS rule provisioned with the action to report the DNS message contents.

The EASDF shall send reports to the SMF as defined in clause 5.2.2.5. The notification request sent to the SMF may contain one or more reports, for DNS Query and/or DNS Response messages matching one or more DNS rules provisioned in the DNS context. For each report, the EASDF may provide a DNS message identifier uniquely identifying the DNS message reported to the SMF within the DNS context (see clause 5.2.3.2.4).

5.2.3.5 Baseline DNS Patterns

5.2.3.5.1 General

The SMF may create, modify or delete baseline DNS patterns in the EASDF using the Neasdf_BaselineDnsPattern service (see clause 5.3).

A baseline DNS pattern contains baseline DNS information that may apply to multiple PDU sessions, e.g. to all PDU sessions with a certain DNN and S-NSSAI.

A baseline DNS pattern may contain:

– one or several BD MDTs; and/or

– one or several BD AITs.

A baseline DNS pattern may contain BD MDTs for DNS Query messages and BD MDTs for DNS Response messages. One BD MDT shall be either a DNS Query MDT or a DNS Response MDT (see clause 5.2.3.3).

A BD AIT may include:

– one or more local DNS Server IP address(es); and/or

– ECS option information.

NOTE 1: Multiple DNS Server IP addresses can be provided for resiliency.

A BD MDT and a BD AIT shall be uniquely identified in the EASDF by the combination of the following information:

– the URI of the baseline DNS pattern in which the BD MDT or BD AIT is defined; the URI shall be chosen by the SMF when creating the baseline DNS pattern (see clause 6.2.3); and

– an MDT or AIT identifier (string) uniquely identifying the MDT or AIT within the baseline DNS pattern; this identifier shall be chosen by the SMF when creating the BD MDT or BD AIT.

The URI of a baseline DNS pattern shall be unique per SMF set, if an SMF set controls the EASDF, or unique per SMF otherwise.

NOTE 2: The URI of a baseline DNS pattern includes an identifier of the SMF or SMF set (see clause 6.2.3.1) and SMF implementation specific information. This ensures the uniqueness of the URI in the EASDF when several SMFs or SMF sets control the same EASDF. As an example, an SMF can encode the URI of the baseline DNS pattern and the MDT or AIT identifier to include the DNAI or a sequence number. The EASDF is not meant to understand the structure of this information.

When a BD MDT or BD AIT of a baseline DNS pattern is modified by the SMF, the modified BD MDT or BD AIT shall apply to all DNS rules of all DNS contexts referring to that BD MDT or BD AIT.

5.3 Neasdf_BaselineDNSPattern Service

5.3.1 Service Description

The Neasdf_BaselineDNSPattern service operates on the Baseline DNS patterns in EASDF, which contains the DNS base information that may apply to multiple PDU sessions, e.g. DNS Query and Response MDTs applicable to all PDU sessions with a certain DNN and S-NSSAI. The EASDF is acting as NF Service Producer, while the SMF is the NF Service Consumer.

Following functionalities are provided by the Neasdf_BaselineDNSPattern service:

– Create a Baseline DNS Pattern in EASDF;

– Update the Baseline DNS Pattern in EASDF;

– Delete the Baseline DNS Pattern in EASDF.

The Neasdf_BaselineDNSPattern service supports the following service operations.

Table 5.3.1-1: Service operations supported by the Neasdf_BaselineDNSPattern service

Service Operations	Description	Operation Semantics	Example Consumer(s)
Create	Create a Baseline DNS Pattern in EASDF.	Request/Response	SMF
Update	Update the Baseline DNS Pattern in EASDF.	Request/Response	SMF
Delete	Delete the Baseline DNS Pattern in EASDF.	Request/Response	SMF

5.3.2 Service Operations

5.3.2.1 Introduction

See Table 5.3.1-1 for an overview of the service operations supported by the Neasdf_BaselineDNSPattern service.

5.3.2.2 Create

5.3.2.2.1 General

The Create service operation shall be used to create the Baseline DNS Pattern in the EASDF.

It is used in the following procedures:

– BaselineDNSPattern management in the EASDF procedure (see clause 6.2.3.4.4 of 3GPP TS 23.548 [14]).

The NF Service Consumer (e.g. SMF) shall create the Baseline DNS Pattern by using the HTTP PUT method as shown in Figure 5.3.2.2.1-1.

Figure 5.3.2.2.1-1: Baseline DNS Pattern creation

1. The NF Service Consumer shall send a PUT request to create the Baseline DNS Pattern in the EASDF. The payload body of the PUT request may contain:

– one or more Baseline DNS message detection templates (MDTs);

– one or more Baseline DNS action information templates (AITs).

2a. On success, a "201 Created" response shall be returned with the "Location" header containing the URI of the created resource.

2b. On failure, or redirection, one of the HTTP status code listed in Table 6.2.3.2.3.2-3 shall be returned.

5.3.2.3 Update

5.3.2.3.1 General

The Update service operation shall be used to update an individual Baseline DNS Pattern previously created in the EASDF. The update operation may apply to the whole Baseline DNS Pattern (complete replacement of the data of the existing Baseline DNS Pattern by new data), or it may apply to modify a subset of the parameters of the Baseline DNS Pattern.

It is used in the following procedures:

– BaselineDNSPattern management in the EASDF procedure (see clause 6.2.3.4.4 of 3GPP TS 23.548 [14]).

To perform a partial update of the Baseline DNS Pattern, the NF Service Consumer shall issue an HTTP PATCH request, as shown in Figure 5.3.2.3.1-1. This partial update shall be used to add, delete and/or replace individual parameters of the Baseline DNS Pattern.

Figure 5.3.2.3.1-1: Baseline DNS Pattern Partial Update

1. The NF Service Consumer (e.g. SMF) shall send a PATCH request to the resource URI representing the individual Baseline DNS Pattern. The payload body of the PATCH request shall contain the list of operations (add/delete/replace) to be applied to parameters in the individual Baseline DNS Pattern.

2a. On success, if all the modification instructions in the PATCH request have been implemented, "204 No Content" shall be returned.

2c. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.2.3.1-3 shall be returned.

To perform a complete replacement of the data of the Baseline DNS Pattern, the NF Service Consumer shall issue an HTTP PUT request, as shown in Figure 5.3.2.3.1-2:

Figure 5.3.2.3.1-2: Baseline DNS Pattern Complete Replacement

1. The NF service consumer (e.g. SMF) shall send a PUT request to the resource URI representing the individual Baseline DNS Pattern. The payload body of the PUT request shall contain a representation of the individual Baseline DNS Pattern to be completely replaced in the EASDF.

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.2.3.2-3 shall be returned.

5.3.2.4 Delete

5.3.2.4.1 General

The Delete service operation shall be used to delete an individual Baseline DNS Pattern previously created in the EASDF.

It is used in the following procedures:

– BaselineDNSPattern management in the EASDF procedure (see clause 6.2.3.4.4 of 3GPP TS 23.548 [14]).

To perform a deletion of the Baseline DNS Pattern, the NF Service Consumer shall issue an HTTP DELETE request, as shown in Figure 5.3.2.4.1-1.

Figure 5.3.2.4.1-1: Baseline DNS Pattern Deletion

1. The NF Service Consumer (e.g. SMF) shall send a DELETE request to delete the individual Baseline DNS Pattern. The request body shall be empty.

2a. On success, "204 No Content" shall be returned. The response body shall be empty.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.2.3.3-3 shall be returned.