2 NSSF Supported Services

This chapter includes information about the services supported by NSSF.

Note:

The performance and capacity of the NSSF system may vary based on the call model, Feature or Interface configuration, and underlying CNE and hardware environment.

2.1 Network Slice Selection Service

The Network Slice Selection service is identified by the service operation name, Nnssf_NSSelection. This service supports the GET request during the following procedures by UE:

Initial Registration:

When NSSF is able to find authorized network slice information for the requested network slice, the response includes a payload containing at least the Allowed NSSAI, target AMF Set, or the list of candidate AMF(s).

Following diagram illustrates the procedure of initial registration:


Initial Registration

  • The AMF sends a GET request to the NSSF.

    The AMF GET request must include:
    • Subscribed S-NSSAIs (with an indication if marked as default S-NSSAI)
    • Any Allowed NSSAI

    The query parameters may also contain:

    • Requested NSSAI
    • Mapping of requested NSSAI to configured NSSAI for the HPLMN
    • Mapping to the Configured NSSAI for the HPLMN
    • PLMN ID of the Subscription Permanent Identifier (SUPI)
    • UE's current Tracking Area
    • NF type of the NF service consumer
    • AMF ID
  • Based on the query parameters mentioned above, local configuration, and locally available information, including Radio Access Network (RAN) capabilities obtained by the current Tracking Area for the UE, NSSF does the following:
    • It selects the Network Slice instance(s) to serve the UE. When multiple Network Slice instances in the UE's Tracking Areas are able to serve a given S-NSSAI ( based on operator's configuration), NSSF selects one slice to serve the UE, or defer the selection of the Network Slice instance until a NF or service within the Network Slice instance needs to be selected.
    • It determines the target AMF set to be used to serve the UE or based on configuration, the list of candidate AMF(s), possibly after querying the NRF.
    • The AuthorizedNetworkSliceInfo response for UE-registration must mandatorily include both AllowedNSSAI and Candidate AMF list or target amfset. The AllowedNSSAI is computed by taking into account the input request and applying operator policies as specified in 3GPP Spec 29.531 Release 15.5.
    • NSSF calculates ConfiguredNSSAI by determining the intersection of S-NSSAI(s) in ConfiguredNSSAI for the PLMN (operator configured) and S-NSSAI(s) in SubscribedNSSAI (from the message indicating SubscribedNSSAI by the UE).
    • It determines the Allowed NSSAI(s) for the applicable Access Type(s), taking also into account the availability of the Network Slice instances that are able to serve the S-NSSAI(s) in the Allowed NSSAI and the current UE's tracking areas.
    • Based on operator configuration, the NSSF determines the NRF(s) to be used to select NFs or services within the selected Network Slice instance(s).
  • When the NSSF locates the authorized network slice information for the requested network, NSSF sends Discovery Request for AMF to NRF.
  • The NRF responds with the list of all candidate AMFs to NSSF.
  • The NSSF returns to the current AMF the Allowed NSSAI for the applicable Access Type(s), the target AMF Set, or the list of candidate AMF(s) based on configuration.
    • NSSF returns the NRF(s) to be used to select NFs/services within the selected Network Slice instance(s) and the NRF to be used to determine the list of candidate AMF(s) from the AMF Set.
    • NSSF returns NSI ID(s) to be associated to the Network Slice instance(s) corresponding to certain S-NSSAIs.
    • NSSF also returns the rejected S-NSSAI(s) and the Configured NSSAI for the Serving PLMN.
  • Candidate AMF selection by NSSF:
    • In response to the Initial Registration request, NSSF responds with AMFs that support the Authorized NSSAI in the specified TAI. NSSF prioritizes runtime data, and if a suitable match is not found, it falls back to operator-configured data. Runtime data consists of NsAvailabilityData sent by the AMF.
    • This approach is chosen to ensure that NSSF responds with consideration of dynamic data. In scenarios where sufficient data is not present (for example, AMFs have not sent an Availability Update), NSSF relies on operator-configured data.
    • This ensures that a response is provided when NSSF is just initialized and does not have Availability Data. The recommendation is that AMFs should have a configuration to update NsAvailability information with NSSF, so that NSSF can respond based on dynamic data.

PDU Session Establishment:

When the NSSF receives a PDU-Session establishment request from the NF consumer, it determines the network slice that can serve the requested S-NSSAI based on the user configured policies, and responds with the URL of the NRF that manages the Slice and Slice ID of the matching Network slice computed.

The PDU session establishment in a Network Slice to a Data Network (DN) allows data transmission in a Network Slice. A PDU Session is associated with a S-NSSAI and a Data Network Name (DNN). Following diagram illustrates the procedure of PDU Session Establishment:

Figure 2-1 PDU Session Establishment

PDU Session Establishment

The following is performed for PDU Session Establishment:

  • If the AMF is not able to determine the appropriate NRF to query for the S-NSSAI provided by the UE, the AMF sends a GET request to the NSSF. The AMF queries the NSSF with this specific S-NSSAI, the NF type of the NF service consumer, Requester ID, PLMN ID of the SUPI, and the location information.
  • The NSSF determines and returns the appropriate NRF to be used for selecting NFs or services within the selected Network Slice instance. The NSSF may also return an NSI ID identifying the Network Slice instance to use for this S-NSSAI.

    When a PDU Session for a given S-NSSAI is established using a specific Network Slice instance, the cloud native provides the RAN with S-NSSAI corresponding to this Network Slice instance, which enables the RAN to perform access specific functions.

UE-Config-Update:

When the UDM updates the Subscribed S-NSSAI(s) to the serving AMF, based on configuration in the AMF, the NSSF determines the mapping of the Configured NSSAI for the serving PLMN and Allowed NSSAI to the Subscribed S-NSSAI(s).

Following diagram illustrates the procedure of UE-Config-Update:

Figure 2-2 UE-Config-Update

UE-Config-Update

The following is performed for UE-Config-Update:

  • The AMF sends a UE-Config-Update (GET) request to NSSF. NSSF checks and validates the Subscribed S-NSSAI(s), Requested S-NSSAI(s), PLMN ID of the SUPI, TAI, NF type, and NF instance ID. If message is valid, NSSF searches for Allowed S-NSSAI list based on policy configuration and input parameters.
  • NSSF responds with "200 OK with AuthorizedNetworkSliceInfo" if it finds a match.
  • The AuthorizedNetworkSliceInfo response for UE-Config-Update must mandatorily include both AllowedNSSAI and ConfiguredNSSAI. The AllowedNSSAI is computed by taking into account the input request and applying operator policies as specified in 3GPP Spec 29.531 Release 15.5.
  • NSSF calculates ConfiguredNSSAI by determining the intersection of S-NSSAI(s) in ConfiguredNSSAI for the PLMN (operator configured) and S-NSSAI(s) in SubscribedNSSAI (from the message indicating SubscribedNSSAI by the UE).
  • NSSF responds with error code if it finds incorrect parameter validation.

2.2 NSSAI Availability Service

The NSSAI Availability service is identified by the service name, Nnssf_NSSAIAvailability. The following operations are defined for this service:
  • Update Service Operation
  • Subscribe Service Operation
  • Unsubscribe Service Operation
  • Notify Service Operation
  • Delete Service Operation
  1. Update Service Operation

    The AMF uses this operation to update the NSSF with the supported S-NSSAI(s) on a per TA basis and to get informed on the S-NSSAIs available per TA (unrestricted) and the restricted S-NSSAI(s) per PLMN in that TA in the serving PLMN of the UE.

    Figure 2-3 Update the S-NSSAIs the AMF supports per TA

    Update the S-NSSAIs the AMF supports per TA
    • The NF service consumer (for example, AMF) sends a PUT request to NSSF with NSSAI availability information, identified by {nfId}, using NssaiAvailabilityInfo.

      The message contains a list of S-NSSAIs supported by the AMF on a per-TA basis.

    • NSSF checks (from operator configuration, specifically the PLMN Config managed object). If any S-NSSAI supported by the AMF is not configured (not part of ConfiguredNSSAI), NSSF responds with 403 Forbidden.

      Since NSSF is the source for slices and S-NSSAIs in the network, if an NF (AMF) claims that it supports an S-NSSAI not known to NSSF (i.e., not present in ConfiguredNSSAI for the PLMN), NSSF responds with 403 Forbidden, as the NF (AMF in this scenario) is forbidden to support an S-NSSAI not configured for that PLMN.

    • NSSF checks (from operator system options configuration) that PLMNs are preconfigured in the NSSF System Option. If any PLMN is found to be not configured, NSSF responds with 403 Forbidden.

      In case an NF (AMF), via NssaiAvailabilityData, claims that it supports a PLMN not known to NSSF (Central NF), NSSF rejects the request with 403 Forbidden, since requests for unknown PLMNs cannot be accepted.

    • NSSF checks (from operator configuration) if the S-NSSAIs are authorized in the TAI and responds with the S-NSSAIs that are authorized by NSSF and supported by the AMF for each TAI.
    • If none of the S-NSSAIs in the request are authorized by NSSF (i.e., if all supported S-NSSAIs from the AMF in all TAIs are configured but restricted either at the PLMN level or at the TAI level), NSSF responds with a 204 No Content message.
    • NSSF supports HTTP PATCH for NssaiAvailability update.
    • Upon receiving a PUT or PATCH message, NSSF stores or updates the list in the session database.
    • In scenarios where all TAI-S-NSSAIs supported by the AMF are configured and some or all S-NSSAIs are authorized, NSSF responds with 200 OK and AuthorizedNssaiAvailabilityData (the TAI-S-NSSAI mapping authorized by NSSF).
  2. Subscribe Service Operation

    The Subscribe operation is used by NF Service Consumer (AMF) to get the notifications for any change in NSSAI availability information.

    Figure 2-4 Subscription creation

    Subscription creation
    • AMF sends a POST request to NSSF with a notification URL and a list of TAIs as JSON body.
    • NSSF stores the subscription request and responds with the list of authorized S-NSSAI(s) per TAI in the request.
    • NSSF also returns a subscription-id and expiry (duration up to which NSSF sends notifications for any change in the status of S-NSSAI for subscribed TAI(s)).
    • The expiry duration is optional:
      • If not provided, NSSF sets it to maxExpiryDuration (Helm configuration)
      • If greater than maxExpiryDuration, NSSF resets it to maxExpiryDuration
      • If less than minExpiryDuration (Helm parameter), the request is rejected
      • If a remove operation is received on the Expires header, NSSF refreshes the subscription to ensure continuity and avoid rejection caused by unexpected or unwarranted NF consumer behavior
    • In case the SUMOD feature is enabled at NSSF and the request comes with supportedFeatures with SUMOD bit as true, NSSF accepts a PATCH request on the subscription.
  3. Unsubscribe Service Operation

    The Unsubscribe service operation is used by AMF to unsubscribe to a notification of any previously subscribed changes to the NSSAI availability information.

    Figure 2-5 Unsubscribe a Subscription

    Unsubscribe a Subscription
    • AMF sends a DELETE request to NSSF with subscription-id.
    • NSSF checks for an active subscription with the ID and, if found, deletes the subscription and responds with the message 204.
    • If a subscription is not found with subscription-id, NSSF responds with 404 Not Found.
  4. Notify Service Operation
    The Notify service operation is used by the NSSF to update the AMF with any change in status, on a per TA basis, of the S-NSSAIs available per TA (unrestricted) and the S-NSSAIs restricted per PLMN in that TA in the serving PLMN of the UE.

    Figure 2-6 Update the AMF with any S-NSSAI restricted per TA

    Update the AMF with any S-NSSAI restricted per TA
    • NSSF sends notification to subscribed AMF when one or more of the following conditions are true
    • If auto population of content based on AMF update is enabled:
      • An S-NSSAI has been barred or unbarred at PLMN level, for PLMNs associated with the subscribed TAIs
      • An S-NSSAI has been barred or unbarred for one or more subscribed TAIs
    • If auto population of content based on AMF update is disabled:
      • An S-NSSAI has been added to or removed from the supported S-NSSAI for one or more subscribed TAIs
  5. Delete Service Operation

    The AMF uses this operation to delete the NSSAI Availability information stored for that AMF in the NSSF.

    Figure 2-7 Delete the NSSAI Availability Information at NSSF

    Delete the NSSAI Availability Information at NSSF
    • The NF service consumer (For example: AMF) sends a DELETE request to NSSF with nfId.
    • The NSSF searches in session database for the NSAvailability data corresponding to nfId and deletes them.