2 research outputs found
SYSTEM AND METHOD FOR DETECTING INFINITE SIGNALING LOOP IN HIERARCHICAL NRF DEPLOYMENTS
For larger deployments, where multiple level of Network Function (NF) Repository Functions (NRFs) are deployed, the slightest misconfiguration could lead to an indefinite query loop between NRFs. The indefinite loop in the NRF query would mean repeated timeouts and/or failure of a service discovery request that a consumer had initiated to find a suitable producer. This could lead to signaling failure between a set of consumers and producers, which in turn can lead to Quality of Service (QoS) and Service Level Agreement (SLA) violations. A new Hypertext Transfer Protocol Version 2 (HTTP/2) header, Network Function (NF)-route-record, is proposed, which should be added by an intermediate NRF (relay or proxy) before forwarding any request. The NF-route-record should contain the identity of the peer from which the request was received. The receiving NRF checks the NF-route-record before further forwarding or serving the request. If the NF-route-record matches its own identity, then the receiving NRF would detect the loop. The same can be used in the reverse direction when sending the response from a server (producer) to a client (consumer)
TECHNIQUES TO FACILITATE SELECTION OF NEXT HOP NRF IN A HIERARCHICAL NETWORK REPOSITORY FUNCTION (NRF) DEPLOYMENT IN 5G NETWORKS
When a Fifth Generation (5G) Network Repository Function (NRF) deployed in a Third Generation Partnership Project (3GPP) hierarchical model architecture receives a Network Function (NF) Discovery or Subscription or Access Token request, the NRF may not have the required information to serve the request on account of the information being divided among multiple NRF instances in the network. In such cases, the NRF instance that receives the request from a consumer NF may choose to forward or redirect the request to another NRF instance in the hierarchy. The conditions and policies to decide when to redirect or forward the request to another NRF are not defined by 3GPP. Further, the procedures and policies for selecting the next hop NRF are left to implementation. This is a major gap in 3GPP standards as an NRF at each hierarchical level needs rules to determine whether it can serve a request locally or needs to forward/redirect the request to another NRF instance in the hierarchy. This proposal involves defining a granular, flexible and policy-driven system for NRF selection and message routing between hierarchical NRFs to minimize latency and signaling overhead