Content for TS 23.548 Word version: 18.4.0
B Application Layer based EAS (Re-)Direction
C Considerations for EAS (re)Discovery
C.1 General
C.2 Impact of IP Addresses for DNS Resolver on UE
C.3 UE Considerations for EAS Re-discovery
C.4 UE Procedures for Session Breakout
C.5 Split-UE Considerations for EAS (Re-)discovery
C.6 Detection of UE not using 5GC provided DNS server
D Examples of AF Guidance to PCF for Determination of URSP Rules
E EPS Interworking Considerations
E.1 General
E.2 Distributed Anchor
E.3 Multiple Sessions
E.4 Session Breakout
B Application Layer based EAS (Re-)Direction p. 77
During the application relocation, the AF can reselect a new EAS for the UE. Reselection can be triggered by the AF when it receives a UP path change notification or by an internal trigger of the AF (e.g. load balancing, UE location change, etc.). When the new EAS is reselected, the UE is provided the new EAS address via application layer signalling. For example, the UE can receive the URL or FQDN of the new EAS once the application context relocation is complete and then use DNS to resolve the URL or FQDN. The UE can also obtain the new EAS address via HTTP redirection.
C Considerations for EAS (re)Discovery p. 78
C.1 General p. 78
DNS records obtained from a DNS resolver in the network contains a time-to-live (TTL) value. This is a hint provided by the DNS resolver and can be used to determine the length of time that the record is to be cached. DNS records can be cached in the UE system wide (in OS) and/or applications. The application cache is managed on a per application basis while the system cache is common to applications. Name resolution caches in various applications also have different policies and behaviours. Some applications cache the DNS records for the length of the application session while others have a time limit. The recommendations in this TS will only work if the UE application (in case of DNS cache at the application layer) or the UE OS (in case of DNS cache shared by applications) consider indications from the UE modem layer with respect to DNS settings and DNS caching. Whether and how the UE (and application) considers the indication depends on implementation.
C.2 Impact of IP Addresses for DNS Resolver on UE p. 78
The UE can be configured by the 5GC with an IP address for the DNS resolver using ePCO or IPv6 Router Advertisement (RA), DHCPv4 or DHCPv6 as described in clause 5.8.2 of TS 23.501. 5GC can reconfigure the DNS resolver IP address using NAS or IPv6 Router Advertisement (RA). In case of anycast IP address is used for the DNS resolver, the 5GC can use UL CL/BP to branch out the DNS messages and the DN is responsible to route them to the closest instance of the MNO DNS resolver without having to reconfigure the DNS resolver IP address in the UE.
A network interface change, or NAS SM EAS rediscovery indication (explicitly as described in clause 6.2.3.3) or reconfiguration of DNS server address in NAS SM message that implicitly indicating EAS rediscovery as described in clause 6.2.3.2.3 can and should result in the UE OS/application clearing name/IP address translations in its DNS cache.
If a network interface change or NAS SM EAS rediscovery explicit indication or reconfiguration of DNS server address using NAS SM (i.e. implicit EAS rediscovery indication) does not result in the UE OS/application clearing name to IP address translations in its DNS cache, a subsequent DNS EAS address resolution request can result to address of old EAS.
During EPC to 5GC mobility without N26 interface, the UE can receive a new DNS server address different from the one received from the SMF+PGW-C during the PDN connection initiated in EPC. This can result in the UE OS clearing name/IP address translations in its DNS cache. During 5GC to EPC mobility without N26 interface, the UE can perform the same if it receives a new DNS server address from the SMF+PGW-C.
C.3 UE Considerations for EAS Re-discovery p. 78
A UE that complies with EAS (re-)discovery described in this specification is not recommended to override operator-provided DNS settings. This is necessary for the "closest" EAS server to be selected. Overriding the operator-provided DNS settings means that procedures requiring operator provided DNS server will not work.
C.4 UE Procedures for Session Breakout p. 79
In the session breakout connectivity model, the selection of a new session breakout path does not result in a new network interface indication at the UE.
Session breakout results in a NAS SM message indicating the need to redo DNS lookup sent by the SMF to the UE modem. Thus, in order to support some solutions of this specification, it is necessary for the operating system to receive information of EAS rediscovery from the modem when such signalling has been received and clear the DNS cache in UE OS.
C.5 Split-UE Considerations for EAS (Re-)discovery p. 79
For the split-UE (i.e. the TE and MT are separated), information provided by the SMF in the NAS message during the PDU Session Establishment, Modification and Command is provided to the MT and MTs cannot provide the NAS provided IP parameters to the TE, i.e. the TE cannot receive that information from the MT because of separation between the TE and MT. Example of information are the DNS configuration or Rediscovery indication.
The TE gets LAN side IP parameters configuration from the MT, i.e. using DHCPv4 (for IPv4) or IPv6 Router Advertisement/DHCPv6 (for IPv6). MT hosts the DNS resolver for TE and its address can be obtained from MT using DHCP or IPv6 RA. When TE uses DNS resolver in MT, the MT in turn uses its configured network DNS resolver (e.g. EASDF, L-DNS) which is the expected DNS resolution chain and it results in the discovery of the correct EAS. An application in the TE that complies with EAS (re-)discovery described in this specification is not recommended to override operator-provided DNS settings as described in clause C.3.
For the split-UE and MTs cannot provide the NAS information requesting UE to redo DNS lookup received from the SMF to the TE or the TE OS. In such cases, the closest EAS is still reachable, for example, if anycast EAS address is used.
For the Split-UE in the option C case, if the new address of Local DNS Server cannot be provided to the TE or the TE OS from the MT, so the TE continues to use the old DNS Server to perform the EAS discovery and cannot receive the DNS Query/Response from the 5GC (e.g. the BP will route the DNS Query to the L-PSA). After no DNS Query response is received from the 5GC for serval times or an information indicating the old DNS Server unreachable (e.g. ICMP message of Host Not Reachable), the TE initiates a new DNS Server Discovery via a DHCP message to the 5GC, and the SMF may send the same new DNS Server IP address to the UE in the DHCP response message than sent via PCO in the PDU Session Command. After the UE gets the new DNS Server IP address, the UE uses the new DNS Server IP address to perform the EAS (re-)discovery.
C.6 Detection of UE not using 5GC provided DNS server p. 79
The UPF Traffic detection and traffic reporting capabilities specified in clause 5.8 in TS 23.501 can be used to monitor if the UE uses a DNS resolver that is different than the one provided by the 5GC, e.g.:
- the SMF can install Packet Detection Rule(s) in the UPF to report when the traffic matches certain well known public DNS service IP addresses;
- the UPF can have an Application Filter defined to detect DNS ports as well as if the DNS traffic not destined to operator provided DNS servers (e.g. EASDF). The SMF can refer to this filter using an application ID.
D Examples of AF Guidance to PCF for Determination of URSP Rules p. 81
a)
The examples b) to e) above can correspond to different AF(s) representing different corporate that have different policies. How the rule precedence between rules for different AFs are set in the URSP rules is up to the operator policy.
In the examples above, when a location specific corporate DNN, S-NSSAI has been agreed, as an alternative, the location area where the DNN is accessible can also be set as part of the SLA agreement configured on the NEF.
The UE is to use a specific (DNN, S-NSSAI) (e.g. working in SSC mode 2 or 3 with the Distributed Anchor deployment) when trying to reach some domains while it should use another (DNN, S-NSSAI) (e.g. working in SSC mode 1) for other domains. In this example, the AF can indicate two FQDN filters, optionally with corresponding filtering rule priorities, if the FQDN filters overlap. For each FQDN filter, the AF can indicate a corresponding DNN, S-NSSAI.
b)
Corporate applications only reachable via a specific (DNN, S-NSSAI) negotiated with the operator; corresponding URSP rules (URSP rules referring to domains of these corporate applications) shall only point to this specific (DNN, S-NSSAI). In this example, the AF can indicate one FQDN filter for the corporate applications. Optionally, the AF can indicate also the corresponding DNN, S-NSSAI for the FQDN filter. If DNN, S-NSSAI is not provided by the AF, the NEF can determine it based on the AF identity.
c)
Corporate applications reachable via a (DNN, S-NSSAI) but only in some location; e.g. the corporate applications are only accessible when the UE is in some location corresponding to the corporate premises. In this example, the AF can provide information as in bullet b) and additionally provides where the corporate applications are accessible. URSP Rules will guide the UE select the (DNN, S-NSSAI) when the UE is in the geographical zone.
d)
Internet applications not reachable via a specific (DNN, S-NSSAI) negotiated with the operator but that should be only reachable via a general purpose (DNN, S-NSSAI); e.g. traffic of UE(s) of a third party targeting Internet applications is not to be sent to a specific (DNN, S-NSSAI) negotiated with the operator as this traffic is not expected to cross the Intranet of the corporate. In this example, the default operator rules are used generate a "match all" URSP rule with a low filtering rule priority and a corresponding generic purpose DNN, S-NSSAI.
e)
Internet applications reachable via both a specific (DNN, S-NSSAI) negotiated with the operator and via a general purpose (DNN, S-NSSAI) for which the third party may want to set preferences between these 2 kinds of connectivity. These preferences may depend on the UE location. In this example, the AF can indicate FQDN filters as in bullet b), but the FQDN filters are for Internet applications. In addition, the AF can indicate where the Internet applications are accessible via the specific DNN, S-NSSAI. In addition, the default operator rules are used generate a "match all" URSP rule with a low filtering rule priority and a generic purpose DNN, S-NSSAI.
f)
Combination of bullets c) and e). In this example, the AF can indicate one FQDN filter for corporate applications as in bullet c) and another FQDN filter for Internet applications as in bullet c), In addition, the AF can indicate filtering rule priorities for the FQDN filters, if the FQDN filters overlap.
g)
Corporate applications reachable via a (DNN, S-NSSAI) in some location and via another DNN, S-NSSAI in another location; e.g. the corporate applications are only accessible via a location specific corporate DNN, S-NSSAI. In this example, the AF can indicate an FQDN filter as in bullet c), but indicates two or more sets of location conditions for the FQDN filter and indicates different DNN, S-NSSAI for each. In addition, if the geographical zones overlap, the AF can indicate a Route Selection Descriptor Precedence for each of them.
E EPS Interworking Considerations p. 82
E.1 General p. 82
5GC is specified to support interworking with EPC. Edge Computing deployments that use interworking need to consider the aspects outlined in this Annex.
E.2 Distributed Anchor p. 82
SSC mode 3 cannot be used when the UE is registered in EPC as 5G-NAS is not available. Re-establishing a PDN connection after releasing an old one can be done in EPS using the "reactivation requested" cause value in EPS bearer context deactivation (see clause 6.4.4.2 of TS 24.301), if the feature is supported by the EPS network.
E.3 Multiple Sessions p. 82
The URSP rules provided by 5GC to the UE are defined to cover both 5GS as well as EPS when interworking is applied. In EPS there is no possibility to provide new URSP rules to the UE, instead according to clauses 5.15.5.3 and 5.17.1.2 of TS 23.501, the URSP rules provided to the UE when it was registered in 5GC can also be used when the UE is registered in EPC if HPLMN uses URSP (see TS 24.526).
AF guidance of URSPs may not take effect if the UE is in EPS and the UE does not use the URSP rules on EPS (see clause 4.4.2 of TS 24.526 for the use of URSP in EPS). Therefore, it is not deterministic when they will take effect, since PCF could have issued the URSP rules when the UE was on EPS (where URSP rules cannot be sent).
E.4 Session Breakout p. 82
As traffic offload via UL CL/BP is not supported over EPC, when a PDN connection is initiated in EPS or a PDU Session is handed-over to EPS, the SMF+PGW-C can send to the EASDF DNS message handling rules requesting the EASDF to transparently forward any DNS traffic. The SMF+PGW-C can send to the EASDF new DNS message handling rules (with actual reporting and actions as defined in clause 6.2.3.2.2) when the PDU Session/PDN connection is handed-over (back) to 5GS.
When a PDN connection is initiated in EPS, the SMF+PGW-C can also select a normal DNS Server (i.e. different from an EASDF) to serve the PDN Connection, and then indicate to the UE to use the EASDF as DNS Server when the PDU Session/PDN connection is moved to 5GS.
