3 NSSF Architecture

NSSF comprises of various microservices deployed in Kubernetes based Cloud Native Environment (CNE), for example: Oracle Communications Cloud Native Core, Cloud Native Environment (CNE). CNE provides some common services like logs, metrics data collection, analysis, graphs, and charts visualization, etc. The microservices integrate with these common services and provide them with the necessary data.

The following diagram describes the overall architecture of the NSSF:


NSSF Architecture

The architecture has the following components:

  1. NSSelection 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:

    1. Initial Registration:

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

      • 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 other locally available information including Radio Access Network (RAN) capabilities made available by the current Tracking Area for the UE, the 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, the NSSF may select one of them to serve the UE, or the NSSF may 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 mandatory 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 in the current UE's tracking areas.
        • Based on operator configuration, the NSSF may determine the NRF(s) to be used to select NFs or services within the selected Network Slice instance(s).
      • When the NSSF is able to find authorized network slice information for the requested network, NSSF sends Discovery Request for AMF to NRF.
      • The NRF responds with list of 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, based on configuration, the list of candidate AMF(s).
        • 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.
    2. PDU Session Establishment:

      When the NSSF receives PDU-Session establishment request from the NF consumer, NSSF determines the network slice which can serve the requested S-NSSAI, based on the user configured policies, and responds with the URL of NRF which manages to the Slice and/or 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).

      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 to select 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 to the RAN the S-NSSAI corresponding to this Network Slice instance to enable the RAN to perform access specific functions.

    3. UE-Config-Update:

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

      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 in case NSSF 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 in case of incorrect parameter validation.
  2. NS Availability Service

    This microservice supports NSAvailability service of NSSF as per 29.531. This microservice stores subscriptions and AMF data.

    The NSSAI Availability service is identified by the service name, Nnssf_NSSAIAvailability. For the Nnssf_NSSAIAvailability service the following service operations are defined:

    • Update Service Operation
    • Subscribe Service Operation
    • Unsubscribe Service Operation
    • Delete Service Operation
  3. NS Subscription Service

    This micro-service sends notifications based on Subscribed Events through NSAvailability.

    Notifications are sent to Subscribed AMFs to signify changes in Authorization state with respect to S-NSSAIs on TAI as per 3GPP TS 29.531

    The Notify 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.

    • NSSF sends notification to subscribed AMF when one or more following conditions are true:
      • There is change at Grant rules on S-NSSAI corresponding to one or more of TAIs subscribed by AMF.
      • An S-NSSAI has been added or deleted for one or more of TAIs subscribed by AMF.
  4. NS Auditor Service

    This microservice is a timed auditor, which removes stale records from NSSF.

    What is a stale record?

    In georedundant scenarios, tables in State Database (stateDB) maintain a column siteId, which identifies owner site of that record. There could be georedundancy scenarios when similar records can be owned by two sites, where the older record is termed as the stale record.

    NS Auditor is used in georedundancy scenarios where subscription is owned by one site, but the Patch is received on other site. This leads to creation of two records for same subscription owned by each site. Ns-Auditor detects this and removes the old stale record to ensure subscription is owned at a singe site only.

    For example:

    • Site-1 receives Subscription POST.
    • Site-1 creates a record, rec-1, for subscription with owner as site-1.
    • If AMF gets disconnected with the site-1, site-1 goes down, or SCP makes a routing decision based on congestion, the subscription PATCH is received on site-2.
    • Site-2 creates a new record, rec-2, for subscription with new owner as site-2.
    • Now, rec-2 for site-2 is same as rec-1 for site1.
    • NS Auditor detects this and deletes rec-1.
    • Site-2 becomes the owner of the subscription, and receives the latest patch.
  5. NS Configuration Service

    This microservice is responsible for configuring policy rules. It implements a REST messaging server that receives configuration HTTP messages, validates and stores the configuration in the database.

  6. NRF Client Manegement
    This microservice registers with the NRF and sends periodic heartbeats, also maintains subscriptions with NRF for AMF sets.
    • NRF Registration and Heartbeat: Once NSSF is registered with NRF, NSSF contacts the NRF periodically. First the registration profile is configured using helm. Then the performance service calculates load and capacity of NF. NS registration requests the load and capacity from performance service and sends it to NRF with heartbeat.
    • NRF Subscription: NSSF subscribes to NRF for AMF based on the Target AMF Set and Region ID for registration and deregistration and load update.
  7. NRF Client Discovery Microservice

    This microservice plays a crucial role in managing discovery requests within a network. Its primary function is to handle on-demand service discovery and efficiently manage interactions with the Network Repository Function (NRF).

    • Discovery: Performs service discoveries as required. When a service or function needs to be identified or connected, the discovery component initiates the process.
    • Handling Requests: Handles requests directed towards the NRF, which is responsible for registering and providing information on network functions and their services.
    • Response Processing: Once a response is received from the NRF, the microservice processes this information and prepares it for the requesting service.
  8. App-Info: This microservice monitors application (microservice) health and status.
  9. Perf-Info: This microservice monitors application (microservice) capacity and load status.
  10. Configuration Server: This service performs the database abstraction for storage and retrieval of NSSF configuration.
  11. Alternate Route Service: Alternate Route Service (ARS) is a microservice designed to efficiently find and provide alternate network routes. It employs a tiered approach, beginning with a fast cache lookup. If the desired route isn't cached or the cached entry is outdated, ARS checks predefined static mappings. It then queries DNS-SRV (if configured), updates its cache, and returns a response indicating success or failure. On success, ARS provides a list of alternate FQDNs (Fully Qualified Domain Names). These alternate routes can be configured either statically (using Helm charts) or dynamically (through DNS-SRV). Essentially, ARS prioritizes speed and efficiency in finding alternate routes by leveraging caching and fallback mechanisms.
  12. Ingress Gateway Service

    This microservice is an entry point for accessing NSSF supported service operations and provides the functionality of an OAuth validator.

  13. Egress Gateway Service

    This microservice is responsible to route NSSF initiated egress messages to other NFs.

Note:

For more information on Ingress and Egress Gateway, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide.