N22 — AMF ⇔ NSSF (Nnssf_NSSelection reference point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N22 is an SBI (Service Based Interface), fundamentally different in protocol/transport from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• Explain that the substance of N22 is the service Nnssf_NSSelection (TS 29.531) provided by the NSSF.
• Explain the flow in which, when the AMF cannot resolve slice selection on its own, it requests slice selection assistance from the NSSF and obtains the Allowed NSSAI and appropriate AMF candidates (AMF Set).
• Explain that "reference point N22" and "service Nnssf_NSSelection" are two views of the same thing.
• Explain that 4G (EPC) has no standardized function equivalent to slice selection (DECOR/eDECOR is a precursor concept) (to be confirmed).

Prerequisites¶

The following are helpful to understand first:

• The positioning of SBA / SBI and HTTP/2 · TLS → Protocol dictionary
• The NFs at both ends of N22 → AMF / NSSF
• How network slicing · NSSAI · Allowed NSSAI are used → Network Slicing
• The concept of interfaces and reference points → Interface dictionary

Why — why it is needed¶

When a UE registers with the network, the terminal presents "which slice (S-NSSAI) it wants to use" as the Requested NSSAI. The AMF receives this, cross-references it with subscription information and network configuration, decides "the slices actually permitted for this terminal (Allowed NSSAI)," and further must judge "whether it (this AMF) is an appropriate AMF that can serve those slices."

However, slice configuration is information that spans the whole network (which slice is provided in which area, by which AMF Set, etc.), and there are cases where the AMF cannot fully resolve it alone. Therefore, a route to query NSSF, the authority on slice selection, "from this terminal's Requested NSSAI and subscription information, what are the Allowed NSSAI and the appropriate AMF?" is needed. This is N22. The AMF requests slice selection assistance from the NSSF over N22, and the NSSF returns the Allowed NSSAI or candidate AMF Set from the network configuration and subscription information. Without N22 (or without NSSF integration), the AMF can only perform slice selection within the range of local configuration and cannot perform network-scale fine-grained slice selection or appropriate AMF re-selection.

Analogy: N22 is a line by which the general reception (AMF) queries the information desk (NSSF) "to which specialized counter = slice should this customer be routed?" When the reception cannot fully judge with its own on-hand information, it asks the information desk over this dedicated line and, following the answer (the assignment of Allowed NSSAI or the counter in charge), routes the customer.

Overview¶

N22 is a reference point connecting AMF ⇔ NSSF. However, N22 is an SBI (Service Based Interface), which is decisively different from N2 (NGAP/SCTP) and N4 (PFCP/UDP). An SBI is a mechanism by which NFs call each other's services via Web APIs (HTTP), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

The substance of N22 is the service Nnssf_NSSelection (TS 29.531) provided by the NSSF. The AMF calls this service to obtain the Allowed NSSAI based on the Requested NSSAI, subscription information, and network configuration, or the information of the appropriate AMF Set/candidate AMF. The judgment logic of slice selection itself is consolidated on the NSSF side, and the AMF is responsible for the assistance request and applying the result.

Basic Concept — explanation for beginners¶

Let us compare N22 to an inquiry between the general reception and the information desk.

When your smartphone tries to register with the network, the registration-in-charge AMF acts. The UE presents its wish "I want to use this slice (S-NSSAI)" (Requested NSSAI). The AMF first tries to decide "the slices it may permit (Allowed NSSAI)" with its own on-hand information (local configuration · subscription information). However, because slice configuration involves network-wide information, there are cases where the AMF cannot decide alone.

At that time, the AMF queries the NSSF, the information desk for slice selection. The NSSF cross-references the network's slice configuration table with subscriber information and returns the Allowed NSSAI (the list of permitted slices) or, if necessary, the assignment "route that customer to this counter = another AMF" (candidate AMF Set). Following this answer, the AMF hands over processing to an appropriate AMF as the case may be (AMF re-selection).

This query to the NSSF is not a dedicated telephone line (a dedicated protocol like N2 or N4); it is more like throwing a request and getting a reply over an internal web system (HTTP). This is SBI (Service Based Interface) = the mechanism by which NFs converse via Web APIs (HTTP/2). Both request and response are exchanged in JSON, a format that is easy for humans to read.

Protocol / Transport¶

Architecture¶

This shows the context in which N22 connects AMF and NSSF, and the AMF also collaborates with the UE (Requested NSSAI) over N1 and with the UDM (subscribed NSSAI) over N8.

flowchart LR
  UE["UE"]
  AMF["AMF"]
  NSSF["NSSF (slice selection assistance)"]
  UDM["UDM"]

  UE -. "N1 (Requested NSSAI)" .- AMF
  AMF == "N22 (Nnssf_NSSelection)" ==> NSSF
  AMF -. "N8 (subscribed NSSAI)" .-> UDM

  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class AMF,NSSF ctrl;

How to read the diagram: The UE presents the Requested NSSAI (the wish for slices to use) to the AMF over N1. The AMF cross-references this with the subscribed NSSAI (slices that could be permitted) obtained from the UDM via N8 and tries to decide the Allowed NSSAI. When it cannot fully resolve locally, it requests slice selection assistance from the NSSF over the thick-line (==>) N22, and the NSSF returns the Allowed NSSAI or candidate AMF. Note that N22 is the line for "the query to decide slice selection."

Procedures used¶

N22 is mainly used within the Registration procedure when the AMF cannot resolve slice selection on its own.

• Requesting slice selection assistance (during Registration): When the AMF cross-references the UE's Requested NSSAI with subscription information (subscribed NSSAI) but cannot locally determine the Allowed NSSAI or the suitability of the serving AMF, the AMF requests assistance from the NSSF with Nnssf_NSSelection_Get (a conceptual operation; the name and method are to be confirmed).
• Obtaining and applying the result: The NSSF returns the Allowed NSSAI or an appropriate AMF Set/candidate AMF from the Requested NSSAI, subscription information, and network configuration. The AMF reflects this in the registration response to the UE and, if necessary, performs AMF re-selection (handing over processing to another AMF).
• Network slice availability collaboration (incidental): The NSSF may receive updates/notifications of the network's slice availability information from the AMF, etc., and use them for the selection judgment (details/direction are to be confirmed).

This NSSF integration is conditional and is not performed when the AMF can resolve slice selection on its own (configuration-dependent).

The detailed flow of the procedure (message sequence, conditions, various NSSAI IEs, triggers for AMF re-selection, etc.) is consolidated in the description of Network Slicing. Refer there for the details of slice selection.

Main Messages¶

Because N22 is an SBI, messages take the form of HTTP method + resource operation (RESTful operations, not a procedureCode like NGAP). The representative service operations are as follows.

The HTTP operation mapping is a conceptual arrangement: The "HTTP operation" in the table above is a mapping for understanding; the exact method, resource URI, and invocation direction of each operation follow the OpenAPI definition of TS 29.531. The strict method assignment and operation names are to be confirmed. For details of each message, refer to the Message dictionary.

Packet Analysis (Wireshark)¶

Because N22 is an SBI, it is observed on capture as HTTP/2 (an L4-dedicated protocol like NGAP/SCTP does not appear).

Decode highlights:

• N22 is encrypted with TLS. To see the contents (HTTP/2 headers and JSON body), a decryption key (TLS session keys, etc.) is required. Without the key, it is only visible as the encrypted payload of tls.
• If you can decrypt, you can identify the operation from the HTTP/2 headers (:method, the :path includes a resource path containing .../nnssf-nsselection/...) (the path notation is to be confirmed).
• The body is JSON (Requested NSSAI, Allowed NSSAI, candidate AMF information, etc.), stored in a human-readable structure.
• Unlike N2's NGAP (binary, over SCTP), the point of observation for N22 is that it is Web-like (HTTP/JSON). Do not use SCTP-specific filters (sctp.port, etc.).

Comparison with EPC¶

• In 4G: There is no standardized network slice selection (equivalent to NSSF/N22) function as in 5G. As a concept for directing a UE to a specific core network (a dedicated group of nodes), DECOR / eDECOR (Dedicated Core Network) existed as a precursor, but its mechanism differs from 5G slice selection (the correspondence is to be confirmed).
• In 5G: NSSF was introduced as a dedicated NF responsible for slice selection, and a framework in which the AMF requests assistance over N22 (Nnssf_NSSelection) when it cannot resolve slice selection on its own was standardized in an SBI-ized form (TS 29.531).

Network slicing is a concept introduced in earnest in 5G. While 4G's DECOR/eDECOR shares part of the idea in the sense of "directing to a dedicated core," it is safest to treat it as separate from 5G slice selection (NSSAI/NSSF/N22) (to be confirmed).

3GPP Specification¶

• 3GPP TS 29.531 — Nnssf_NSSelection service (network slice selection, N22). Individual clause numbers are to be confirmed
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical conventions / design principles · OpenAPI). Individual clause numbers are to be confirmed
• 3GPP TS 23.501 §4 — System architecture and reference points (definition of N22) ／ §5.15 — Network slicing (NSSAI/Allowed NSSAI, etc.). Clause numbers are to be confirmed
• 3GPP TS 33.501 — SBI security (TLS, etc.). Individual clause numbers are to be confirmed

Note (to be confirmed): That the substance of N22 is Nnssf_NSSelection (TS 29.531), that the common SBI framework is the TS 29.500/29.501 family, and that reference point N22 and service Nnssf are two views of the same collaboration, are general arrangements of the 3GPP architecture. The operation names, exact resource URIs, HTTP method assignments, concrete S-NSSAI/SST values, and clause sub-numbers of each service operation differ by Release, so they are individually to be confirmed.

Summary¶

• N22 is a reference point connecting AMF ⇔ NSSF, but being an SBI (Service Based Interface) it is fundamentally different from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• The protocol is HTTP/2 + JSON (RESTful) over TLS, and its substance is the NSSF service Nnssf_NSSelection (TS 29.531).
• When the AMF cannot resolve slice selection (determining Allowed NSSAI, serving-AMF suitability) on its own, it requests slice selection assistance from the NSSF over N22 and obtains the Allowed NSSAI or appropriate AMF Set/candidate AMF.
• Reference point N22 = service Nnssf_NSSelection are two views of the same AMF⇔NSSF collaboration (this site's way of thinking about the reference-point/service duality is common with NSSF).
• 4G has no function equivalent to standardized slice selection (DECOR/eDECOR is a precursor concept, to be confirmed); in 5G it was introduced in an SBI-ized form as NSSF/N22.

Next Step¶

• NSSF — the other side of N22. The hub of network slice selection assistance
• AMF — the NF that uses N22 to obtain the Allowed NSSAI · candidate AMF and, if necessary, performs AMF re-selection
• Network Slicing — details of NSSAI/Allowed NSSAI · slice selection procedure (consolidation point)
• N8 — the reference point where the AMF obtains subscription information such as the subscribed NSSAI from the UDM
• Interface dictionary — check reference points such as N11 and N12