Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/085—Retrieval of network configuration; Tracking network configuration history
  • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/12—Discovery or management of network topologies
  • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/562—Brokering proxy services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
  • H04L67/5682—Policies or rules for updating, deleting or replacing the stored data

Definitions

• the subject matter described herein relates to providing high availability support for NFs. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for distributing NF HA topology information in a core network.
• a network function that provides service is referred to as a producer NF or NF service producer.
• a network function that consumes services is referred to as a consumer NF or NF service consumer.
• a network function can be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or consuming and producing services.
• the terms “producer NF” and “NF service producer” are used interchangeably herein.
• the terms “consumer NF” and “NF service consumer” are used interchangeably herein.
• a given producer NF may have many service endpoints, where a service endpoint is the point of contact for one or more NF instances hosted by the producer NF.
• the service endpoint is identified by a combination of Internet protocol (IP) address and port number or a fully qualified domain name that resolves to an IP address and port number on a network node that hosts a producer NF.
• IP Internet protocol
• An NF instance is an instance of a producer NF that provides a service.
• a given producer NF may include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.
• Producer NFs register with a network function repository function (NRF).
• the NRF maintains service profiles of available NF instances identifying the services supported by each NF instance.
• service profiles and “NF profiles” are used interchangeably herein. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.
• SCP service communication proxy
• the SCP subscribes with the NRF and obtains reachability and service profile information regarding producer NF service instances.
• Consumer NFs connect to the service communication proxy, and the service communication proxy load balances traffic among producer NF service instances that provide the required services or directly routes the traffic to the destination producer NF instances.
• SEPP security edge protection proxy
• PLMNs 5G public land mobile networks
• API application programming interface
• NFs in the 5G network support different HA topologies, including active-active, active-standby, an N+K, where N is the number of active NF instances and K is the number of standby NF instances.
• Consumer NFs seeking to obtain service from a producer NF that operates in an HA topology need to know the HA topology for load balancing and for rerouting in the event that a producer NF providing service to a consumer NF fails.
• 3GPP standards do not currently provide a way for producer NFs to publish their HA topology information to the core network.
• a method for distributing network function (NF) high availability (HA) topology information in a core network includes, at an NF repository function (NRF) including at least one processor, receiving, from a plurality of producer NFs in an NF set, NFRegister requests including NF HA topology information for the producer NFs. The method further includes registering the producer NFs and storing the NF HA topology information for the producer NFs. The method further includes receiving, from a consumer NF or service communication proxy (SCP), an NFDiscover request containing at least one service discovery parameter that corresponds to a service provided by the producer NFs.
• SCP consumer NF or service communication proxy
• the method further includes responding to the NFDiscover request by generating an NFDiscover response, including, in the NFDiscover response, the NF HA topology information for the producer NFs, and transmitting the NFDiscover response to the consumer NF or SCP.
• receiving the NFRegister requests including the NF HA topology information includes receiving the NFRegister requests including information identifying an NF HA topology type supported by the producer NFs.
• the information identifying the NF HA topology type includes information identifying one of: an active-active NF HA topology type, an active-standby NF HA topology type, and an N+K NF HA topology type, where N and K are integers respectively identifying a number of active NFs and a number of standby NFs in the NF set.
• receiving the NFRegister requests including the NF HA topology information includes receiving the NFRegister requests, each including information identifying a current NF HA topology role of a producer NF in the NF set.
• the information identifying the current NF HA topology role of the producer NF in the NF set includes information identifying the producer NF as an active NF or a standby NF.
• responding to the NFDiscover request with the NFDiscover response including the NF HA topology information comprises including, in the NFDiscover response, the information identifying the NF HA topology type and the information identifying the current NF HA topology role.
• the method for distributing NF HA topology information includes, at the NRF, receiving, from at least one of the producer NFs, an NFUpdate request including updated NF HA topology information for the at least one producer NF and, in response to the receiving the NFUpdate request with the updated NF HA topology information for the at least one producer NF, storing the updated NF HA topology information for the at least one producer NF and automatically communicating the updated NF HA topology information to consumer NFs subscribed to receive updates in NF profile information for the at least one producer NF.
• the updated NF HA topology information indicates a change in role of a first producer NF in the NF set from an active HA role to a standby HA role and of a second producer NF in the NF set from a standby HA role to an active HA role and wherein the method further comprises, at the consumer NF or SCP, transmitting a service request to the second producer NF.
• receiving the NFDiscover request from a consumer NF or SCP includes receiving the NFDiscover request from a consumer NF, and further comprising, at the consumer NF, using the NF HA topology information to select a producer NF in the NF set to provide service to the consumer NF.
• receiving the NFDiscover request from a consumer NF or SCP includes receiving the NFDiscover request from an SCP, and further comprising, at the SCP, using the NF HA topology information to select a producer NF in the NF set to provide service to the consumer NF.
• a system for distributing network function (NF) high availability (HA) topology information in a core network includes a network function (NF) repository function (NRF) including at least one processor.
• the system further includes an NF profiles manager implemented by the at least one processor for receiving, from a plurality of producer NFs in an NF set, NFRegister requests including NF HA topology information for the producer NFs, registering the producer NFs and storing the NF HA topology information for the producer NFs, receiving, from a consumer NF or service communication proxy (SCP), an NFDiscover request containing at least one service discovery parameter that corresponds to a service provided by the producer NFs, and responding to the NFDiscover request by generating an NFDiscover response, including, in the NFDiscover response, the NF HA topology information for the producer NFs, and transmitting the NFDiscover response to the consumer NF or SCP.
• SCP consumer NF or service communication proxy
• the NFRegister requests include information identifying an NF HA topology type supported by the producer NFs.
• the information identifying the NF HA topology type includes information identifying one of: an active-active NF HA topology type, an active-standby NF HA topology type, and an N+K NF HA topology type, where N and K are integers respectively identifying a number of active NFs and a number of standby NFs in the NF set.
• the NFRegister requests each include information identifying a current NF HA topology role of a producer NF in the NF set.
• the information identifying the current NF HA topology role of the producer NF in the NF set includes information identifying the producer NF as an active NF or a standby NF.
• the NFDiscover response includes the information identifying the NF FIA topology type and the information identifying the current NF FIA topology role.
• the NF profiles manager is configured to receive, from at least one of the producer NFs, an NFUpdate request including updated NF FIA topology information for the at least one producer NF and, in response to the receiving the NFUpdate request with the updated NF FIA topology information for the at least one producer NF, store the updated NF FIA topology information for the at least one producer NF and automatically communicate the updated NF FIA topology information to consumer NFs subscribed to receive updates in NF profile information for the at least one producer NF.
• the updated NF FIA topology information indicates a change in role of a first producer NF in the NF set from an active FIA role to a standby FIA role and of a second producer NF in the NF set from a standby FIA role to an active FIA role.
• the NF profiles manager receives the NFDiscover request from a consumer NF.
• the NF profiles manager receives the NFDiscover request from an SCP.
• a non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor of a computer control the computer to perform steps.
• the steps are performed at a network function (NF) repository function (NRF).
• the steps include receiving, from a plurality of producer NFs in an NF set, NFRegister requests including NF high availability (FIA) topology information for the producer NFs.
• the steps further include registering the producer NFs and storing the NF FIA topology information for the producer NFs.
• the steps further include receiving, from a consumer NF or service communications proxy (SCP), an NFDiscover request containing at least one service discovery parameter that corresponds to a service provided by the producer NFs.
• SCP consumer NF or service communications proxy
• the steps further include responding to the NFDiscover request by generating an NFDiscover response, including, in the NFDiscover response, the NF FIA topology information for the producer NFs, and transmitting the NFDiscover response to the consumer NF or SCP.
• the subject matter described herein can be implemented in software in combination with hardware and/or firmware.
• the subject matter described herein can be implemented in software executed by a processor.
• the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps.
• 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.
• 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.
• Figure 1 is a network diagram illustrating an exemplary 5G system network architecture
• Figure 2 is a message flow diagram illustrating exemplary messages exchanged between network functions in a network that does not provide support for the distribution of NF HA topology information where a consumer NF selects a producer NF that is currently in a standby HA role;
• Figure 3 is a message flow diagram illustrating exemplary messages exchanged between network functions in a network that does not provide support for the distribution of NF HA topology information where a producer NF transitions to a standby HA role and a consumer NF attempts to obtain service from the producer NF after the HA state transition;
• Figure 4 is a message flow diagram illustrating an exemplary network that supports distribution of NF FIA topology information where a producer NF provides the FIA topology type implemented by the NF set of which producer NF is a member and the current FIA role of the producer NF to an NRF and the NRF provides the FIA topology information to a consumer NF in a discovery response so that the consumer NF can use the FIA topology information in selecting a producer NF to provide service;
• Figure 5 is a message flow diagram illustrating an exemplary network that supports distribution of FIA topology information
• a producer NF provides the FIA topology type implemented by the NF set of which producer NF is a member and the current FIA role of the producer NF to an NRF
• the NRF publishes the update in the FIA topology information to a consumer NF
• the consumer NF uses the updated FIA topology information to select an active producer NF to provide service
• Figure 6 is a block diagram illustrating an exemplary architecture for an NRF that facilitates distribution of NF FIA topology information to consumer NFs and SCPs;
• Figure 7 is a flow chart illustrating an exemplary process performed by an NRF for distributing NF FIA topology information to NFs and SCPs;
• Figure 8 is a block diagram illustrating an exemplary architecture for a consumer NF for obtaining and using NF FIA topology information
• Figure 9 is a flow chart illustrating an exemplary process performed by a consumer NF for obtaining and using NF FIA topology information
• Figure 10 is a block diagram illustrating an exemplary architecture for a producer NF for distributing NF FIA topology information
• Figure 11 is a flow chart illustrating an exemplary process performed by a producer NF for distributing NF FIA topology information.
• FIG. 1 is a block diagram illustrating an exemplary 5G system network architecture.
• the architecture in Figure 1 includes NRF 100 and SCP 101, which may be located in the same home public land mobile network (HPLMN).
• NRF 100 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 101 may also support service discovery and selection of producer NF instances.
• SCP 101 may perform load balancing of connections between consumer and producer NFs.
• NRF 100 is a repository for NF or service profiles of producer NF instances.
• a consumer NF or an SCP In order to communicate with a producer NF instance, a consumer NF or an SCP must obtain the NF or service profile of the producer NF instance from NRF 100.
• the NF or service profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510.
• JSON JavaScript object notation
• the NF or service profile definition includes at least one of a fully qualified domain name (FQDN), an Internet protocol (IP) version 4 (IPv4) address or an IP version 6 (IPv6) address.
• any of the network functions can be consumer NFs, producer NFs, or both, depending on whether they are requesting, providing, or requesting and providing services.
• the NFs include a policy control function (PCF) 102 that performs policy related operations in a network, a unified data management (UDM) 104 that manages user data, and an application function (AF) 106 that provides application services.
• PCF policy control function
• UDM unified data management
• AF application function
• the NFs illustrated in Figure 1 further include a session management function (SMF) 108 that manages sessions between access and mobility management function (AMF) 110 and PCF 102.
• AMF 110 performs mobility management operations similar to those performed by a mobility management entity (MME) in 4G networks.
• An authentication server function (AUSF) 112 performs authentication services for user equipment (UEs), such as user equipment (UE) 114, seeking access to the network.
• UEs user equipment
• UE user equipment
• a network slice selection function (NSSF) 116 provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice.
• a network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (loT) devices and other UEs attached to the network. NEF 118 performs similar functions to the service capability exposure function (SCEF) in 4G networks.
• SCEF service capability exposure function
• a radio access network (RAN) 120 connects user equipment (UE) 114 to the network via a wireless link.
• Radio access network 120 may be accessed using a g-Node B (gNB) (not shown in Figure 1 ) or other wireless access point.
• gNB g-Node B
• a user plane function (UPF) 122 can support various proxy functionality for user plane services.
• proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality.
• MPTCP multipath transmission control protocol
• UPF 122 may also support performance measurement functionality, which may be used by UE 114 to obtain network performance measurements.
• DN data network
• DN data network
• SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN.
• SEPP 126 may communicate with a SEPP in a foreign PLMN which manages security for the foreign PLMN.
• traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.
• HA topology types are:
• Active-Standby - were some NFs are operational and provide service and other NFs are operational but do not provide service unless one of the active NFs fails or otherwise becomes unavailable;
• N NFs are operational and provide service and K NFs are operational but do not provide service unless one of the N active NFs fails or otherwise becomes unavailable.
• 3GPP does not provide a way to publish FIA related information in the network. 3GPP implies active-active FIA topology for an NF set, which is not true for all deployments.
• An NF set is a logical group of NFs that provide the same service, support the same network slices, and are identified by the same NF set ID. 3GPP assumes that all of the NFs in an NF set are active, which may not be true, for example, if an operator decides to deploy some NFs in a NF set as active and other NFs in the NF set as standby.
• the subject matter described herein provides a method for publishing an NF’s FIA topology information so that a consumer NF or SCP can use this information when selecting an NF to provide service.
• the NF FIA topology information may define the NF FIA type implemented by an NF set, as well as the publishing NF’s role in the NF FIA type.
• 5G SB I routing is not possible for an FIA topology, other than active-active topology.
• NFs implementing an N+K FIA are required to be deployed in an active-active topology where the network operator will face the following challenges: the NF consumer/SCP would have to incur additional routing attempts in the case of FIA an state transition (to standby) after resource creation; and the consumer NF/SCP would have problems in load balancing traffic between NF instances with different FIA roles.
• FIG. 2 is a message flow diagram illustrating exemplary messages exchanged when a consumer NF or SCP attempts to route traffic to a standby producer NF in an NF set that implements an N+K FIA topology.
• producer NF-1 200 operates in an active FIA role
• producer NF-2 202 operates in a standby FIA role
• Producer NF-1 200 and producer NF-2 202 form an NF set 204.
• NF set 204 implements an N+K FIA topology.
• producer NF-1 200 sends an NFRegister request to NRF 100.
• the NFRegister request contains the NF profile of producer NF-1 200.
• 3GPP does not define a way for producer NF-1 200 to communicate to NRF 100 the FIA topology type implemented by NF set 204 or the role of producer NF-1 200 in the FIA topology type.
• producer NF-2 202 operating in a standby FIA role sends an NFRegister request message to NRF 100.
• the NFRegister request message does not include an indication that producer NF- 2 202 is operating in a standby role.
• consumer NF or SCP 206 sends an NFDiscover request message to NRF 100.
• the NFDiscover request message may include discovery parameters for selecting a producer NF to provide service.
• NRF 100 responds to the NFDiscover request message with an NFDiscover response message including the NF profiles of producer NF-1 200 and producer NF-2 202.
• the NFDiscover response message does not include the NF FIA type implemented by NF set 204 or the FIA roles of producer NF-1 200 and producer NF-2 202.
• consumer NF or SCP 206 may route a service based interface (SBI) service request, as indicated by step 5 of the message flow diagram, to a producer NF operating in the standby role.
• SBI service based interface
• producer NF-2 202 receives the SBI service request message, because producer NF-2 202 is operating in the standby role, producer NF-2 202 will reject the SBI service request message.
• consumer NF or SCP 206 is required to re-route the service request by selecting another NF and sending the SBI service request to another producer NF.
• Consumer NF or SCP 206 may be required to re-route the service request multiple times until the request is received by a producer NF operating in an active FIA role. Such re-routing is time consuming and wastes network resources.
• Figure 3 illustrates another problem that can occur when an NF FIA state transition occurs.
• producer NF-1 200 and producer NF-2 202 have registered with NRF 100 without specifying their NF FIA topology types or the NF FIA topology role implemented by the NF set of which producer NF-1 200 or producer NF-2 202 are members.
• consumer NF or SCP 206 sends ab SBI service request to producer NF-1 200.
• producer NF-1 200 is functioning in the active FIA role
• producer NF-1 200 responds to the SBI service request in step 2 with a 201 Created message.
• step 3 an FIA state transition occurs in NF set 204 where producer NF-1 200 transitions to a standby FIA role, and producer NF-2 202 transitions to an active FIA role.
• step 4 of the message flow diagram consumer NF or SCP 206 sends a subsequent service request to producer NF-1 200, which is currently operating in the standby FIA role. Because producer NF-1 200 is operating in the standby role, producer NF-1 200 rejects the service request. As a result, consumer NF or SCP 206 will be required to re-route the service request to another NF, which results in routing and network inefficiencies.
• subject matter described herein includes the ability of a producer NF to communicate, to the NRF, the NF FIA topology type implemented by the NF set of which the producer NF is a member and also the current FIA role of the producer NF within the FIA topology type.
• the NRF stores information that indicates the NF FIA topology type and current NF FIA role in the NF profiles database or in a separate database.
• the NRF includes in the discovery response, information that indicates the NF FIA topology type and NF FIA topology role of the producer NFs.
• FIG. 4 is a message flow diagram illustrating an exemplary network that supports distribution of NF FIA topology information where a producer NF provides the FIA topology type implemented by the NF set of which producer NF is a member and the current FIA role of the producer NF to an NRF and the NRF provides the FIA topology information to a consumer NF in a discovery response so that the consumer NF can use the FIA topology information in selecting a producer NF to provide service.
• producer NF-1 200 sends an NFRegister request message to NRF 100 to register producer NF-1 200 to provide service.
• the NFRegister request message indicates the NF FIA topology type, which in the illustrated example is active/standby and the FHF FIA role, which, for producer NF-2 202, is active.
• consumer NF or SCP 206 sends an NFDiscover request message to NRF 100.
• the NFDiscover request message may include discovery parameters for selecting a producer NF to provide service to a consumer NF.
• NRF 100 responds to the NFDiscover request message with an NFDiscover response message including the NF profiles of producer NF-1 200 and producer NF-2 202.
• the NFDiscover response message includes NF FIA topology information that indicates the NF FIA type implemented by NF set 204 and the FIA roles of producer NF-1 200 and producer NF-2 202.
• the NF FIA topology information indicates that the NF FIA topology type implemented by NF set 204 is active/standby, the NF FIA role currently implemented by producer NF- 1 200 is active, and the NF FIA role currently implemented by producer NF-2 202 is standby.
• consumer NF or SCP 206 selects a producer NF that is currently in the active FIA role to provide service.
• consumer NF or SCP 206 selects producer NF-1 200 to provide service.
• producer NF or SCP 206 sends an SBI service request to producer NF-1 200, which is operating in the active FIA role. Because producer NF-1 200 is operating in the active FIA role, producer NF-1 200 accepts the SBI service request, and, in step 6, responds to the SBI service request with a 201 Created message.
• Figure 4 illustrates the case where NF FIA topology information is provided to NRF 100 in NFRegister messages, distributed to a consumer NF or SCP in an NFDiscover response message, and used by the consumer NF or SCP to select an active NF to process an initial SBI service request message. Because the consumer NF or SCP has the NF FIA topology information, consumer NF or SCP 206 can avoid the routing inefficiency illustrated in Figure 2.
• FIG. 5 is a message flow diagram illustrating exemplary messages exchanged to distribute updated NF FIA topology information in response to an FIA state transition and the use of the update FIA topology information to select a new active NF to provide service.
• an NF FIA state transition occurs.
• the NF FIA state transition is producer NF-1 200 switching its FIA role from active to standby and producer NF-2 202 switching its FIA role from standby to active.
• producer NF-1 200 sends an NFUpdate request to NRF 100 identifying the new FIA role of producer NF-1 200.
• NRF 100 in response to receiving the NFUpdate request, publishes a notification message to all consumer NFs or SCPs that are subscribed to receive updates regarding changes in status of producer NF-1 200.
• producer NF-1 200 sends the notification message to consumer NF or SCP 206.
• the notification message includes the updated NF FIA topology information for producer NF-1 200.
• step 4 of the message flow diagram producer NF-2 202 sends NFUpdate request to NRF 100 containing a new NF FIA role for producer NF- 2 202.
• the NF update message indicates that producer NF-2 202 is switching to the active role.
• step 5 of the message flow diagram NRF 100 sends a notification message to consumer NF or SCP 206 with the updated NF FIA topology information for producer NF-2202.
• consumer NF or SCP 206 formulates a subsequent SBI service request message, and, rather than sending the subsequent SBI service request message to producer NF-1 200, consumer NF or SCP 206 sends the subsequent SBI service request to producer NF-2202 based on the current updated HF FIA topology information.
• producer NF-2 202 switches to the active state, producer NF-2 202 has obtained the necessary state information to process the subsequent SBI service request from consumer NF or SCP 206.
• producer NF-2 202 sends a 200 OK message to consumer NF or SCP 206.
• Figure 5 illustrates the case where producer NFs automatically update their FIA roles and communicate their new FIA roles to NRF 100 and where NRF 100 automatically distributes indications of the change in status to consumer NFs and SCPs that are subscribed to receive updates regarding change in status of an NF.
• the subject matter described herein avoids the scenario illustrated in Figure 3 where an NF FIA state transition occurs and a subsequent SBI service request lands on a standby producer NF.
• the scenario illustrated in Figure 5 provides increased efficiency over the scenario illustrated in Figure 3 where the consumer NF or SCP is required to re-route the service request to another producer NF.
• FIG. 6 is a block diagram illustrating an exemplary architecture of NRF 100 capable of obtaining, storing, and distributing producer NF FIA topology information.
• NRF 100 includes at least one processor 600 and a memory 602.
• NRF 100 further includes an NF profiles database 604 that stores NF profiles of producer NFs that are registered with NRF 100.
• NRF 100 further includes an NF profiles manager 606 that receives NFRegister request messages, stores NF profiles of producer NFs in database 604, and distributes NF profile information from consumer NFs.
• NF profiles manager 606 may also receive NF FIA topology information from producer NFs and store the FHF FIA topology information in NF profiles database 604 or in a separate database maintained by NRF 100.
• NF profiles manager 606 may provide the NF FIA topology information to consumer NFs or SCPs in response to NFDiscover requests and also in response to NFUpdate messages from producer NFs.
• NF profiles manager 606 may be implemented using computer executable instructions stored in memory 602 and executed by processor 600.
• Figure 7 is a flow chart illustrating an exemplary method for distributing NF FIA information. The steps in Figure 7 are performed at an NRF, such as NRF 100. Referring to Figure 7, in step 700, the process includes receiving, from a plurality of producer NFs in an NF set, NFRegister requests including NF FIA topology information for the producer NFs.
• NRF 100 may receive NFRegister requests from producer NFs, where the NFRegister requests include information identifying an NF FIA topology type implemented by the producer NFs and a current NF FIA topology role implemented by each producer NF in the NF set.
• NF FIA topology types may include active-active, active-standby, and N+K, where N and K are integers that respectively identify the number of active and standby NFs in an NF set.
• the NF FIA topology role information provided in the NFRegister requests may identify each NF as active or standby.
• the process includes registering the producer NFs and storing the NF FIA topology information for the producer NFs.
• NRF 100 may register the producer NFs by storing the NF profiles for the producer NFs in NF profiles database 604 and storing registration status or state indicators for the NFs indicating a status or state of REGISTERED.
• NRF 100 may store the NF FIA topology information in NF profiles database 604 or in a separate database used to store NF FIA topology information.
• the process includes receiving, from a consumer NF or service communication proxy (SCP), an NFDiscover request containing at least one service discovery parameter that corresponds to a service provided by the producer NFs.
• SCP service communication proxy
• NRF 100 may receive an NFDiscover request from a consumer NF that includes parameters identifying a type of service for which NF discovery is being requested.
• the process includes responding to the NFDiscover request by generating an NFDiscover response, including, in the NFDiscover response, the NF FIA topology information for the producer NFs, and transmitting the NFDiscover response to the consumer NF or SCP.
• NRF 100 may generate an NFDiscover response message in response to a received NFDiscover request message.
• the NFDiscover response message may include NF profiles of producer NFs that match the service identifying parameters in the NFDiscover request.
• the NFDiscover response may also include, for each NF for which NF FIA topology information is available, the NF FIA type implemented by the producer NF set and the current NF FIA role of each producer NF.
• the NF FIA topology information may be included as one or more attributes of the NF profile of each producer NF or may be communicated separately from the NF profiles of the producer NFs.
• the process includes receiving updated NF FIA topology information for a producer NF.
• NRF 100 may receive an NFUpdate request message from a producer NF when the NF FIA topology role of the producer NF changes.
• Examples of NF FIA topology role changes include changes from active to standby or from standby to active.
• the process includes publishing the updated NF FIA topology information for the producer NF to NFs subscribed to receive NFUpdates regarding the producer NF.
• NRF 100 in response to receiving an NFUpdate request message regarding a producer NF may update the profile for the producer NF in the NF profiles database.
• NRF 100 may also update the NF FIA role for the producer NF if the NF FIA role for the producer NF changed.
• NRF 100 may then communicate notification of changes in the NF profile and the NF FIA topology information to consumer NFs and SCPs that are subscribed to receive the updates.
• FIG. 8 is a block diagram illustrating an exemplary architecture for consumer NF or SCP 206 that obtains and uses NF FIA topology information to route SBI service requests.
• consumer NF or SCP 206 includes at least one processor 800 and a memory 802.
• Consumer NF or SCP 206 further includes and NF discovery/SBI request generator 804 that generates and sends NFDiscover requests to NRF 100, receives NFDiscover responses from NRF 100, where the NFDiscover responses include NF FIA topology information, and generates and sends SBI requests to producer NFs selected using the NF FIA topology information.
• NF discovery/SBI request generator 804 may be implemented using computer executable instructions stored in memory 802 and executed by processor 800.
• Figure 9 is a flow chart illustrating an exemplary process implemented by a consumer NF or SCP for obtaining and using NF FIA topology information to select a producer NF to provide service.
• the steps illustrated in Figure 9 may be implemented by consumer NF or SCP 206 illustrated in Figure 8.
• the process includes generating an NFDiscover request and sending the NFDiscover request to an NRF.
• consumer NF or SCP 206 may generate an NFDiscover request including discovery parameters for a service needed by a consumer NF and send the NFDiscover request to NRF 100.
• the process includes, in response to the NFDiscover request, receiving an NFDiscover response.
• the NFDiscover response includes NF profiles matching the discovery parameters from the request as well as NF FIA topology information of producer NFs.
• the NF FIA topology information may be included in the NF profiles or may be included in data structures separate from the NF profiles.
• the process includes selecting a producer NF to provide a service using the NF FIA topology information.
• consumer NF for SCP 206 may use the NF FIA topology information to select an active NF to provide service for the consumer NF.
• the process includes sending a new SBI request to the producer NF.
• consumer NF or SCP 206 may send an SBI request to the producer NF that was selected using the NF FIA topology information.
• the process includes receiving an NFUpdate request message with updated NF FIA topology information for the producer NF.
• consumer NF for SCP 206 may receive an NFUpdate request message containing updated HF FIA topology information for a producer NF currently providing service for the consumer NF.
• the updated NF FIA topology information may indicate that the role of the producer NF has changed.
• the process includes selecting a new producer NF to provide the service based on the updated FHF FIA topology information. For example, consumer NF or SCP 206 may select a new active producer NF to provide service when the role of the producer NF currently providing service changes to standby.
• consumer NF or SCP 206 generates and sends a new SBI request to the new producer NF. For example, consumer NF or SCP 206 may generate and send an SBI request to a producer NF that is currently active.
• FIG 10 is a block diagram illustrating an exemplary producer NF 200 or 202 capable of distributing NF FIA topology information to other NFs.
• producer NF 200 or 202 includes at least one processor 1000 and a memory 1002.
• Producer NF 200 or 202 further includes an NF FIA topology manager 1004 that maintains, in memory 1002, indications of the NF FIA topology type and NF FIA topology role implemented by producer NF 200 or 202.
• NF FIA topology manager 1004 may also determine when the NF FIA topology role of producer NF 200 or 202 needs to change, e.g., based on input from a network operator that the NF FIA topology of producer NF 200 or 202 needs to change.
• Producer NF 200 or 202 also distributes its NF FIA topology information to other NFs by sending NFRegister and NFUpdate messages to NRF 100.
• NF FIA topology manager 1004 may be implemented using computer executable instructions stored in memory 1002 and executed by processor 1000.
• Figure 11 illustrates an exemplary process implemented by a producer NF in distributing its NF FIA topology information to other NFs.
• the process includes storing indications of FIA topology type and FIA topology role in memory.
• producer NF 200 or 202 may store, in memory 1002, an indication of the current FIA topology type and FIA topology role implemented by producer NF 200 or 202.
• the process includes communicating the NF FIA topology information to the NRF.
• producer NF 200 or 202 may generate and send an NFRegister request including the NF FIA topology information to NRF 100.
• the process includes detecting a need for a change in NF FIA role.
• producer NF 200 or 202 may determine that its NF FIA topology role needs to change in response to receiving notification of the need for a change from a network operator.
• producer NF 200 or 202 changes its NF FIA role. For example, producer NF 200 or 202 may change from active to standby or from standby to active.
• producer NF 200 or 202 communicates an indication of the updated NF FIA role to the NRF. For example, producer NF 200 or 202 may generate and send an NFUpdate request message with the updated NF FIA role to NRF 100.
• Benefits of the subject matter described herein include synergy between the NRF and SCP in indirect communication models. Another benefit is that the subject matter enables NFs to expose their supported FIA topology in the 5GC, which results in better (re-)routing and load balancing handling at the NF consumer/SCP.
• the subject matter described herein also provides better routing resiliency for producers supporting an active-standby or an N+K FIA topology.
• the subject matter described herein also provides better routing resiliency for networks with hybrid NF deployments (virtual machine (VM), hardware, cloud-native) with different FIA topologies.
• VM virtual machine

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=82358462

Family Applications (1)

Country Status (5)

Cited By (3)

Families Citing this family (7)

Citations (2)

Family Cites Families (6)

• 2021
  • 2021-05-28 US US17/334,268 patent/US11611626B1/en active Active
• 2022
  • 2022-05-25 CN CN202280038335.5A patent/CN117397230A/zh active Pending
  • 2022-05-25 WO PCT/US2022/030874 patent/WO2022251324A1/en not_active Ceased
  • 2022-05-25 JP JP2023573199A patent/JP2024521821A/ja active Pending
  • 2022-05-25 EP EP22736055.9A patent/EP4348990B1/en active Active

Patent Citations (2)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events