Edge Computing - EAS Discovery and Edge Relocation

An application server close to the UE can answer in a few milliseconds instead of tens. That is the whole idea of edge computing. The difficulty is not in running a server at a local site. It is in making sure that the UE talks to the right server, the one near its current point of attachment, and that it keeps talking to a suitable one when it moves. The server itself is called an EAS (Edge Application Server), and most of 3GPP's edge work is about finding, reaching and changing an EAS.

Release 17 put this into two specifications. TS 23.548 defines what the 5G core does: connectivity models, EAS discovery through DNS with a new function called the EASDF, and edge relocation. TS 23.558 defines an optional application layer on top: an enabler client in the UE and enabler servers at the edge. The two can be used together or separately. Both specifications have grown in later releases, and this page describes them as in the Release 20 versions downloaded for it, marking what goes beyond the Release 17 core where that is clear.

• What problem does edge computing solve in 5GC ?
• Connectivity models - where the local PSA sits
• EAS discovery with DNS and the EASDF
• Edge relocation
• Application layer architecture - EEC, EES, ECS and EAS
• After Release 17
• Reference

What problem does edge computing solve in 5GC ?

Why does a core network need special procedures for edge servers ? The server is just an IP host in a data network. The reason is that an application usually runs many instances of the same server, in many sites, often behind one domain name. When the UE resolves that name, ordinary DNS does not know where the UE is attached, so it may return a server hundreds of kilometres away. Even when the UE reaches a local server, the user plane must leave the 5G core at a local UPF. If it leaves at a central one, the latency gain is lost on the way.

So 23.548 solves two linked problems. The first is routing: the PDU session needs a PSA (PDU Session Anchor) UPF at the local site, the L-PSA, for the edge traffic. The second is discovery: the DNS answer must point to an EAS reachable through that local anchor. 23.548 calls the local site the local part of the DN, and the environment that runs the EAS the EHE (Edge Hosting Environment). An EHE can be run by the operator or by a third party.

• EAS: an application server resident in an Edge Hosting Environment.
• Routing: edge traffic must leave the 5GC through a local PSA UPF. The general N6 picture is in the N6 page.
• Discovery: the DNS answer must depend on where the UE is, or more exactly on which local anchor it uses.
• Reuse: 23.548 builds on Release 15 and 16 tools in TS 23.501, such as UL CL, branching point, SSC modes and AF influence on traffic routing.

Connectivity models - where the local PSA sits

Where does the local anchor come from, and how much of the UE's traffic goes through it ? 23.548 clause 4.3 defines three connectivity models. They differ in whether the whole PDU session is local, only part of it, or a separate session. The choice affects every later procedure, so it is worth fixing first.

URSP rules can steer applications to PDU sessions in any of the models. They are required for the Multiple PDU Sessions model, because the UE must know which application uses which session. URSP itself is described in the Manage UE Policy page. Session Breakout is the model that most of 23.548's detailed procedures address, and Figure 1 shows it.

Figure 1. Session Breakout. The UE keeps one PDU session and one IP anchor at the C-PSA, and the UL CL or branching point sends only the edge traffic out through the local PSA to the EAS.

• Session Breakout keeps the IP address: the C-PSA stays as the IP anchor when an UL CL is used, so the UE does not notice when the local PSA is added or changed.
• Distributed Anchor is the simplest: everything is local, but moving the anchor means a new session and usually a new IP address.
• Roaming: 23.548 also covers local breakout roaming, and in later versions home routed sessions with session breakout in the VPLMN (HR-SBO).

EAS discovery with DNS and the EASDF

How does the UE get the IP address of the nearest EAS ? 23.548 keeps the mechanism the Internet already uses, DNS, and makes the DNS answer location aware. A DNS system can choose an answer by the source IP address of the query or by the EDNS Client Subnet (ECS) option from RFC 7871. The 5GC's job is to make sure the query reaches a DNS resolver that knows the UE's local site, or to add an ECS option that represents that site.

For the Distributed Anchor model this is easy. The SMF selects a DNS server for the session, gives it to the UE in the PCO, and that server is local. For Session Breakout it is harder, because the UE's IP address belongs to the central anchor, and the local PSA may not exist yet when the DNS query is sent. Release 17 adds a new network function for this case, the EASDF (Edge Application Server Discovery Function).

The EASDF is a DNS handler controlled by the SMF. The SMF gives the EASDF address to the UE as its DNS server. When a DNS query arrives, the EASDF applies DNS message handling rules from the SMF. A typical action is to forward the query to a local DNS with an ECS option for the right site. Other actions report the query and the answer to the SMF, or buffer the message. Figure 2 shows the main sequence.

Figure 2. EAS discovery with the EASDF in the Session Breakout model, simplified. The EASDF can hold the response until the SMF has prepared the local path, so the first packet to the EAS already goes through the local PSA.

• DNS message handling rules: each rule has a precedence, a detection part (query or response, FQDN ranges, EAS IP address ranges) and actions. The actions are report, forward, buffer and discard.
• EAS Deployment Information: the AF can tell the 5GC, through the NEF, which FQDNs are served by which DNAI. The SMF uses it to build the rules. From it, the SMF can also configure a BaselineDNSPattern in the EASDF that is not tied to one session.
• No NAT before the EASDF: the EASDF connects to the PSA UPF over N6 without a NAT, so it sees the real UE address of each DNS query.
• Local DNS alternative: instead of an EASDF, the SMF can steer DNS queries to a local DNS resolver through the local PSA. 23.548 clause 6.2.3.2.3 covers that variant.
• Re-discovery: when the UE moves and the old EAS is no longer optimal, the same mechanism runs again. This is called EAS re-discovery.

One weakness remains. The UE must actually send its DNS queries to the server from the PCO. An application or an operating system may use its own DNS resolver instead, and then none of this works. Later versions of 23.548 add the EDC (Edge DNS Client) functionality in the UE to address this. With EDC, the SMF can allow or require that DNS queries for a PDU session go to the indicated server.

Edge relocation

What happens when the UE moves away from the site that serves it ? The local PSA and the EAS that were close are now far. 23.548 calls the change of EAS and/or local PSA edge relocation. The network can trigger it, for example because of UE mobility, and the AF can trigger it, for example to balance load between EAS instances. The user plane part reuses Release 16 tools: SSC mode 2 or 3, or a change of the local PSA under the UL CL or branching point.

The application part is harder. The UE has an open connection to the old EAS, often TCP or QUIC with application state. Changing the path to a new EAS breaks that unless the application moves its context too. 23.548 offers three ways to handle the application side.

• Re-discovery and reconnect: the UE discovers a new EAS through DNS, as above, and connects to it. The application has to tolerate the reconnection.
• AF relocation: the AF instance that controls the routing can change together with the EAS, using AF influence on traffic routing and its early and late notifications from the SMF.
• EAS IP replacement: the local PSA UPF rewrites addresses. Uplink packets to the old EAS IP address and port are redirected to the new EAS, and downlink packets from the new EAS get the old address back. The UE keeps its connection unchanged. This requires TCP, TLS or QUIC context transfer between the EAS instances, and 23.548 notes that this depends on what third party platforms support.

The AF also has more control during relocation. It can ask for simultaneous connectivity over the source and target PSA for a time, so packets in flight are not lost. It can also request buffering at the UPF for low packet loss. Which of these an operator uses depends on the application, and 23.548 does not prescribe one.

Application layer architecture - EEC, EES, ECS and EAS

Everything above works with any application and no special UE software. TS 23.558 adds an optional layer for applications that want more: discovery by service rather than by domain name, network information exposed to the server, and coordinated context transfer when the EAS changes. 23.548 notes that its own features do not depend on this layer. Figure 3 shows the entities and the EDGE reference points between them.

Figure 3. The 23.558 application layer. The EEC in the UE finds an EES through the ECS, and the EES helps the EEC find and reach an EAS. EDGE-2, EDGE-7 and EDGE-8 give the servers access to 5GC capabilities.

The 5GC and this layer meet at one practical point: how does the EEC learn the ECS address ? 23.548 clause 6.5.2 answers it. A UE that hosts an EEC indicates in the PCO at PDU session establishment that it can receive ECS addresses. The SMF then sends ECS Address Configuration Information in the PCO, based on the subscription from the UDM, and can update it with PDU session modification. Each entry can carry a spatial validity condition, given as a geographical area, a list of TAs or a list of countries.

Service continuity is the other large topic in 23.558. When a better EAS becomes available, the application context moves from the source EAS (S-EAS) to a target EAS (T-EAS). 23.558 calls this ACR (Application Context Relocation). The trigger can be UE mobility, overload or maintenance, and ACR can be detected and executed by the EEC, the source EAS or the source EES, in several defined scenarios. The 5GC part of the move, such as a new local PSA, still uses the 23.548 procedures.

After Release 17

Both specifications started in Release 17 and kept growing. The versions used for this page are 23.548 v20.0.0 and 23.558 v20.3.0, which include all later additions. The documents do not tag each clause with a release, so the list below names the additions without assigning each one to a release. Treat it as a map of what to look for beyond the Release 17 core.

• HR-SBO: edge computing in the visited network for home routed sessions, with a V-EASDF and local DNS in the VPLMN.
• EDC functionality: a UE function that makes sure DNS queries go to the server given by the SMF.
• Common EAS for a set of UEs: selection of a common DNAI and a common EAS for a group of UEs, for example for a shared game session. On the application layer side, ECS-ER federation supports it.
• Local Offloading Management: the intermediate SMF controls the EASDF and the local breakout, with an N88a reference point between them.
• Edge and cloud: 23.558 adds the CAS (Cloud Application Server) and CES (Cloud Enabler Server) and ACR between edge and cloud.
• Other items: N6 delay measurement, mapping between EAS address information and DNAI, and edge relocation that considers user plane latency.

Release 17 is therefore the foundation: three connectivity models, the EASDF, edge relocation, ECS address provisioning, and the EEC/EES/ECS architecture. I am not certain whether EAS IP replacement was already in Release 17 or came later, so this page does not place it. As far as I can tell from the clause structure, the later additions extend those pieces rather than replace them. The Release 17 page gives the release overview, and the SMF role is described in the SMF page.

Reference

• 3GPP TS 23.548 V20.0.0 : 5G System Enhancements for Edge Computing; Stage 2. Clauses 4 to 6
• 3GPP TS 23.558 V20.3.0 : Architecture for enabling Edge Applications. Clauses 6.3, 6.5 and 8.8
• 3GPP TS 23.501 : System architecture for the 5G System. Clause 5.13, support for edge computing
• IETF RFC 7871 : Client Subnet in DNS Queries
• N6, SMF, UPF, Manage UE Policy, PDU Session Establishment, Release 17 (ShareTechnote)