Patent Description:
In telecommunications networks, a service endpoint is an address on a network node that uniquely identifies an entity that provides service to service consumers. The service endpoint can include an Internet protocol (IP) address or a combination of IP address and transport layer port number, which is also referred to as an IP endpoint.

In <NUM> telecommunications networks, the network node that provides service is referred to as a producer network function (NF). A network node that consumes services is referred to as a consumer NF. A network function can be both a producer NF and a consumer NF depending on whether it is consuming or providing service.

A given producer NF may have many service endpoints. Producer NFs register with a network function repository function (NRF). The NRF maintains an NF profile of available NF instances and their supported services. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is a service communication proxy (SCP). The SCP subscribes with the NRF and obtains reachability and service profile information regarding producer NF service instances. Consumer NFs connect to the service communications proxy, and the service communications proxy load balances traffic among producer NF service instances that provide the required service or directly routes the traffic to the destined producer NF.

One problem with the existing 3GPP service architecture is PDU session binding information maintained in a PDU session binding database at a binding support function (BSF) may not be updated when the status of a policy control function (PCF) associated with the PDU session binding changes. For example, after a user equipment (UE) device registers with the network, the UE creates a PDU session in order to exchange data with the network. As part of the PDU session creation process, a policy control function (PCF) is assigned to the session to generate policy rules for the session to control quality of service and charging for the session. The PCF assigned to the session registers with a binding support function (BSF), and the BSF creates a binding record for the session in its database. NF service consumers seeking to discover the PDU session binding for a UE do so by querying the BSF using a discovery API provided by the BSF.

One problem that can occur when the NF service consumers query the BSF is that the PDU session binding records maintained by the BSF may not reflect the current operational status of the PCFs. For example, after a binding record is created, the operational status of a PCF associated with the binding record may change, e.g., due to the PCF going out of service. A BSF consumer NF may seek to discover a PDU session binding in order to provide service to a UE. However, if the PDU session binding information does not reflect the current operational status of the PCF, the NF may receive PDU session binding information for a PCF that is out of service. The consumer NF may then seek to contact the non-operational PCF, fail to receive a response, and then initiate discovery with a network function (NF) repository function (NRF) to obtain alternate PCF session binding information for the UE. Requiring consumer NFs to contact the BSF, contact the non-operational PCF, contact the NRF, and then contact the alternate PCF assigned to a PDU session can result in delays in providing of services to UEs.

In light of these and other challenges, there exists a need for improved, methods, and non-transitory computer-readable media for providing optimized BSF PDU session binding discovery responses.

"<NPL>, is a document that belongs to the prior art and describes that a BSF may subscribe at the NRF to notifications about the availability of PCF(s).

According to the present invention there is provided a method according to claim <NUM>, a system according to claim <NUM> and a non-transitory computer readable medium according to claim <NUM>.

The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms "function" "node" or "module" as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform any one or more of the steps described herein. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

The subject matter described herein relates to methods, systems, and computer readable media for providing optimized BSF PDU session binding discovery responses. <FIG> is a block diagram illustrating an exemplary <NUM> system network architecture. The architecture in <FIG> includes NRF <NUM> and SCP <NUM>, which may be located in the same home public land mobile network (HPLMN). As described above, NRF <NUM> may maintain profiles of available producer NF service instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated producer NF service instances. SCP <NUM> may also support service discovery and selection of producer NFs. In addition, SCP <NUM> may perform load balancing of connections between consumer and producer NFs.

NRF <NUM> is a repository for NF profiles. In order to communicate with a producer NF, a consumer NF or an SCP must obtain the NF profile from NRF <NUM>. The NF profile is a JSON data structure defined in 3GPP TS <NUM> that stores information about NF service instances. The NF profile definition includes at least one of an FQDN, an IP version <NUM> address or an IP version <NUM> address. However, there is no requirement that the NF profile include individual IP addresses or IP endpoints associated with a producer NF service endpoint located on the producer NF service instance.

In <FIG>, any of the nodes (other than SCP <NUM> and NRF <NUM>) can be either consumer NFs or producer NFs, depending on whether they are requesting or providing services. In the illustrated example, the nodes include a policy control function (PCF) <NUM> that performs policy related operations in a network, a user data management (UDM) function <NUM> that manages user data, and an application function (AF) <NUM> that provides application services. The nodes illustrated in <FIG> further include a session management function (SMF) <NUM> that manages sessions between access and mobility management function (AMF) <NUM> and PCF <NUM>. AMF <NUM> performs mobility management operations similar to those performed by a mobility management entity (MME) in <NUM> networks. An authentication server function (AUSF) <NUM> performs authentication services for user equipment (UEs), such as UE <NUM>, seeking access to the network.

A network slice selection function (NSSF) <NUM> provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. A network exposure function (NEF) <NUM> provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (IoT) devices and other UEs attached to the network. NEF <NUM> performs similar functions to the service capability exposure function (SCEF) in <NUM> networks.

A radio access network (RAN) <NUM> connects UE <NUM> to the network via a wireless link. Radio access network <NUM> may be accessed using a g-Node B (gNB) (not shown in Figure 1A) or other wireless access point. A user plane function (UPF) <NUM> can support various proxy functionality for user plane services. One example of such proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality. UPF <NUM> may also support performance measurement functionality, which may be used by UE <NUM> to obtain network performance measurements. Also illustrated in <FIG> is a data network (DN) <NUM> through which UEs access data network services, such as Internet services.

<FIG> is a network diagram illustrating an additional <NUM> NF, the binding support function (BSF), which stores bindings between PDU sessions and PCFs and allows discovery of bindings to other nodes. In <FIG>, BSF <NUM> provides a service that is referred to as the Nbsf_Management service. The Nbsf_Management service is defined in 3GPP TS <NUM>.

In general, the Nbsf_Management service is used for the BSF to provide PDU session binding functionality, which ensures that an AF request for a PDU session reaches the PCF holding the PDU session information. The Nbsf_Management service allows consumers to register, update, and remove binding information. The Nbsf_Management service also allows consumers to retrieve the binding information.

In <FIG>, the consumers of the service provided by BSF <NUM> include a PCF <NUM>, NEF <NUM>, AF <NUM>, and network data analytics function (NWDAF) <NUM>.

PCF <NUM> registers binding information in the BSF for a UE when an IPv4 address and/or an IPv6 prefix is allocated, or a MAC address is used for the PDU session. PCF <NUM> also updates binding information with BSF <NUM> when UE address information is changed for a PDU session. PCF <NUM> removes binding information in BSF <NUM> when an IPv4 address and/or an IPv6 prefix is released or a MAC address is not used for the PDU session.

NEF <NUM> provides a means for AF <NUM> to securely interact with the policy framework for policy control to a 3GPP network. During the procedure, any NEF <NUM> needs to discover the selected PCF using the Nbsf_Management_Discovery service operation.

AF <NUM> discovers the PCF using the Nbsf_Management_Discovery service operation when AF <NUM> is allowed to interact directly with the policy framework for policy control. NWDAF <NUM> discovers a selected PCF using the Nbsf_Management_Discovery service.

Table <NUM> shown below illustrates the operation of the Nbsf_Management service.

In Table <NUM>, the Nbsf_management services offered by the BSF include Nbsf_Management_Register service, Nbsf_Management_Deregister service, Nbsf_Management_Discovery service, and Nbsf_Management_Update service. Nbsf_Management_Register and Nbsf_Management_Deregister services are services used by PCFs to register and deregister session bindings for a UE. The Nbsf_Management_Update service is used by the PCF to update a session binding for a UE when a UE address for a PDU session changes. The Nbsf_Management_Discovery service allows NF service consumers, such as NEFs, AFs, and NWDAFs, discover PDU session binding information for a UE. It is the Nbsf_Management_Discovery service that the subject matter described herein enhances by subscribing to receive updated PCF registration status information for PCFs that are bound to PDU sessions and responding to PDU session binding discovery requests with the NF profiles of reachable PCF instances.

<FIG> illustrates an exemplary message flow when a PCF registers session binding information with BSF <NUM> and a consumer NF discovers the session binding information for the case where the PCF registration status does not change between PDU session binding registration and discovery. Referring to <FIG>, in step <NUM>, a PCF instance <NUM>N creates a binding for a PDU session at BSF <NUM>. PCF instance <NUM>N acting as the NF service consumer may provide PCF Set Id within the "pcfSetId" attribute and "bindLevel" attribute set to NF_SET or provide PCF Set Id within the "pcfSetId" attribute, PCF instance Id within the "pcfld" attribute and "bindLevel" attribute set to NF_INSTANCE. The bindLevel attribute defines the level of the PDU session binding and indicates either an individual PCF instance bound to the session or a group of PDF instances, referred to as an NF set, assigned to the PDU session. If the bindLevel attribute is set to NF_INSTANCE, a single PCF instance is assigned to the PDU session. If the bindLevel attribute is set to NF_SET, then an entire set of PCFs is bound to the PDU session. In <FIG>, PCF set <NUM> includes plural PCF instances <NUM><NUM>-<NUM>N, which can be bound to the same PDU session as a set. In either case, the PCF performing the registration will also specify PCF endpoint identifying parameters for the PCF instance that is providing the policy service for the session. This information will be used by BSF service consumers in discovery requests to obtain PDU session binding information.

In step <NUM> of <FIG>, a consumer NF, which can be any of AF <NUM>, NEF <NUM> or an alternate PCF <NUM>, sends a BSF discovery request to obtain the details of the endpoint that can be used for N5/Rx messages. BSF <NUM> provides the binding information to the consumer NF <NUM>, <NUM>, or <NUM>. In step <NUM>, consumer NF <NUM>, <NUM>, or <NUM> performs N5/Rx messaging with the corresponding PCF instance.

Table <NUM> shown below illustrates exemplary PCF binding data that can be registered by a PCF with BSF <NUM>.

In Table <NUM>, in the attribute name column, the pcfFqdn, pcflpEndPoints, pcfDiamHost, PcfDiamRealm, PcfSmIpEndPoints, the pcfld, pcfSetId, and bindLevel attributes are the PCF identifying attributes set by the PCF that creates or registers the binding record in the BSF. For a discovery request from a consumer NF that uses the N5 interface for contacting the PCF bound to a session, the pcfFqdn and pcflpEndpoints attributes will be used by the consumer NF on the N5 interface to contact the PCF. For a discovery request from a DRA/AF that uses the Rx interface for contacting the PCF bound to a session, the PcfDiamHost and PcfDiamRealm attributes will be used by the DRA/AF to contact the PCF. In case another PCF tries to register binding of the same subscriber + dnn + snssai, pcfSmFqdn and pcfSmIpEndpoints will be used by the alternate PCF. As stated above, the PCF as the NF service consumer may provide the PCF set ID within the pcfSetld attribute and bindLevel attribute set to NF_SET or provide the PCF set ID within the pcfSetld attribute, the PCF instance ID within the pcfld attribute, and the bindLevel attribute set to NF_INSTANCE. The significance of the different settings of these attributes with regarding to providing optimized PDU session binding discovery responses will be explained in detail below with regard to <FIG> and <FIG>.

<FIG> illustrates an exemplary message flow for the Nbsf_Management_Discovery service for a consumer NF that uses the N5 interface to contact the PCF bound to a session. Referring to <FIG>, an NF service consumer <NUM>, which can be any of the service consumers illustrated in <FIG> and <FIG>, invokes the Nbsf_Management_Discovery service option to obtain the address information of the selected PCF for a PDU session in the BSF (step <NUM>). The service is invoked by sending an HTTP GET message that includes "query parameters" used by the BSF to locate any corresponding session bindings. According to 3GPP TS <NUM>, the query parameters include the UE address and may include the SUPI or GPSI, DNN and optionally S-NSSAI, and IPv4 address domain. Upon receiving the HTTP GET message, BSF <NUM> searches for PDU session binding information that matches the query parameters. In step <NUM>, if the HTTP request from the NF service consumer is accepted and a session binding resource matching the query parameters exists, the BSF replies with an HTTP <NUM> OK response with the corresponding PcfBinding data structure as provided by the PCF during the NbsfManagement_Register service operation in the response body. Table <NUM> above is an example of the PCFBinding data structure that will be provided to the consumer NF in response to the discovery request.

<FIG> is a message flow diagram illustrating the PDU session binding discovery process and subsequent Rx session establishment. In <FIG>, BSF <NUM> receives a discovery request which in the Diameter protocol is an Rx-AAR-I message from AF/DRA <NUM>. BSF <NUM> includes a Diameter gateway <NUM> that receives and processes diameter messages, a Diameter connector <NUM> that handles diameter layer connections and a binding service <NUM> that implements the Nbsf_Management_Discovery service.

PCF <NUM> includes a Diameter gateway <NUM> that performs processing of received Diameter messages and a Diameter connector <NUM> that handles diameter connections. PCF <NUM> also includes a policy service <NUM> that makes policy decisions for PDU sessions, a policy authorization service <NUM> that creates policies, a session management service <NUM> that creates session bindings. PCF <NUM> interfaces with session management function <NUM> to inform session management function <NUM> of policy decisions.

In the message flow illustrated in <FIG>, in line <NUM>, AF/DRA <NUM> sends an Rx-AAR-I message to Diameter gateway <NUM> of BSF <NUM>. Diameter gateway <NUM> receives the message and sends, in line <NUM>, the Rx-AAR-I message to Diameter connector <NUM>. Diameter connector <NUM>, in response to receiving the Rx-AAR-I message, sends an Nbsf_Management_Discovery message to binding service <NUM>. Binding service <NUM> performs a lookup in the binding database based on the query parameters in the Nbsf_Management_Discovery message. In line <NUM>, binding service <NUM> sends the binding discovery result to Diameter connector <NUM>. In line <NUM>, Diameter connector <NUM> sends the binding results to Diameter gateway <NUM>.

After receiving the PDU session binding information, AF/DRA <NUM> initiates contact on the Rx interface with the PCF assigned to the session. In line <NUM> of the message flow diagram, Diameter gateway <NUM> sends an Rx-AAR-I proxy message to Diameter gateway <NUM> of PCF <NUM>. In line <NUM>, Diameter gateway <NUM> sends the Rx-AAR-I proxy message to Diameter connector <NUM>. In line <NUM>, Diameter connector <NUM> sends an Npcf_Policy_Authorization_Create message to PA service <NUM>. In line <NUM>, PA service <NUM> sends a session binding request to session management service <NUM>. In line <NUM>, session service <NUM> sends a session binding reply to PA service <NUM>. In line <NUM>, PA service <NUM> sends a create reply message to Diameter connector <NUM>. In line <NUM> Diameter connector <NUM> sends an Rx-AAA-I message to Diameter gateway <NUM>. In line <NUM>, Diameter gateway <NUM> sends the Rx-AAA-I message to Diameter gateway <NUM>. In line <NUM>, Diameter gateway <NUM> sends the Rx-AAA-I message to AF/DRA <NUM>.

After sending the session binding reply in line <NUM>, SM service <NUM> sends a policy evaluate message to policy service <NUM>. Policy service <NUM> makes a decision based on application of a policy and in line <NUM> sends a policy decision to SM service <NUM>. SM service <NUM> applies the policy decision and in line <NUM> sends a policy association notification rules to SMF <NUM>.

If the operational status of a PCF changes after a binding record is created in the BSF, many problems and inefficiencies can occur. For example, if a PCF service instance goes offline during a network outage or due to a service issue, the binding maintained by the BSF is not up to date, and an NRF discovery procedure may be required to be rerun to find an alternate PCF instance. Other problems can occur when SM, PA, and Diameter entities used to contact a PCF instance become unreachable. SMs/PA/Diameter entities published in binding information can also be changed when a new IP address, FQDN, or other identity is assigned to the PCF by the network operator. These changes make entities listed in the BSF's binding table inaccessible and, without the subject matter described herein, a manual procedure is required to update BSF binding records to correct these discrepancies.

<FIG> illustrates a message flow that can occur during discrepancies in the binding database maintained by BSF <NUM>. Referring to <FIG>, in step <NUM>, the PCF service of PCF <NUM>N goes down. As a result, the PCF information stored in BSF <NUM> for PCF <NUM>n cannot be used to process N5 or Rx messages. In step <NUM>, AF/NEF/PCF <NUM>, <NUM>, or <NUM> attempts to perform discovery of binding information stored in the BSF. BSF <NUM> responds with the binding information to identify failed PCF <NUM>N.

In step <NUM>, upon receiving the discovery response, AF/NEF/PCF <NUM>, <NUM>, or <NUM> attempts to contact PCF instance <NUM>N identified in the binding response. However, PCF <NUM>N is not available. Accordingly, upon failing to receive a response, AF/NEF/PCF <NUM>, <NUM> or <NUM> initiates the NF discovery procedure with NRF <NUM> to identify a new PCF instance. In step <NUM>, consumer NF <NUM>, <NUM>, or <NUM> performs N5 or Rx message signaling with the alternate PCF instance <NUM><NUM>.

One problem caused by the unavailability of a PCF instance in the BSF binding database is a delay in processing service requests from consumer NFs. As described above, upon a failed attempt to reach the original PCF, the consumer NF initiates the NRF discovery procedure and reroutes the request to the new PCF upon receiving the discovery response from the NRF. The time required to perform discovery with the BSF, the failed attempt to contact the PCF, and to perform discovery with the NRF result in delayed service provided to the consumer NF.

Another problem associated with outdated binding information maintained by the BSF is a discovery storm at the NRF. When a PCF instance fails, all consumers of binding records with the failed PCF instance as the serving PCF instance will initiate discovery with the NRF to find the identity of an alternate PCF serving the UE. This could lead to the NRF becoming overwhelmed due to the storm of discovery messages at the NRF.

Other challenges associated with discovery include the fact that non-<NUM> nodes, such as a Diameter relay agent (DRA) may not be able to perform <NUM> discovery with the NRF. Accordingly, there is no alternate route for the DRA to try when the binding information received from the BSF is incorrect or not up to date. Similarly, an AF may lack the ability to run NRF discovery to select an alternate PCF. This also limits the possibility for the AF to be served by an alternate PCF.

In order to avoid these difficulties, a BSF may subscribe with an NRF to keep track of registered PCF instances for corresponding PCF sets in the PDU session binding database maintained by the BSF. The BSF, upon processing of a bsf_discovery request, if a binding record is present in the BSF database that contains bindlevel information, may run additional logic set forth below in Table <NUM> to verify that reachable endpoints are in the binding discovery response.

The operation of the BSF in the various scenarios illustrated in Table <NUM> will be described in detail below.

<FIG> illustrates an overview of this solution. In <FIG>, BSF <NUM> includes at least one processor <NUM> and memory <NUM>. BSF <NUM> further includes a PCF instance tracker <NUM> that may be implemented in software executable by processor <NUM>. PCF instance tracker <NUM> subscribes with NRF <NUM> to obtain up to date registration status and NF profile information for PCF instances whose binding data is stored in binding database <NUM> and generate optimized BSF PDU session binding discovery responses based on the updated registration status and NF profile information.

<FIG> illustrates exemplary messaging exchanged between BSF <NUM>, PCF instance <NUM><NUM>, and NRF <NUM> associated with tracking registered PCF instances. As part of the solution, BSF <NUM> keeps tracks of registered PCF instances for corresponding "pcfset(s)". For example, when any PCF instance from PCF NF set "set <NUM>" creates a first binding, BSF <NUM> subscribes with NRF <NUM> to monitor all PCF instances that register with NRF <NUM> with the pcf set id "set1". BSF <NUM> also tracks the number of stored binding records for a given PCF NF set id. When a counter for given NF set id goes to <NUM>, BSF <NUM> un-subscribes for that NFSet with NRF <NUM>.

Referring to the message flow in <FIG>, in line <NUM>, PCF instance <NUM><NUM> of PCF set set1 sends a registration message to BSF <NUM> to create a PDU session binding between PCF instance <NUM><NUM> and a PDU session. In line <NUM>, BSF <NUM> creates the session binding, creates a corresponding record in the PDU session binding database, and responds to PCF instance <NUM><NUM> with an HTTP <NUM> message indicating that the binding has been created. In line, BSF <NUM> determines whether the registration message received in line <NUM> is the first message received for the PCF set set1. In this example, BSF <NUM> determines that registration message is the first message received for pcfSet set1. Accordingly, in line <NUM> of the message flow diagram, BSF <NUM> subscribes with NRF <NUM> to receive notification of change in status of NF instances in the NF set set1. In line <NUM> of the message flow diagram, NRF <NUM> processes the subscription request for pcfSet set1, creates the subscription, and responds to BSF <NUM> indicating the subscription has been created. Once the subscription is created, BSF <NUM> will receive notice from NRF <NUM> any time a change in status of the of any of the NF instances in set1 occurs until the timer maintained by BSF <NUM> for the subscription expires and BSF <NUM> unsubscribes with NRF <NUM> for the status of the PCF set. In line <NUM> of the message flow diagram, BSF <NUM> invokes the nnrf discovery service to discover the PCF profiles in the nfSet set1. In line <NUM>, NRF <NUM> responds with a <NUM> Ok message that includes the list NF profiles of the PCFs in set1. After a successful subscription, the NRF notifies changes to subscribed data from the point of subscription only. Thus, line <NUM> is required for the BSF to fetch the list of all PCF instances in NFSet, with their current states at NRF.

After the message flow in <FIG>, BSF <NUM> will have a list of NF profiles for the PCFs in set <NUM> and will be subscribed with the NRF to receive updates in status of the PCFs. The NRF will notify the BSF any time the NF profile of any of the PCFs in set1 changes. Examples of changes in status include deregistration, change in IP address, etc. As will be described in detail below, BSF <NUM> will use this information to provide optimized discovery response to consumer NFs seeking to discover PDU session binging information from BSF <NUM>.

<FIG> is a flow chart illustrating an exemplary process performed by BSF <NUM> in processing a PDU session binding discovery request message from a consumer NF. Referring to <FIG>, in step <NUM>, BSF <NUM> receives a binding discovery request from a consumer NF. The consumer NF may be an AF, an NEF, another PCF, or an NWDAF. In step <NUM>, BSF <NUM> determines whether binding data is present in the binding database and whether this solution for maintaining PCF status information is enabled. If the solution is enabled, control proceeds to step <NUM>, where BSF <NUM> determines whether the bind level attribute is set in the binding record in the record in the PDU session binding database containing the binding data requested by the discovery request. As illustrated in Table <NUM>, the bind level attribute defines the level at which the binding was originally created. If the binding level attribute is set, control proceeds to step <NUM> where BSF <NUM> determines whether the bind level is NF_instance.

If the bind level is set to NF_instance, this indicates that the binding level for the record is and individual PCF instance, and control proceeds to step <NUM> where BSF <NUM> checks the NRF reported status for the PCF profile with the same pcfld indicates that the corresponding PCF is still registered with the NRF. If the PCF is still registered, control proceeds to step <NUM> where BSF <NUM> determines whether the parameters stored for the PCF instance in the binding record match the corresponding details in the NF profile registered for the PCF instance with the NRF. If the parameters match, control proceeds to step <NUM> where BSF <NUM> sends a binding discovery response with the PCF instance profile of the PCF matching the query parameters (such as UE address) in the binding discovery request.

Returning to step <NUM>, if pcfDiamHost, pcfDiamRealm, pcfSmIpEndPoints, or pcfSmFqdn stored for the PCF instance in the binding record does not match the corresponding details in the NF profile registered for the PCF instance with the NRF, then the parameters in discovery response need to be updated with the parameters for the matching PCF profile registered with the NRF. Accordingly, control proceeds to step <NUM> where the mismatching attributes are updated in the binding response and the response is sent to the consumer NF.

Returning to step <NUM>, if there is no binding data and/or the solution is not enabled, default behavior is executed and control proceeds to step <NUM> where the binding discovery response is sent. If there is no binding data, the binding discovery response will indicate that there is no binding data stored with the BSF matching the query parameters in the binding discovery request.

Returning to step <NUM>, if the bind level attribute is not set in the binding discovery request, the BSF cannot verify PCF instance details from binding data, with registered PCF profiles at NRF. Thus, control proceeds to step <NUM>, where the binding discovery response with PCF information as stored in binding database is sent.

Returning to step <NUM>, if the bind level in the binding data is not set to NF_Instance, control proceeds to step <NUM>, where is determined whether the bind level is set to NF_Set. If the bind level is set to NF_Set, control proceeds to step <NUM> where the BSF <NUM> determines whether the pcfFqdn and pcflpEndPoints parameters in the binding record match those for any PCF profile registered with the NRF (received by the BSF in the discovery response and as modified by any status notifications received from the BSF) for the pcfSetld in the binding record. If the parameters match those for any PCF profile registered with the NRF, control proceeds to step <NUM> where BSF <NUM> determines whether the PCF pcfDiamHost, pcfDiamRealm, pcfSmFqdn, pcfSmIpEndpoints parameters match those for the corresponding PCF profile identified as matching in step <NUM>. If the parameters in step <NUM> match, this indicates that the PCF profile registered with the NRF matches the details in the binding record, and, control proceeds to step <NUM> where the binding discovery response with the PCF profile is sent to the consumer NF.

Returning to step <NUM>, if the bind level is set to NF_Instance and the NRF reported status information for the PCF profile matching the pcfld and pcfSetld is no longer registered with the NRF, the BSF cannot provide the PDU session binding information to the service consumer. In this case, the BSF may respond to the service consumer indicating that no binding information is available and perform actions to clean up or delete the corresponding binding record. Without the solution described herein, the BSF would have responded to the discovery request with a PCF profile of a PCF that is no longer registered with the NRF. This would result in the inefficiencies described above where the service consumer attempts to contact the PCF, is unsuccessful, and contacts the NRF to obtain updated binding information for the PDU session.

Returning to step <NUM>, if the bindLevel is not set to NF_Set or NF_Instance, the bindLevel is unknown because these are the only two bindLevels allowed by the 3GPP specifications. Accordingly, control proceeds to step <NUM> where BSF <NUM> sends a binding discovery response to the consumer NF indicating the binding information stored in the binding database.

Returning to step <NUM>, if the pcfFqdn and pcflpEndpoints in the binding record matching the query parameters do not match any of the PCF profiles registered with the NRF, control proceeds to step <NUM> where BSF <NUM> selects an alternate PCF profile and sends a discovery response to the consumer NF with the alternate PCF profile. Details of the steps performed by BSF <NUM> to select the alternate PCF profile are described below with regard to <FIG>.

Returning to step <NUM>, if the pcfFqdn and pcflpEndpoints in the binding record matching the query parameters match one of the PCF profiles registered but the pcfDiamHost, pcfDiamRealm, pcfSmIpEndPoints, or pcfSmFqdn does not match the corresponding PCF profile, then the parameters in discovery response need to be updated with the parameters for the matching PCF profile registered with the NRF. Accordingly, control proceeds to step <NUM> where the mismatching attributes are updated in the binding response and the response is sent to the consumer NF.

<FIG> illustrates exemplary steps for selecting an alternate PCF profile as illustrated by step <NUM> in <FIG>. Referring to <FIG>, selecting an alternate PCF profile begins in step <NUM> where BSF <NUM> creates, from the list of PCF profiles received from the NRF in the discovery response from the NRF to the BSF (see step <NUM> in <FIG>) or later through NRF notification due to change in status of PCF profile(s) for subscriber NfSet, a list of PCF profiles that match the pcfSetld of the binding record. In step <NUM>, BSF <NUM> determines whether the binding record has pcfSmFqdn or pcfSmIpEndPoints attributes. If BSF <NUM> determines that the binding record has pcfSmFqdn or pcfSmIpEndPoints attributes, control proceeds to step <NUM> where BSF <NUM> filters the profile to locate a profile that supports at least one instance of session management service. If in step <NUM> BSF <NUM> determines that the binding record does not have pcfSmFqdn or pcfSmIpEndPoints attributes, step <NUM> is bypassed.

After step <NUM> or <NUM>, control then proceeds to step <NUM> where BSF <NUM> determines whether the binding record has pcfFqdn or pcflpEndPoints attributes. If the binding record includes these attributes, control proceeds to step <NUM> where BSF <NUM> filters the profiles that have PA service registered. If the binding record does not include the pcfFqdn or pcflpEndPoints attributes, step <NUM> is bypassed.

After step <NUM> or <NUM>, control proceeds to step <NUM>, where BSF <NUM> determines whether the binding record has pcfDiamHost and pcfDiamRealm attributes. If the binding record has pcfDiamHost and pcfDiamRealm attributes, control proceeds to step <NUM> where BSF <NUM> filters profiles that have Diameter attributes published to the NRF in pcfinfo. If the binding record does not have pcfDiamHost and pcfDiamRealm attributes, step <NUM> is bypassed.

After the filtering in step <NUM> or if the binding record does not have the pcfDiamHost and pcfDiamRealm attributes in step <NUM>, control then proceeds to step <NUM> where BSF <NUM> determines whether the list, after the filtering, has more than one profile. If the filtered list includes more than one profile, control proceeds to step <NUM> where BSF <NUM> filters the profile based on operator configuration to select profiles to select a profile that has a matching SM service version. This is an optional step. It is not required when the operator network has more than one PCF instance in the same PCF set with the same major version. Control then proceeds to step <NUM> where BSF <NUM> filters the profile based on operator configuration to select profiles that have the specific api version, load, capacity, location, etc. that best satisfies the requirements of the network operator to be selected as an alternate PCF profile for the PCF whose status has changed since the binding record was created. If in step <NUM>, the BSF determines that the list does not include more than one profile, steps <NUM> and <NUM> are bypassed.

After the filtering in step <NUM> or if more than <NUM> profile was not found in step <NUM>, control proceeds to step <NUM> where BSF <NUM> determines whether there is at least one profile in the filtered list. If BSF <NUM> determines that there is at least one profile in the filtered list, control proceeds to step <NUM> where BSF <NUM> updates the binding discovery response to be sent to the consumer NF to match the parameters of the alternate PCF profile. BSF <NUM> may optionally update the binding record in the PDU session binding database to include the updated information for the alternate PCF. In step <NUM>, BSF <NUM> sends the discovery response with the alternate PCF binding information to the consumer NF.

If BSF <NUM> determines in step <NUM> that there are no remaining profiles in the list, this means that BSF <NUM> cannot find an alternate PCF profile to include in the binding discovery response. Accordingly, control proceeds to step <NUM> where the binding discovery response is sent with the PCF profile from the PDU session binding record.

Thus, the solution described herein allows BSF to actively monitor PCF status information by subscribing to and receiving updates from an NRF. If a PCF whose binding information is maintained at the BSF fails, goes out of service, or has changed attributes in its NF profile, the BSF will upon receiving a discovery request, update the information to be provided to the consumer NF in a binding discovery response and provide the updated binding information to the requesting consumer NF. The BSF may optionally update the binding information for the UE in the PDU session binding database. Such a solution reduces additional messaging from consumer NFs, such as AFs, NEFs, and PCFs towards the NRF. It provides efficient network utilization but avoids network overload. Higher throughput and lower latency at the AF, NEF, and PCF can also be achieved by avoiding unnecessary NRF discovery.

The subject matter described herein is optional and backward compatible. It does not require any parameter or trigger from any other NF and thus control and scope of the feature can be implemented at the BSF. The feature can be selectively enabled for specific consumers by network operators. Information about a consumer seeking force to perform selective enablement can provide selection details such as an instance ID or PLMN ID in authorization token. Alternatively, for HTTPS connections, the transport layer security (TLS) certificate can be used to find the identity of the consumer. Similarly, Vendor specific attributes in the discovery request can also be used to identify the consumer.

The disclosure of each of the following references is hereby acknowledged.

Claim 1:
A method for providing optimized binding support function, BSF, packet data unit, PDU, session binding discovery responses, the method comprising:
at a BSF (<NUM>) including at least one processor (<NUM>):
maintaining a database (<NUM>) of packet data unit, PDU, session binding records;
subscribing with a network function, NF, repository function, NRF (<NUM>), to receive notification of changes to NF profiles of Policy Control Function, PCF, instances for NF sets identified in the PDU session binding records, wherein subscribing with the NRF includes subscribing with the NRF to monitor all PCF instances in a PCF NF set that are registered with the NRF in response to one of the PCF instances in the PCF NF set creating a first PDU session binding in the BSF;
obtaining, from the NRF, lists of NF profiles for the PCF instances for the NF sets identified in the PDU session binding records;
receiving, from the NRF and in response to the subscribing, at least one notification of changes in at least some of the NF profiles in the NF sets identified in the PDU session binding records;
receiving a PDU session binding discovery request from a consumer NF;
identifying, in the database of PDU session binding records and based on at least one query parameter in the PDU session binding discovery request, a matching PDU session binding record matching; and
generating, using the matching PDU session binding record, one of the lists of NF profiles received from the NRF, and at least one notification of changes in at least some of the NF profiles, a PDU session binding discovery response; and
transmitting the PDU session binding response to the consumer NF.