NR CORE - NSSF

Before anything else on this page makes sense, it is worth being clear about what a network slice actually is, because the word suggests something more physical than it is. A slice is not a separate network and not dedicated hardware. It is a logical network built from the same functions and the same radio as everything else, but configured and dimensioned for one purpose - one slice tuned for very low latency, another for enormous numbers of cheap metering devices, another for ordinary mobile broadband. They coexist on one infrastructure, and a UE can be attached to several of them at once.

Each slice is named by an S-NSSAI, and a list of them is an NSSAI. Those two acronyms account for most of the vocabulary on this page, and almost every data structure described further down is a list of S-NSSAIs with a qualifier attached saying who asked for it or who approved it.

Which brings us to why a selection function has to exist at all. A UE that registers will ask for the slices it wants, but wanting is not the same as getting. The slices it asks for may not be ones it is subscribed to. They may be subscribed but not deployed in the particular tracking area the user happens to be standing in. They may be deployed there but currently too loaded to accept anybody else. Somebody has to reconcile the request against the subscription against what is actually available on the ground, and produce a straight answer the AMF can act on. That is the entire job of the NSSF, and it explains why such a small function is worth having at all.

NSSF plays(Network Slice Selection Function) has relatively simple function and interact with only a few NF(Network Functions). Within a PLMN, it interact only with NRF and AMF and exchange information about Network Slice Selection.

That picture makes your opening point better than any description could. It is the whole 5G core, and the NSSF has exactly one line attached to it - the blue N22 running down to the AMF. Compare that with the AMF in the middle, which has nine. The NSSF talks to one function, answers one kind of question, and has no user plane, no subscriber data of its own and no session state.

The question it answers is this. A UE that registers may ask for particular network slices, and the network has to decide which of them it is actually going to get. That decision is not obvious : the UE may ask for slices it is not subscribed to, or slices that exist in the network but are not deployed in the tracking area it happens to be standing in, or slices that are deployed but currently overloaded. Somebody has to reconcile what was asked for against what is permitted and what is available, and that somebody is the NSSF.

The AMF could in principle do this itself, and in a small network it effectively does - if there is no NSSF the AMF falls back on locally configured slice information. Separating it out matters when slices become numerous and their availability varies by area, because then the mapping is real operational data that changes, and it is better held in one place than replicated into every AMF.

Followings are the name of each network component.

AMF Access and Mobility Management Function ==> Equivalent to MME in 4G

AUSF    Authentication Server Function
DN       Data Network
NEF      Network Exposure Function
NRF      Network Repository Function
<hl1>NSSF</hl1>    Network Slice Selection Function
PCF      Policy Control Function ==> Equivalent to PCRF in 5G
(R)AN   (Radio) Access Network
SMF     Session Management Function
UDM     Unified Data Management ==> Equivalent to HSS in 4G
UPF      User Plane Function ==> Equivalent to PGW in 4G
SMSF   SMS Function
SEAF    SEcurity Anchor Function ==> part of AMF function
ARPF    Authentication credential Repository and Processing Function
SIDF    Subscription Identifier De-concealing Function

GET operation of NSSF

It is worth pausing on why this is a query rather than anything more elaborate. The NSSF could in principle have been designed to push slice information to AMFs as it changed, or to hold a subscription for each UE and notify when something moved. It does neither. It waits to be asked, answers, and forgets.

That works because the NSSF keeps no per-UE state at all. Everything needed to answer is carried in the request : what the UE asked for, what the subscription allows, where the UE currently is. The NSSF holds only the network-wide picture - which slices exist, where they are deployed, how loaded they are - and applies that picture to whatever question arrives. Nothing about a particular subscriber is remembered between one request and the next.

The practical consequences are worth noting because they explain the shape of the interface you are about to see. An NSSF can be replicated freely, since no instance knows anything the others do not. It can be restarted without losing anything. And the AMF must ask again whenever the situation changes rather than expecting to be told - which is precisely why the same operation appears in three different procedures rather than once at registration.

Since the main roles of NSSF is to provide Network Slice Information to AMF, the major operation should be GET operation. NSSF GET operation described in 29.531 is as follows.

One request, one response, and no state left behind on either side - which is what you would expect from a function whose entire job is to answer a question. Two details in that figure are worth drawing out.

   GET  .../v1/network-slice-information?<query parameters>      no request body
                                    |
                                    v
   200 OK       AuthorizedNetworkSliceInfo
   403 Forbidden  ProblemDetails
   4xx / 5xx    ProblemDetails      or 3xx redirect

It is a GET with query parameters and no body. That is a deliberate contrast with the registration on the NRF page, which was a PUT carrying a profile. Nothing is being created or changed here - the consumer is asking a question and everything it needs to ask sits in the URL. It follows that the operation is safe to repeat, and that an NSSF can be scaled out behind a load balancer without any of the instances needing to share state.

The response type is called Authorized, not Requested. That word is the whole function in one adjective. The AMF sends what the UE asked for together with what the subscription permits, and what comes back is neither of those - it is what the NSSF has decided the UE may use here and now. Reading the definition of that type further down this page, it carries an allowedNssaiList and a configuredNssai, and the specification notes that the NSSF may take load information from the NWDAF into account in order to leave overloaded slices out of the answer.

And notice that 403 Forbidden is named explicitly in the figure rather than being folded into the general 4xx case. It is called out because it is not really an error condition - "you may not have any of these slices" is a perfectly normal answer for this function to give, and a consumer has to handle it as an ordinary outcome rather than as a failure.

The same operation (with different parameters) happens in a few different situationas listed below :

during the mobility procedure (29.531-5.2.2.2.2)
during the PDU session establishment procedure (29.531-5.2.2.2.3)
during UE configuration update procedure (29.531-5.2.2.2.4)

Those three are not three variations on a theme - they are three genuinely different questions, and the specification gives each one its own request data type, which is why the list of structures further down this page contains three names that look almost identical :

Procedure	Request type used	What is really being asked
Registration / mobility	SliceInfoForRegistration	The UE has arrived. Which of the slices it wants may it actually use in this area, and what should it store for next time?
PDU session establishment	SliceInfoForPDUSession	The UE already has an allowed set. For this one session on this one slice, which network slice instance should serve it, and which NRF should be used to find the SMF?
UE configuration update	SliceInfoForUEConfigurationUpdate	Something changed on the network side. What should the UE's stored configuration now be, so the network can push it down?

The middle one is the one people tend to overlook. Getting an allowed slice at registration does not tell the network which instance of that slice will serve a particular session - a single S-NSSAI can be realised by several network slice instances - so the NSSF is asked a second, narrower question when the session is actually created.

Network Selection Related Information

Everything the NSSF deals with is a list of slice identifiers, so the structures in this section are almost entirely wrappers around one thing : the S-NSSAI, which names a single network slice, and the NSSAI, which is simply a list of them. Once you know that, eleven data types stops sounding like eleven concepts.

What makes them different from each other is not their contents but their standing - whose opinion each one represents. A slice identifier that the UE asked for, one that its subscription permits, one the network has authorised for use right now, and one it wants the UE to remember for next time are all the same kind of value, and they are all just an S-NSSAI. They are given separate type names because confusing them would be a serious error : granting a UE a slice because it asked for one, or because it is subscribed to one, would defeat the point of having an NSSF at all.

So the right way to read the list below is not top to bottom but as a small pipeline with inputs on one side and outputs on the other.

That list of eleven structures looks like a lot until you notice that most of the names are the same word with a different qualifier in front of it. Those qualifiers are the model, and reading them in the right order tells you how a slice decision is actually made :

   Requested    NSSAI    what the UE asked for            sent by the AMF in the query
        |
   Subscribed   S-NSSAI  what the subscription permits   comes from the UDM
        |
        |   the NSSF reconciles the two against what is deployed here,
        |   and may drop slices the NWDAF reports as overloaded
        v
   Allowed      NSSAI    what the UE may use now          returned in AuthorizedNetworkSliceInfo
   Configured   S-NSSAI  what the UE should remember      also returned, for future use

   and two supporting types :
   MappingOfSnssai  translates a serving-PLMN S-NSSAI to its home-PLMN equivalent, for roaming
   NsiInformation   names the actual slice instance and the NRF to use for it

Read that way, the eleven tables stop being a list and become a pipeline. Requested and Subscribed go in, Allowed and Configured come out, and everything else is either the input wrapper for one of the three procedures above or a supporting detail.

The distinction between Allowed and Configured is the one worth fixing in your mind, because the names do not make it obvious. Allowed is for right now, in this registration area - it is what the UE may use until something changes. Configured is what the UE should write down and keep, so that the next time it registers it asks for something sensible rather than starting from whatever it was given at the factory. One governs the present, the other seeds the future.

< 29.531 - Table 6.1.6.1-1: Nnssf_NSSelection specific Data Types >