Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.548  Word version:  18.6.0

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

 

6  Procedures for Supporting Edge Computingp. 13

6.1  Generalp. 13

Edge Computing enables operator and 3rd party services to be hosted in EAS close to the UE's point of attachment. The traffic to EAS can be routed based on the UE position and EAS availability "near to" that position.
The subsequent clauses describe the procedures for supporting Edge Computing in 5G System considering different connectivity models, including:
  • EAS discovery and re-discovery.
  • Edge relocation.
  • Network exposure to Edge Application Server.
  • Support of 3GPP application layer architecture defined in TS 23.558.
  • Support of AF guidance to PCF determination of proper URSP rules.
Up

6.2  EAS Discovery and Re-discoveryp. 14

6.2.1  Generalp. 14

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.
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).
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.
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 configuration of the DNS Server (IP address and, conditionally, DNS security information of the EASDF/DNS Server/ Resolver; see TS 24.501 and TS 33.501) indicated by the SMF (see clauses 5.2.1 and 6.2.4) then resolves the FQDN by its own DNS mechanism.
For EASDF, the DNS security information may be provided by EASDF to SMF. The DNS security information of the EASDF/Local DNS Server/Resolver may also be locally configured in the SMF.
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.
Up

6.2.2  EAS (Re-)discovery over Distributed Anchor Connectivity Modelp. 15

6.2.2.1  Generalp. 15

Void

6.2.2.2  EAS Discovery Procedurep. 15

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, 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.
Up

Up   Top   ToC