Tools

Demonstrate NRF Management Procedures

1. Network Repository Function (NRF)

1.1 What is NRF?

The NRF acts as the central directory or information hub of the entire 5G Core Network. It maintains a complete registry of all active Network Functions and their capabilities.

1.2 Information Stored by NRF:

  1. NF Identity and NF Type (AMF, SMF, PCF, UDM, AUSF, etc.)
  2. Instance ID (UUID) - Globally unique identifier
  3. IPv4/IPv6 addresses and Port numbers
  4. Supported services and API versions
  5. Heartbeat timer value
  6. Operational status (REGISTERED / UNAVAILABLE)
NRF Central Registry Architecture

Fig 1: NRF Central Registry Architecture

1.3 Why NRF is Critical:

Without NRF, each NF would need manual configuration with addresses of every other NF, which is impossible in cloud-native 5G systems where NFs:

  1. Scale up or down dynamically
  2. Restart due to failures
  3. Relocate across cloud nodes
  4. Launch multiple instances based on load

The NRF makes 5G Core flexible, dynamic, self-adapting, intelligent, and easy to scale.

2. Network Function Registration

Registration is the first and most essential procedure when any Network Function becomes operational. The NF must announce its availability to the NRF so other NFs can discover and communicate with it.

2.1 Registration Process:

Step a: NF Sends Registration Request

  • HTTP Method: PUT
  • Endpoint: /nnrf-nfm/v1/nf-instances/{nfInstanceId}
  • Protocol: HTTP/2 over TCP
  • Content Type: JSON

Step b: NF Profile (JSON Payload)

The request contains a detailed NF Profile with the following fields:

Field Description Example
nfInstanceId Unique UUID for this NF instance 4947a69a-f61b-4bc1-b9da-47c9c5d14b64
nfType Type of Network Function AMF, SMF, PCF, UDM, AUSF
nfStatus Current operational state REGISTERED
ipv4Addresses IP address of the NF 127.0.0.5 [NF_ip_address]
port Service port number 7777, 8080
nfServices List of supported services/APIs namf-comm, nsmf-pdusession
allowedNfTypes Which NFs can consume this service [SMF, UDM]
heartBeatTimer Periodic check interval (seconds) 10
capacity Load handling capability 100
priority Selection priority 1

Step c: NRF Validation

When NRF receives the registration request, it:

  1. Checks if nfInstanceId is unique - Rejects if duplicate exists
  2. Validates NF profile structure - Ensures all mandatory fields are present
  3. Verifies service endpoint information - Checks IP/port validity
  4. Detects conflicts - Identifies any inconsistencies

Step d: NRF Response

  • Success Response: 201 Created
    • NRF stores the profile in its internal repository
    • Returns Location header indicating where profile is stored
    • Confirms heartbeat timer value
  • Failure Response: 400 Bad Request or other error codes
    1. Registration rejected due to invalid data or conflicts
NF Registration Complete Flow

Fig 2: NF Registration Complete Flow

2.2 Example: AMF Registration:

Key Registration Details:

  1. NF Type: AMF (Access and Mobility Management Function)
  2. Status: REGISTERED
  3. IP Address: 192.168.70.135
  4. Supported Service: namf-comm (Communication service)
  5. Allowed NF Types: SMF (Session Management can use AMF services)
  6. Heartbeat Timer: 10 seconds

What Happens:

  1. AMF starts and prepares its NF profile
  2. Sends PUT request to NRF with instance ID, service list, API versions, endpoints
  3. NRF processes and validates the request
  4. NRF responds with 201 Created and assigns heartbeat timer
  5. AMF must now send periodic heartbeats every 10 seconds to stay active

2.3 Example: UDM Registration:

Key Registration Details:

  1. NF Type: UDM (Unified Data Management)
  2. Multiple Services Registered:
    1. nudm-ueau (User Authentication)
    2. nudm-uecm (UE Context Management)
    3. nudm-sdm (Subscription Data Management)

What Happens:

  1. UDM has a richer profile since it provides multiple services
  2. Sends large JSON payload describing every service instance
  3. Includes API version, network address, supported consumers for each service
  4. NRF accepts registration and responds with 201 Created
  5. Now AMF, SMF, and AUSF can discover UDM services when needed

3. Network Function Discovery

3.1 What is Discovery?

Discovery is the mechanism that allows NFs to find and connect with other NFs dynamically without manual configuration. It works like a search operation in a service directory.

3.2 Discovery Process:

Step a: NF Needs Another Service

Example Scenario:

  • AMF needs to establish a PDU session for a user
  • Must contact Session Management Function (SMF)
  • But 5G Core is dynamic - multiple SMF instances may be running
  • AMF doesn't know their IP addresses or locations

Step b: NF Sends Discovery Request

  • HTTP Method: GET
  • Endpoint: /nnrf-disc/v1/nf-instances?nf-type=SMF
  • Query Parameters:
    • nf-type - Type of NF needed (SMF, PCF, UDM, etc.)
    • service-names - Specific service required
    • target-nf-instance-id - If looking for specific instance
    • requester-nf-instance-id - Who is requesting

Step c: NRF Searches Internal Database

NRF queries its registry for:

  • All NFs matching the requested type
  • Currently REGISTERED status
  • Services matching the requirement
  • Compatible API versions

Step d: NRF Returns Discovery Response

Success Response: 200 OK with JSON array containing:

{
            "nfInstances": [
              {
                "nfInstanceId": "uuid-smf-1",
                "nfType": "SMF",
                "nfStatus": "REGISTERED",
                "ipv4Addresses": ["192.168.1.10"],
                "nfServices": [{
                  "serviceInstanceId": "service-1",
                  "serviceName": "nsmf-pdusession",
                  "versions": [{"apiVersionInUri": "v1"}],
                  "scheme": "http",
                  "fqdn": "smf1.5gc.mnc001.mcc001.3gppnetwork.org",
                  "ipEndPoints": [{
                    "ipv4Address": "192.168.1.10",
                    "port": 8080
                  }]
                }],
                "capacity": 100,
                "load": 35,
                "priority": 1
              }
            ]
          }

Each discovered NF includes:

  • IP addresses and service endpoints
  • NF instance IDs - For direct communication
  • Version compatibility - API version information
  • Availability status - REGISTERED/UNAVAILABLE
  • Capacity and load - For load balancing decisions
  • Priority - For selection preference
NF Discovery Process

Fig 3: NF Discovery Process

3.3 Why Discovery is Important:

  • Removes manual configuration - No hardcoded IP addresses needed
  • Supports dynamic environments - New instances appear/disappear automatically
  • Enables load balancing - NRF returns multiple instances with load info
  • Ensures connectivity - Always connects to active, available NFs
  • Version compatibility - Finds NFs with compatible API versions

4. Network Function Deregistration

4.1 What is Deregistration?

Deregistration is the final step in the lifecycle of any Network Function. It removes the NF from the NRF registry when the NF is no longer available.

4.2 When Deregistration Happens:

  • NF is being stopped for maintenance
  • NF is being replaced with new version
  • NF is being scaled down (reduced instances)
  • NF is being relocated to different server
  • NF is shutting down gracefully

4.3 Type 1: Manual/Graceful Deregistration

Process:

  1. NF Sends Deregistration Request
    • HTTP Method: DELETE
    • Endpoint: /nnrf-nfm/v1/nf-instances/{nfInstanceId}
    • Contains the specific NF instance ID to remove
  2. NRF Processes Request
    • Locates the NF profile in registry
    • Validates the deregistration request
    • Removes the NF profile from database
  3. NRF Response:
    • Success: 204 No Content - Profile deleted successfully
    • Error: 404 Not Found - NF instance doesn't exist

Why Manual Deregistration Matters:

  • Ensures clean shutdown - Other NFs immediately know this NF is offline
  • Prevents failed connections - No other NF will try to contact removed service
  • Maintains registry accuracy - Database stays current and reliable
  • Avoids timeout delays - Immediate removal instead of waiting for heartbeat expiry

4.4 Type 2: Automatic Deregistration (Heartbeat-Based)

The Problem: NFs may crash unexpectedly due to:

  • Software failures or bugs
  • Network errors or disconnection
  • Power failure or hardware issues
  • Container shutdown or orchestration events
  • Operating system crashes

In these cases, the NF cannot send a DELETE request.

The Solution: Heartbeat Mechanism

How It Works:

  1. During Registration:
    • NRF assigns a heartbeat timer (e.g., 10 seconds)
    • NF must send periodic heartbeat updates before timer expires
  2. Heartbeat Update:
    • HTTP Method: PUT or PATCH
    • Endpoint: /nnrf-nfm/v1/nf-instances/{nfInstanceId}
    • Minimal payload - just confirms "I'm still alive"
    • Resets the heartbeat timer
  3. Heartbeat Monitoring:
    • NRF tracks last heartbeat time for each NF
    • If no heartbeat received within timer period:
      • NRF marks NF status as "UNAVAILABLE"
      • After additional grace period, NRF removes the profile
      • Prevents stale records in database
  4. Automatic Cleanup:
    • NRF runs periodic cleanup tasks
    • Identifies expired NF instances
    • Removes them from registry automatically
    • Logs the removal event
Deregistration Types - Manual vs Automatic

Fig 4: Deregistration Types - Manual vs Automatic

Benefits of Heartbeat Mechanism:

  • Self-healing registry - Automatically removes dead NFs
  • No manual intervention - System maintains itself
  • Prevents connection failures - Discovery won't return dead NFs
  • Handles edge cases - Works even when NF crashes unexpectedly