When you modify subscriber details, the NAP server, LDAP server, and PCF or PCRF perform the following operations:

NAP request termination on the PCRF

1. The LDAP server updates the NAP server with the modified details.

2. The NAP server broadcasts the Subscriber Change Notification message to the connected PCRF server. The message contains the unique identifier, and MSISDN or IMSI ID.

3. After receiving the message, the PCRF sends an acknowledgment to NAP. The PCRF then searches for the local session.

4. If the subscriber session is active on the PCRF, then PCRF requests the updated subscriber information from SPR or LDAP server. Depending upon the information it receives, PCRF updates the local session with the updated subscriber information and sends a Re-Auth-Request (RAR) for the Policy and Charging Rules Function (PCEF). For example, if PCRF identifies a session for the notification that contains the specified MSISDN in the PCRF then it triggers a Gx-RAR for the subscriber sessions.

5. If PCRF does not find the subscriber session locally, then the Policy Server forwards the Subscriber Change Notification to PCF. After receiving notification, PCF seeks the session locally and takes the appropriate action.

NAP request termination on PCF

When profile changes occur in NAP, it signifies that certain policies are added or modified. In this situation, the PCF performs the following:

1. Upon receiving a notification from NAP, the PCF initiates a requery or refresh request.

2. The PCF sends an N28 Subscribe Update request seeking the details of the policies that are added or updated.

3. After receiving the updates, the PCF reevaluates the policies to determine the updated policies and sends the Update_Notify message to SMF (over the N7 interface).

The Policy Server manages the 4G and 5G subscriber information in separate modules, which indicates that the PCRF continues to store the 4G-specific information, and PCF preserves the 5G-specific details. When the Policy Server receives a request seeking subscriber information, the LDAP with other components performs the following tasks:

1. The LDAP queries the MongoDB or Subscriber Profile Repository (SPR) by sending the "Get Subscriber Information" message.

2. After receiving the query, the Policy Server searches the subscriber information in the local MongoDB instance.

3. After receiving the search query, the Policy Server searches the subscriber information in the local MongoDB instance.

4. If the Policy Server discovers the subscriber information on PCRF, it sends the details to LDAP in the defined format. If the PCRF does not find the information, it forwards the request to PCF for further processing.

5. When PCF detects the information, it notifies PCRF with the subscriber information, which the PCRF forwards to the LDAP in the specified format.

This section includes the following call flows.

• NAP Notification Call Flow

• LDAP Server Initialization Call Flow

This section describes how to configure the gRPC endpoint to route the messages for PCF.

To set up the endpoint for gRPC, use the following configuration:

config 
  engine engine_group_name  
   grpc externalIPs external_ip 
    port port_number 
    end  

For example,

engine magenta grpc externalIPs [192.0.2.18] port 8080 

NOTES:

• engine engine_group_name – Specifies the engine group name.

• grpc externalIPs external_ip – Specifies the gRPC external IP address.

• port port_number – Specifies the port number.

This section describes how to configure the forwarding capability.

For High Availability (HA) or Geographic Redundancy (GR) environments, ensure that the PCF Engine can access the Policy Server VMs. You can configure the capability responsible for routing the notification and queries by adding the following parameters to the qns.conf file.

The following table describes the application parameters.

This section describes the prerequisites that must be met for PCF-NAP communication.

For PCF-NAP interaction, make sure that the following configurations are available in your environment:

• N7 interface must be configured. For information on configuring the N7 interface, see Configuration Support for the N7 and N28 Interface.

• LDAP must be configured to operate with PCF. For information on configuring the LDAP, see Configuring PCF to use LDAP.

This section describes how to configure the unified API through the PCF Ops Center.

PCF receive NAP requests to requery the LDAP and reevaluate policies after receiving notification about profile change from NAP, so the new policies are applied. PCF receives the NAP requests through the unified API ingress endpoint.

To configure the unified API, use the following configuration in the Policy Ops Center console:

config 
  api unified          
    engine-group engine_group_name 
    external-port external_ip 
    externalIPs external_ip 
    end 

NOTES:

• api unified – Enter the unified API configuration mode.

• engine-group engine_group_name – Specifies the PCF engine's group name.

• external-port port_number – This is an optional parameter, and is required when you want the service to be accessed using an external IP instead of an Ingress endpoint. Specifies the external port number to expose the unified API endpoint.

• externalIPs external_ip – This is an optional parameter, and is required when you want the service to be accessed using an external IP instead of an Ingress endpoint. Specifies the IP address for the external endpoint.

This section describes how to set a limit on the number of NAP requests for PCF to process.

To configure the maximum number NAP requests TPS per PCF Engine deployment, use the following configuration in the Policy Ops Center console:

config 
  engine engine_name 
     properties broadcast.tps value tps 
     end   

• engine engine_name – Specifies the engine name.

• properties broadcast.tps value tps – Specifies the maximum number of NAP requests TPS that each PCF Engine must process. The default value is 20.

This section describes how to configure the LDAP server endpoint and the associated filter mappings.

Based on the LDAP endpoint configuration, the LDAP endpoint authenticates itself with PCF to retrieve the subscriber details through the search query.

To configure the LDAP server endpoint, use the following configuration in the Policy Ops Center console:

config 
  ldap-server-endpoint 
  connect   
    bind-ip ip_address     
      port port_number 
    binddn username  
      password password 
    request-timeout timeout 
      replica replica_count 
    max-transactions maximum_transaction 
  health-check-attributes attribute_name 
    valueattribute_value 
  health-check-filter name attribute_name  
    valueattribute_value 
  ldap-clients client_name   
    passwordpassword 
  input-mapping filter_from_client 
  internal-lookup-key [ IMSI | IP_ADDRESS | MSISDN ] 
  output-mapping output_attribute_name   
    input session_attribute_name   
    end   

• ldap-server-endpoint – Enters the LDAP server endpoint configuration mode.

• connect – Enters the LDAP connection configuration.

• bind-ip ip_address port port_number request-timeout timeout – Specifies the external IP address and port number to which the LDAP client can connect to externally. The default port number is 9389.

• binddn username password password – Specifies the user DN, for example: cn=manager, ou=account, so=profile, and password for connecting to the LDAP server.

• request-timeout timeout_duration – Specifies the duration in milliseconds after which the request expires. The request awaits a response from the PCF engine. The default timeout value is 2000.

• replica replica_count – Specifies the replica count for the LDAP server.

• max-transactions maximum_transaction – Specifies the maximum number of transactions per second that each connection must process. The default value is 200.

• health-check-attributes attribute_name value attribute_value – Specifies the attribute name and value that the client receives as a response to the health check request.

• health-check-filter name attribute_name value attribute_value – Specifies the attribute name and value that distinguishes the health check request.

• ldap-clients client_name password password – Specifies the configuration that PCF uses to configure multiple client authentication parameters.

• input-mapping filter_from_client – Indicates the configuration to map the filter ID received from LDAP client and the internal-lookup-key. The accepted value must contain text string. For example, IMSI, MSISDN, framedIp, framedIpv6Prefix. You can configure the input mapping separately for frameIP, MSISDN, IMSI, and framedIpv6Prefix.

• internal-lookup-key [ IMSI | IP_ADDRESS | MSISDN ] – Configures the internal lookup key.

• output-mapping output_attribute_name input session_attribute_name – Indicates the table that is used to defile the response attributes for the client. The response attribute name is mapped to the internal CPS session attributes for added flexibility.

  Note	PCF does not process the requests for which the output-mapping configuration is missing. The response attributes contain only those values that are configured in the output mapping as input key.

  You can configure multiple supported keys only if they are available in the PCF session. The input keys can be duplicate but not the output values that you cannot configure two output-mappings with the same values.

This section describes how to set the limit on the number of LDAP search requests for PCF to process.

To configure the maximum number LDAP requests TPS per replica, use the following configuration in the Policy Ops Center console:

config 
  ldap-server-endpoint connect  
  max-transactions max_tps 
  end 

NOTES:

• max-transactions max_tps – Specifies the maximum number of LDAP requests TPS that each replica must process. The default value is 200.