Reaching further · chapter 20 of 27 · 15 minutes
20 Computing close by, and opening the door
How the core puts an application server near the user, and how software outside the operator's network asks the core for information and for changes.
Built from §5.13 §5.20 §5.20a §5.20b §5.20c §5.20d §5.46 §7.3
Two ideas share this chapter: moving the application towards the user, and letting that application talk back to the network carrying it.
20.1 Why an application wants to sit at the edge
Every kilometre of fibre between a phone and its server costs delay, and every packet crossing the operator's backhaul costs capacity somebody pays for. Both bills fall if the server sits near the base station.
The specification says exactly that: hosting operator and third-party services close to the device's point of attachment gives lower end-to-end latency and less load on the transport network §5.13.
The core reaches that goal by choosing a UPF (the packet-forwarding function in the user plane) near the device and sending selected traffic out of it to a local data network over N6 §5.13.
The choice can rest on the subscription, the device's location, what an application asked for, policy, the measured delay between the radio network and each candidate UPF, or delay measured on N6 itself §5.8.2.23.
20.2 What the architecture offers the application
Clause §5.13 lists the enablers. Each is a mechanism taught elsewhere in this course; here is what each one is for when the goal is a nearby server.
-
Choosing the user plane function. The core selects, and later reselects, a UPF that routes traffic into the local part of the data network §6.3.3.
-
Local routing and traffic steering. The core picks out which traffic goes to the local applications, using one session with several exit points, or a session whose single exit point is itself local §5.6.4.
-
Session and service continuity. What happens to the session when the device moves away §5.6.9.
-
Application influence on routing. An outside application asks for its traffic to go somewhere, through the PCF (the function that turns operator policy into the rules a session is run by) or through the NEF §5.6.7.
-
Capability exposure. Core and application tell each other things, through the NEF §5.20 or straight from the UPF §5.20d.
-
Quality and charging. The PCF supplies the rules for traffic that exits locally — Rules, and paying for them and What the network promises unchanged.
-
Local area data networks. A data network that only exists in part of the country §5.6.5.
The rest of the list points outside this document. The three a reader meets most are discovery and re-discovery of an edge application server, edge relocation, and reselecting the session manager on the DNAI — all specified in TS 23.548 or TS 23.502 §5.13.

20.2.1 The fork in the path, from the application's side
Chapters The connection to a data network and Where the packets actually go describe the two ways one session gets more than one exit. What matters here is how each looks from outside.
With an uplink classifier, the SMF (the function that sets up a session and steers its traffic) inserts a UPF that examines uplink packets and diverts the ones matching a filter to the local anchor. The device is not told, and sees one address on one session §5.6.4.2.
It is not involved when an anchor is re-allocated either, so the second anchor never becomes visible to it §5.6.9.2.2. The client cannot detect the fork; it just finds the server nearer.
With a branching point, the session carries two IPv6 prefixes and the fork is made on the packet's source prefix. Here the device does take part: it picks the source prefix using routing information and preferences the network sends it §5.6.4.3.

20.2.2 A data network that only exists in some places
A local area data network, LADN, is a data network reachable only inside a named set of tracking areas. It is a service of the serving network, it applies only to 3GPP access, and it does not apply to home-routed roaming §5.6.5.
The device learns which DNN (the name of a data network) is a LADN either from its own configuration, or from the AMF (the function that keeps track of where a device is and whether it is reachable) — during registration, or later in a UE Configuration Update, which is also where the tracking areas come from.
Outside that area the device must not establish or activate a session for that DNN; inside it, it may §5.6.5.
The network enforces the same boundary. The AMF tells the SMF whether the device is IN, OUT or UNKNOWN, and on OUT the SMF either releases the session at once or deactivates its user plane and keeps it for a while §5.6.5.
A newer variant scopes all of this per DNN and slice §5.6.5a, which is where One network, many networks meets the edge.
20.2.3 Following a device that moves
A server two kilometres away stops being near when the user boards a train. The three session and service continuity modes are the answer:
-
Mode 1 keeps the anchor, and with it the IP address, whatever happens.
-
Mode 2 lets the network drop the session and have the device build a new one.
-
Mode 3 builds the new path before tearing down the old one, so connectivity is never lost, though the address changes §5.6.9.2.3.
An application can steer this. In its routing request it may set an indication that the device's IP address should be preserved, which stops the core reselecting the anchor for that traffic.
It may also say whether the application can be relocated at all, and ask that the old and new anchors stay up together for a while during an edge relocation §5.6.7.1.
20.3 Opening the door: what the NEF is for
Now turn the picture around. Something outside the operator wants to ask the network a question, or ask it to behave differently — but it must not call the AMF or the PCF directly, because it is outside the operator's trust domain and knows none of its internal identifiers.
The Network Exposure Function is the door. Applications the operator trusts may be allowed to talk to the relevant network functions directly; every other application shall use the external exposure framework through the NEF §6.2.10.
Clause §7.3 is one sentence, pointing back at the exposure clauses.

20.3.1 The five things that can be exposed
Clause §5.20 sorts external exposure into five categories.
| Category | What an outside party gets |
|---|---|
| Monitoring | Events about a device: location, reachability, roaming status, loss of connectivity, quality monitoring results, and changes to a group's membership |
| Provisioning | The right to supply information the network will use: expected device behaviour, group information, service parameters, a static address, an edge configuration server address |
| Policy and charging | Session and charging policy, quality enforcement, accounting, influence on access and mobility policy — including becoming the party that pays |
| Analytics reporting | Discovery and consumption of the analytics the NWDAF — the function that gathers data from the network and works out patterns in it — produces |
| Member UE selection | A filtered list of candidate devices, drawn from a list the application supplied |
The NEF may also front the API framework CAPIF §6.2.5.1, slice admission events §5.15.11, time synchronisation capabilities §5.27.1.8 and energy functions §5.51. The full list of its services, background data transfer policy negotiation among them, is the service table in §7.2.8.
20.3.2 From an outside name to an inside name
An outside application usually knows a device only by its address. The NEF turns that into the permanent identifier the core uses, working from the address plus the DNN and slice, which are needed whenever the address is an IP address §5.20.
Going the other way is where privacy bites. An application that asks for a stable handle for a device gets an AF specific UE Identifier — a GPSI, which is the kind of subscriber name the operator lets the outside world see — and never a phone number:
The value may sit in the UDR or be generated by the UDM on demand; the operator can renew it by replacing or removing the stored one, after which the UDM rejects any request using the old value §5.20.
20.3.3 What a routing request contains, and what happens to it
The request an application sends to influence routing is a defined set of fields §5.6.7.1. The ones that carry the meaning:
| Field | Meaning |
|---|---|
| Traffic Description | Which traffic, as a DNN and optionally a slice, plus an application identifier or packet filters. Through the NEF it may instead be a service identifier the NEF resolves |
| Potential Locations of Applications | Where the application sits, as a list of DNAIs — the names by which the core knows an access point into a local data network |
| Target UE Identifier(s) | One device, a list, a group, or any device using that combination of DNN, slice and DNAI |
| Spatial and Temporal Validity | Only devices in this area, only during these times |
| N6 Traffic Routing requirements | A routing profile agreed in advance, or explicit routing information, per DNAI |
| Application Relocation Possibility | Whether the core may move the chosen location later |
| Subscription to path management events | Tell me when the path changes, before it changes, after it changes, or both |
The translation the NEF performs is the interesting part:
-
A service identifier becomes a DNN and slice, and may also be what the NEF uses to authorise the request at all.
-
A geographical area becomes areas of validity, using pre-configuration.
-
An external group identifier becomes the internal one §5.9.7; a GPSI becomes a SUPI, the permanent subscriber identity the core uses inside, taken from subscription data at the UDM.
-
The application's own transaction identifier becomes an internal one the NEF keeps mapped, so the outside never sees inside labels.
Then the PCF, not the NEF, authorises the request against operator policy and turns it into PCC rules — the policy and charging rules a session is run by — for the SMF, carrying the traffic filters, the DNAIs and a traffic steering policy identifier §5.6.7.1.
A request aimed at many devices or at any device goes through the NEF into the UDR, and reaches whichever PCFs need it §6.3.7.2.
What comes back is a notification of a path change: the old and new DNAI, the routing information on N6, the device's address and its GPSI.
Early notifications arrive before the new path is configured, late ones after, and the application may ask the core to wait for its acknowledgement in between §5.6.7.1.
20.3.4 Asking on behalf of a whole group
Three clauses handle groups, so an application need not repeat itself a million times.
An application may provision two attributes for a group, per DNN and slice: a LADN service area, and a default quality profile §5.20b.1.
That profile is a 5QI (a number pointing into a table of delay, loss and priority values), an ARP (the rank that decides whose resources are taken when the network runs short) and a 5QI priority level.
The service area is stored as subscription data and reaches the AMF, which then treats that DNN as a LADN DNN; if the request gave a geographical area, the NEF converts it to tracking areas first §5.20b.2.
The UDM stores the quality profile and uses it to set each member's subscribed profile; where a device is in several groups with conflicting values, the UDM picks one §5.20b.3.
Separately, an application may provision traffic characteristics and monitor performance for a group §5.20c.
Here the request is expanded per member: the group identifier becomes a list of SUPIs, only members with an active session on the right DNN and slice are acted on, and each member carries its own status of activated, de-activated or failed. Members joining and leaving are picked up as they happen.
Data also flows the other way: a network function needing data from an application may subscribe directly or through the NEF, and that data feeds the analytics function §5.20a.
20.3.5 Reporting straight from the user plane
The control plane is the wrong place for a stream of measurements, so the SMF may instruct the UPF to report network information straight to the consumer, bypassing SMF, PCF and NEF §5.20d.1.
In an edge deployment the consumer can be a local NEF or, where trusted, a local application. Where the measurement is made in the radio network instead, the radio reports it inside the GTP-U tunnel to the anchor.
Two things travel this way: quality monitoring results §5.45 and the time-sensitive management information of Clocks, TSN and deterministic delivery §5.28.3.
20.4 When the application is training a model
Clause §5.46.1 covers three application-layer jobs: splitting an AI computation between two endpoints, distributing models and data, and federated learning — training across many devices without pooling their data.
None of the learning happens in the network: the decisions and the internal logic stay in the application and its client, explicitly out of 3GPP scope §5.46.1. The network only helps with the awkward parts.
-
Picking the devices. The application hands the NEF a list of target devices and at least one filter — current or past location, direction, distance apart, quality requirements, DNN, preferred access, desired transfer time, service experience.
The NEF asks the PCF, NWDAF, AMF and SMF for the matching data and returns one or more candidate lists §5.46.2.
-
What comes back with the list. Recommended time windows, each device's quality, location, access type and service experience. The NEF may also return the count of devices that failed each filter, which tells the application which requirement was too strict §5.46.2.
-
Picking the moment. The application may ask for a recommended time window using planned data transfer with quality requirements §5.46.1.
-
Getting the bandwidth. During the operation it may ask the NEF for quality for a list of devices, each named by IP address, and subscribe to quality monitoring on the ones where resources were granted, including consolidated data rate §5.45.4.
-
Nudging the network's own assumptions. It may provision expected device behaviour parameters, with a confidence and accuracy level attached §5.46.1.
Three limits: the application must be authorised by the core, the feature is not supported for roaming devices in this release, and the operation runs within a single slice §5.46.1.
20.5 Where this meets the rest of the system
The edge half reuses machinery taught earlier: anchors in The connection to a data network, forwarding in Where the packets actually go, promises in What the network promises, rules in Rules, and paying for them.
The exposure half is the outside face of Services instead of interfaces, and its name translation is the practical reason Every name the system uses separates internal from external names.
Roaming narrows both. Edge computing applies to non-roaming and local breakout, with one home-routed exception defined in TS 23.548 §5.13.
The PCF never applies a routing-influence request to a home-routed session. The one exception is that same home-routed case with session breakout, where the visited NEF hands the traffic influence straight to the visited SMF and the PCF is bypassed §5.6.7.1.
Check yourself
Answers appear when you pick one, with where they come from.
Q20.1 Why does the core pick a user plane function close to the device for edge computing?
The clause names exactly those two gains — reduced end-to-end latency and reduced load on the transport network. §5.13
Q20.2 An application the operator does not trust to talk to core functions directly must reach them how?
Trusted application functions may be allowed to interact directly. Everything else shall use the external exposure framework via the NEF. §6.2.10
Q20.3 Which of these is NOT one of the five categories of external exposure?
The five are monitoring, provisioning, policy/charging, analytics reporting and member UE selection. Nothing in the list touches the radio scheduler. §5.20
Q20.4 What is an AF specific UE Identifier?
It shall not correspond to an MSISDN, it is a GPSI in the form of an External Identifier, and the value handed out is different for different application functions, to protect privacy. §5.20
Q20.5 In user plane direct exposure, who sends the report to the consumer?
The function lets the UPF report network information directly to the consumer based on instructions provided by the SMF, bypassing SMF, PCF and NEF on the reporting path. §5.20d.1
Q20.6 Must an application use the NEF's member UE selection to pick devices for a training round?
The clause says the AF decides whether to use the function, and that without it an AF in either domain can select the members itself using location reporting, user plane information and analytics. §5.46.2
This chapter was written against TS 23.501 version 20.2.0, verified 2026-08-04. A newer version of the document may say something else.