5 Services instead of interfaces

5.1 The trouble with naming a pair

A reference point is a conceptual point where two non-overlapping functional groups meet §Annex A. That definition sounds harmless and has an expensive consequence: the name belongs to the pair, not to the behaviour.

So if function A and function B exchange exactly the same thing that function A and function C exchange, the document still has to give those two conversations two different names. Nothing in either name says they are the same, and nobody reading a list of reference points can tell.

Draw the same network with services instead and the duplication disappears. The interface belongs to the producer, so one name covers every consumer that calls it, and two consumers calling the same thing visibly call the same thing.

That sentence is the whole point of Annex A. It is a mapping rule for reading older material and older diagrams: where you see a reference point, look for the service or services that now carry it.

One reference point can become one service-based interface or several, and one network function can expose several services through the interface it exhibits §Annex A.

The naming of the interfaces themselves — Namf, Nsmf, Nudm and the rest — is The shape of the 5G core. This chapter is about what lives behind them.

5.2 What a service is

Two roles, and they are per call, not per function. The same function is a producer of its own services and a consumer of everybody else's. When a producer cannot answer a request on its own it goes and consumes services from other functions to fulfil it §7.1.2.

Services are not invented from nothing. The specification says where they come from: they are derived from the system procedures that describe end-to-end behaviour, and a system procedure can then be described as a sequence of service invocations §7.1.1. Procedure first, service second.

That is a deployment requirement, not a style note. Two services of the same function must be scalable and repairable separately. The document does concede that services inside one function may share resources such as context data, and says that this still does not excuse managing them together §7.2.1.

Below the service sits one more level. A service is reached through an interface, and an interface may consist of one or several operations §7.2.1.

5.3 Reading the names

Clause 7.2 is a list of tables, one per function, each naming that function's services and pointing at the clause of TS 23.502 where its operations are defined §7.2.1. You do not read it end to end. You read the shape.

Function	A few of its services
AMF	Namf_Communication, Namf_EventExposure, Namf_MT, Namf_Location
SMF	Nsmf_PDUSession, Nsmf_EventExposure, Nsmf_NIDD
NRF	Nnrf_NFManagement, Nnrf_NFDiscovery, Nnrf_AccessToken, Nnrf_Bootstrapping
UPF	Nupf_EventExposure, Nupf_GetUEPrivateIPaddrAndIdentifiers
SCP	Nscp_EventExposure

Those rows come from the tables for the AMF §7.2.2, the SMF §7.2.3, the NRF §7.2.6, the UPF §7.2.29 and the SCP §7.2.30.

A service name is the interface name, an underscore, and a capability.

The capability is a noun, not a verb: Namf_Communication is not one call, it is everything a consumer does through the AMF towards the device or the access network, including asking for an EBI allocation for the sake of 4G interworking §7.2.2.

Nsmf_PDUSession is likewise the whole of managing PDU sessions, using the policy and charging rules the SMF received from the PCF §7.2.3.

Add a third part and you have an operation. Nnrf_NFManagement_NFRegister is the register operation of the NRF's management service §6.3.1.

Nupf_EventExposure_Subscribe §5.8.2.17 and Nupf_EventExposure_Notify §5.8.2.18 are the two halves of a subscription to user plane events.

Two things stand out once you have read a few tables.

The first is that _EventExposure recurs almost everywhere — AMF, SMF, PCF, UDM, UPF, SCP. It is the same idea each time: subscribe, and be told when something happens. Even the UPF, a packet forwarder, and the SCP, a message router, expose one §7.2.29, §7.2.30.

The second is that a large function is not one big service. The UDM splits into ten, and the split follows what a consumer wants rather than how the UDM is built: Nudm_UECM for who is currently serving a device, Nudm_SDM for subscription data, Nudm_UEAuthentication for authentication data §7.2.5.

The PCF splits much the same way, largely one service per kind of policy §7.2.4.

5.4 The two ways to call

Whatever route a message takes, only two patterns exist §7.1.2.

Request-response is one consumer, one producer, one answer, expected within some timeframe §7.1.2.

The producer may attach a Binding Indication to the response — a hint saying "for this context, keep coming back to this instance, or at least to this set" — which the consumer uses to pick a producer for the next request. What that hint may contain is §6.3.1.0.

Subscribe-notify is one producer and any number of consumers. The subscribe request must carry a notification endpoint: a Notification Target Address and a Notification Correlation ID, which together can be one callback URL §7.1.2.

Without both, the producer would know where to send the notification but not which subscription it answers.

Subscribing happens in one of three ways §7.1.2:

• Explicit — its own request and response between consumer and producer.

• Implicit — the subscription rides along inside another operation of the same service, so setting a thing up and asking to hear about it is one call.

• Default notification endpoint — the consumer registers, per type of notification, an endpoint with the NRF when it registers itself. Nothing is subscribed at call time at all.

A consumer may also subscribe on behalf of somebody else: NF_A subscribes at NF_B and puts NF_C's notification endpoint in the request, so the notifications go to NF_C.

NF_A may add a second endpoint of its own, tied to subscription-change events, so that it still hears when its own subscription is altered §7.1.2.

5.5 Getting listed, and being allowed to call

A service that nobody can find is not a service. Each NF instance tells the NRF which services it supports, usually when it first becomes operative, and updates that entry whenever a service instance is activated or deactivated — after a scaling operation, for example §7.1.5.

What it registers is more than a name list. It includes capacity and configuration information at the time of instantiation, and per service it may include the notification endpoints that service is prepared to receive notifications on §7.1.5.

Another authorized entity, such as a management function, may register on the instance's behalf.

De-registration goes the same way, and the clause covers the ugly case: an instance that shuts down cleanly de-registers itself, and an instance that crashes or becomes unreachable must be de-registered by an authorized entity instead §7.1.5. Nobody is left calling a dead endpoint forever.

Being listed is not permission. Authorization has two steps at two different sizes §7.1.4:

• May this consumer discover this producer at all? Checked per NF, by the NRF, during discovery. Where discovery is done from local configuration instead, the configured functions are assumed to be authorized.

• May this consumer make this particular request? Checked per UE, per subscription or per roaming agreement, and the specification puts this check inside the service logic of the producer itself, not in the NRF.

The information the NRF checks against is part of the producer's own profile: which NF types and which realms or origins may consume its services §7.1.4.

Service discovery itself is the NF discovery machinery, and it has its own chapter — How one function finds another §7.1.3.

5.5.1 What the document does not settle

If you are looking for API version numbers here, they are not in this document. TS 23.501 names services and points at TS 23.502 for their operations, and at other documents for the protocol detail — TS 29.510 for how long a discovery result stays valid, for one §6.3.1.

Two traces of versioning do appear all the same. A consumer may state the supported features it requires when it asks the NRF for a producer §6.3.1, and the NRF's bootstrapping service is called out as a version independent API, which the clause says may be useful over roaming interfaces §6.3.26.

5.6 Four ways the same call can be routed

Now the part that surprises people. Consumer and producer, request and subscription, all of that is fixed. How the message gets there is not, and there are four legal answers. Annex E calls them models A to D §E.1.

• Model A — direct, no NRF. No NRF, no SCP. Consumers are configured with the producers' profiles and call whoever they choose.

• Model B — direct, with the NRF. The consumer queries the NRF, selects a producer from the result, and sends the request straight to it.

• Model C — indirect, without delegated discovery. The consumer still queries the NRF and still selects — an NF set, or one instance in it — but sends the request to the SCP with that selection in it. If the consumer named a set, the SCP picks the instance, asking the NRF for selection parameters such as location and capacity where it can.

• Model D — indirect, with delegated discovery. The consumer discovers and selects nothing. It puts the discovery and selection parameters into the request itself and hands it to the SCP, which finds a suitable producer, querying an NRF if it needs to.

All four can coexist in one and the same network §7.1.1. The choice is not network-wide policy: it comes from the local configuration of the consumer, or of the producer in the case of notifications, and one NF may use the SCP for some of its traffic and not for the rest §7.1.1.

5.7 What an SCP looks like when somebody builds one

Annex G sketches deployments, and says up front that it is a set of examples and not a list of the options §G.1. Three shapes appear.

A service mesh — a layer of small proxies, one beside each function, carrying all the calls between them. An SCP Service Agent sits in the same deployment unit as the 5G core functionality — a container, for instance — and gives that unit indirect communication and delegated discovery.

A mesh controller pushes routing and selection policies to the agents.

Inside the mesh the SCP handles registration and discovery itself, and talks to an external NRF only for exposing services outward and for calls that leave the mesh §G.2.1.

Crossing a mesh boundary is deliberately blind: the outgoing mesh knows neither whether the target sits in a mesh nor what that mesh looks like inside.

An egress proxy (the proxy calls leave through) hands the request to the other mesh's ingress proxy (the proxy calls arrive at), and the only shared knowledge is a routing rule such as a name prefix §G.2.2.

Independent deployment units. SCP and core functions are deployed separately. SCP agents are the HTTP intermediaries; an SCP controller feeds them policies over an interface that is entirely the vendor's business.

One sentence here is worth remembering: the SCP is not a service producer, but as an HTTP proxy it registers services in the NRF on behalf of the producers. Direct communication can go on in the same deployment at the same time §G.3.

Name-based routing. A third example builds the SCP around a path computation element — the part that works out which way a message goes — with one service router per cluster mapping requests onto publish and subscribe underneath §G.4.0.

Once a name has been resolved, functions in the same cluster may talk directly; the service router is used when the target sits in another cluster §G.4.1.

The SCP does have one service of its own, Nscp_EventExposure, which reports SCP related information to consumers §7.2.30 — load, delay, error rates and message counts are the kind of thing meant §6.2.19.

5.8 Where this meets the rest

Discovery and selection, NF sets, binding and reselection are How one function finds another. The interface names and the two ways the architecture is drawn are The shape of the 5G core, and what each function is for is What each network function does.

Clause 7.3 is one sentence: exposure of these capabilities outside the operator's network is described elsewhere §7.3, which is Computing close by, and opening the door. Who is allowed to call whom, in cryptographic terms rather than architectural ones, is Who you are and who may listen.