Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.548  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   4.3   5…   6…   6.2.2.3…   6.2.3…   6.2.3.3…   6.3…   6.4…   6.5…   6.6   6.7…   6.8…   7…   A   B…   F…

 

6.2.3  EAS (Re-)discovery over Session Breakout Connectivity Modelp. 18

6.2.3.1  Generalp. 18

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 or based on the common EAS. 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 and in clause 5.6.7.1 of TS 23.501 and in clause 4.3.6.2 of TS 23.502.
Up

6.2.3.2  EAS Discovery Procedurep. 18

6.2.3.2.1  Generalp. 18
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).
Up
6.2.3.2.2  EAS Discovery Procedure with EASDFp. 18
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.
  • 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);
  • 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.
    • Forwarding Action: Send the DNS message(s) to a DNS server/resolver(s) as follows:
      1. 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.
      2. 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.
      3. Respond directly to the DNS request. In this case the EASDF is configured by the SMF not to forward the DNS Query to the DNS server, instead it creates a response based on EAS IP address provided by the SMF.
    • Control Action: Performs at least one of control actions on the DNS message(s) as follows:
      • Buffer the DNS message(s).
      • Build DNS response from DNS query with indicated IP address (e. g. common EAS). The EASDF is expected to handle the response it has built the same way as a response it has received from a remote DNS server.
      • 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; and/or
  • IP address or DNAI (e.g. common EAS, common DNAI) cached locally or retrieve from UDR via PCF.
  • 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 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.
    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 based on the Notification.
    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, or in the case a common DNAI is used for the set of UEs, the information is determined based on the common DNAI of the set of UEs. 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 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.
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.
Copy of original 3GPP image for 3GPP TS 23.548, Fig. 6.2.3.2.2-1: EAS discovery procedure with EASDF
Up
Step 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. 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.
Step 2.
During the PDU Session Establishment procedure, the SMF selects EASDF as described clause 6.3 of TS 23.501. 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.
Step 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.
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.
Step 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. 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.
Step 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.
Step 6.
The EASDF responds with Neasdf_DNSContext_Update Response.
Step 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.
Step 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.
Step 9.
The SMF responds with Neasdf_DNSContext_Notify Response.
Step 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 u
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.
Step 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.
Step 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 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.
Step 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.
Step 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.
Step 15.
The SMF invokes Neasdf_DNSContext_Notify Response service operation.
Step 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 of TS 23.501, and possibly Service Experience or DN performance analytics for an Edge Application as described in TS 23.288, the SMF may determine the DNAI. The SMF may also determine the associated N6 traffic routing information for the DNAI according to N6 traffic routing information for the DNAI included in EAS Deployment Information and configure Local PSA UPF with forwarding actions derived from the N6 traffic routing information. The SMF may perform UL CL/BP and Local PSA selection and insertion as described in TS 23.502. 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.
Step 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.
Step 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.
Step 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.
Up
6.2.3.2.3  EAS Discovery Procedure with Local DNS Server/Resolverp. 25
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.
Copy of original 3GPP image for 3GPP TS 23.548, Fig. 6.2.3.2.3-1: EAS discovery with Local DNS server/resolver
Up
Step 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. 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.
Step 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 or in a network initiated PDU Session Modification procedure. The UE configures the Local DNS Server as DNS server for that PDU Session.
The UL CL/BP and Local PSA are inserted or changed as described in TS 23.502. 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.
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:
Step 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.
Step 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.
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.
Step 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.
Step 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.
Step 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.
If SMF decides to remove the UL CL/BP and Local PSA as defined in clause 4.3.5.5 of TS 23.502, 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).
Up
6.2.3.2.4  Select common DNAI with Local DNS Server/Resolver for a set of UEs |R18|p. 27
The following procedure is for selecting common DNAI with Local DNS Server/Resolver for set of UEs.
Copy of original 3GPP image for 3GPP TS 23.548, Fig. 6.2.3.2.4-1: Discovery Procedure for selecting the common DNAI for a set of UEs with Local DNS Server/Resolver
Up
Step 1.
The UE sends a PDU Session establishment request to SMF as specified in step 0 of Figure 6.2.3.2.3-1.
Step 2.
The procedure in steps 1-4 of Figure 6.2.3.2.3-1 applies with following difference:
In step 1, the SMF determines UE belongs to a set of UEs accessing an EAS corresponds to a common DNAI based on traffic correlation indication and Traffic correlation ID in the PCC rule.
If the common DNAI is not available, the SMF notifies the NEF to determine the common DNAI as described in clause 6.2.3.2.7.
Once the common DNAI is available, SMF inserts or changes a Local PSA serving the common DNAI and selects local PSA and local DNS server corresponding to the common DNAI.
If the PDU session has been established and the PCC rule including updated common DNAI is provided to SMF, the SMF should reselect the local DNS server according to the common DNAI and configure the UE with new local DNS server in PCO using PDU session modification procedure.
Step 3.
The EAS information (e.g. EAS IP address) is resolved by Local DNS Server and sent the UE as described in steps 5-6 of Figure 6.2.3.2.3-1.
Up
6.2.3.2.5  Common EAS discovery for a set of UEs |R18|p. 28
The following is the procedure for common EAS discovery for a set of UEs accessing the same application. Different UEs can be served by different SMFs.
The common EAS IP address for the set of UEs may be provided by AF or determined by 5GC. AF may provide the common EAS IP via AF Traffic influence procedure as defined in clause 4.3.6.2 of TS 23.502, for this purpose AF may determine the common EAS IP address based on candidate DNAI(s) reported by SMF as described in clause 4.3.6.3 of TS 23.502. Alternatively, the common EAS IP address may be determined by NEF as defined in clause 6.2.3.2.7 and is stored in UDR as part of AF traffic influence request information.
Copy of original 3GPP image for 3GPP TS 23.548, Fig. 6.2.3.2.5-1: Common EAS discovery for a set of UEs
Up
Step 1.
The AF request in step 1 of Figure 4.3.6.2-1 in TS 23.502 is used to request selecting the common EAS for a set of UEs accessing the application as identified in the AF Request.
AF may use External/Internal Group ID(s) or a list of UEs or any UE as Target UE Identifier(s) and additionally Spatial Validity Condition to identify the set of UEs for correlated selection of common EAS.
The following information may be included in AF request as defined in clause 5.6.7.1 of TS 23.501:
  • An EAS Correlation indication may be provided for indication of selecting the same EAS for the set of UEs accessing the same application.
  • A Traffic Correlation ID may be provided for identification of the set of UEs accessing the application identified by the Traffic Description in AF request.
  • A Common EAS to be accessed by the set of UEs may be included in AF request, if it is determined by AF.
  • FQDN(s) may be included which is corresponding to the application traffic identified by Traffic Description in AF request.
  • Spatial Validity Condition could be provided for limiting the location of the UEs, and also "any UE" or a UE list or group ID can be provided for defining the set of UEs accessing the same EAS.
In step 3a of Figure 4.3.6.2-1 of TS 23.502, NEF updates the AF influence data related to the traffic correlation ID in the UDR with a Notification Endpoint to subscribe to be notified with information related to SMF's involvement for UE members of the set of UEs.
In step 5 of Figure 4.3.6.2-1 of TS 23.502, PCF determines the UEs influenced by the AF Request and for each UE, based on AF request, PCF creates PCC rule with Traffic Correlation ID, EAS Correlation indication, Common EAS, FQDN(s) and NEF subscription to SMF due to step 3a and sends the PCC rule to the SMF.
If an existing PDU Session is impacted by the above PCC rule for common EAS discovery and if the UE has indicated that it supports to refresh EAS information stored locally, the SMF shall send PDU Session Modification Command (EAS rediscovery indication, [impact field]) to UE to refresh the cached EAS information as described in step 2 of clause 6.2.3.3.
Step 2.
Based on steps 1-19 in Figure 6.2.3.2.2-1, with the following updates:
In step 9:
If FQDN in Neasdf_DNSContext_Notify Request is corresponding to the application indicated in PCC rule, e.g. the FQDN is included in the FQDN(s) in the PCC rule and if EAS Correlation indication is set, SMF determines the UE belongs to the set of UEs identified by Traffic Correlation ID and accessing the application and determines the UE connects to the common EAS for the set of UEs. If FQDN(s) is included in PCC rule, the SMF can use the FQDN(s) in PCC rule and the FQDN in Neasdf_DNSContext_Notify Request to match the FQDN with the PCC rule, i.e. the matched PCC rule includes the FQDN(s) containing the FQDN in Neasdf_DNSContext_Notify Request.
If the common EAS is not present in PCC rule or SMF decides to trigger the EAS discovery procedure to select a new EAS for the set of UEs:
Steps 10-15 are used for discovering of common EAS. After step 15, the procedure defined in clause 6.2.3.2.7 may be performed for common EAS IP coordination.
Else, if the common EAS is available and to be used for the set of UEs:
Steps 10-15 are skipped.
In step 16:
SMF may determine the DNAI based on the common EAS.
In step 17:
SMF sends DNS message handling rule including IP address for the common EAS and the Forwarding Action "Respond directly to the DNS request" for instructing EASDF to return the Common EAS IP address in a DNS response to UE directly.
In step 19:
If received IP address of the common EAS and instructed to respond directly in step 17, EASDF sends DNS response with the IP address of the common EAS to UE.
Up
6.2.3.2.6  EAS discovery corresponding to Common DNAI for a set of UEs |R18|p. 30
The common DNAI for the set of UEs can be provided either by AF or determined by 5GC. When the AF determines the common DNAI, the AF provides the common DNAI for the set of UEs via AF Traffic influence procedure as defined in clause 4.3.6.2 of TS 23.502 The AF may determine the common DNAI based on candidate DNAI(s) reported by SMF as described in clause 4.3.6.3 of TS 23.502.
When the 5GC determines the common DNAI, the common DNAI is determined by NEF and the NEF stores the common DNAI in UDR as part of AF traffic influence request information, as described in clause 6.2.3.2.7.
The following is the procedure for discovery EAS corresponding to a Common DNAI for set of UEs accessing the same application.
Copy of original 3GPP image for 3GPP TS 23.548, Fig. 6.2.3.2.6-1: EAS discovery corresponding to Common DNAI for a set of UEs
Up
Step 1.
The AF request in step 1 of Figure 4.3.6.2-1 in TS 23.502 is used to request selecting the common DNAI for a set of UEs accessing the application as identified in the AF Request.
AF may use External/Internal Group ID(s) or a list of UEs or any UE as Target UE Identifier(s) and additionally Spatial Validity Condition to identify the set of UEs for correlated selection of common DNAI.
The following information may be included in AF request as defined in clause 5.6.7.1 in TS 23.501:
  • An indication of traffic correlation may be provided for indication of selecting the same DNAI (i.e. selecting EAS corresponding to the same DNAI) for the set of UEs accessing the same application.
  • A Traffic Correlation ID may be provided for identification of the set of UEs accessing the application identified by the Traffic Description in AF request.
  • A Common DNAI to be accessed by the set of UEs can be included in AF request, if it is determined by AF.
  • FQDN(s) may be included which is corresponding to the application identified by Traffic Description in AF request.
  • Spatial Validity Condition could be provided for limiting the location of the UEs, and also "any UE" or a UE list or group ID can be provided for defining set of UEs accessing the same DNAI.
In step 3a of Figure 4.3.6.2-1 of TS 23.502, NEF updates the AF influence data related to the traffic correlation ID in the UDR with a Notification Endpoint to subscribe to be notified with information related to SMF's involvement for UE members of the set of UEs.
In step 5 of Figure 4.3.6.2-1 of TS 23.502, PCF determines the UEs influenced by the AF Request, and for each UE, based on AF request, PCF creates PCC rule with Traffic Correlation ID and indication of traffic correlation, Common DNAI, FQDN(s) and Notification endpoint of NEF subscription received to step 3a and sends the PCC rule to the SMF.
If an existing PDU Session is impacted by the above PCC rule for EAS discovery corresponding to Common DNAI and if the UE has indicated that it supports to refresh EAS information stored locally, the SMF shall send PDU Session Modification Command (EAS rediscovery indication, [impact field]) to UE to refresh the cached EAS information as described in step 2 of clause 6.2.3.3.
Step 2.
Based on steps 1~19 in Figure 6.2.3.2.2-1, with the following changes:
In step 10:
If FQDN in Neasdf_DNSContext_Notify Request is corresponding to the application indicated in PCC rule, e.g. the FQDN is included in the FQDN(s) in the PCC rule and if indication of traffic correlation is set, SMF determines the UE belongs to set of UEs identified by Traffic Correlation ID and accessing the application and determines the UE connects to EAS corresponding to the common DNAI for the set of UEs. If FQDN(s) is included in PCC rule, the SMF can use the FQDN(s) in PCC rule and the FQDN in Neasdf_DNSContext_Notify Request to match the FQDN with the PCC rule, i.e. the matched PCC rule includes the FQDN(s) containing the FQDN.
If the common DNAI is not available in the PCC Rule received in step 1, the SMF invokes the NEF to determine the common DNAI as described in clause 6.2.3.2.7.
Once the common DNAI is available, for Option A, SMF provisions EASDF with the information to build EDNS Client Subnet option that refers to a location that is topologically close to the common DNAI; for Option B, SMF provisions EASDF with Local DNS server related to the common DNAI.
Up
6.2.3.2.7  Coordination among SMFs for Common EAS/DNAI determination |R18|p. 31
Copy of original 3GPP image for 3GPP TS 23.548, Fig. 6.2.3.2.7-1: Handling of Common EAS, Common/DNAI for set of UEs
Up
Step 1.
SMF sends Nsmf_TrafficCorrelation_Notify to the NEF with Notification Endpoint received in the PCC rule as described in clauses 6.2.3.2.5 and 6.2.3.2.6 and provides: EAS IP address based on EASDF procedure, list of candidate DNAI(s), SMF ID, number of PDU sessions it is serving for the set of UEs, Traffic Correlation ID.
Step 2.
If the NEF determines that there is currently no common EAS IP address and/or common DNAI available for the set of UEs identified by Traffic Correlation ID, it selects a common DNAI and/or common EAS using the list of DNAI(s), EAS IP address and number of PDU sessions each SMF is serving for the set of UEs received in step 1. Then the NEF updates traffic influence data with the 5GC determined common EAS/DNAI for the set of UEs.
The update of traffic influence data triggers notifications to PCF(s) that in turn trigger associated PCC rule updates to the SMF(s), if any, with PDU Session(s) associated with the traffic correlation ID.
The NEF maintains a list of SMFs serving the set of UEs and the associated data including common DNAI, common EAS, number of PDU sessions each SMF is serving for the set of UEs, Traffic Correlation ID.
Step 3.
NEF responds by acknowledging the notification to the SMF.
Step 4.
The update in UDR triggers notification to the PCF(s) that have subscribed for notification. The PCF(s) sends PCC rule(s) with NEF information, Traffic correlation ID and common EAS IP address and/or Common DNAI, as part of traffic influence data to the SMF(s) with PDU Session(s) associated with the Traffic Correlation ID.
SMF(s) may select other candidate DNAI(s) for the PDU session(s) or a candidate new EAS IP address via the EASDF procedure e.g. due to UE(s) mobility. In this case, the SMF notifies to the NEF as in the above step 1, with the list of candidate DNAI(s) and/or EAS IP address. This may trigger NEF to re-select common DNAI or common EAS. NEF determines common EAS and/or common DNAI based on received EAS IP, list of candidate DNAI(s), number of PDU sessions SMF(s) serving for the set of UEs.
If another DNAI/EAS IP address is selected by the NEF, it updates the common DNAI or common EAS in the UDR in the Traffic Influence data.
Up

Up   Top   ToC