System and method for providing enhanced network repository function (ENRF) for edge locations

Abstract

The present disclosure provides a system and a method to deploy an enhanced Network Repository Function (NRF) for an edge location. The present disclosure deploys a common enhanced NRF at the edge locations for 6th Generation (6G) Network Functions (NFs), 5th Generation (5G) NFs, and custom NFs, thereby ensuring reduction in latency for NRF signaling. The present disclosure provides a custom interface between the eNRF and a centralized NRF for auto building of routing table at the centralized NRF. The present disclosure uses AI / ML based enhancements for data management from other eNRFs for use during failures / outages. The present disclosure reports measurement parameters from the NFs which may be auto parsed by the eNRF and stored in a local cache. These measurement parameters allow other analytics and scaling NFs to perform analytics and scaling decision by gathering data directly from the eNRF rather than depending on multiple NFs.

Description

SYSTEM AND METHOD FOR PROVIDING ENHANCED NETWORK REPOSITORY FUNCTION (eNRF) FOR EDGE LOCATIONS RESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, integrated circuit (IC) layout design, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (herein after referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner. TECHNICAL FIELD

[0002] The present disclosure relates to a field of a wireless network, and specifically to a system and a method for providing an enhanced Network Repository Function (NRF) for edge locations, for example, 5thGeneration (5G) edge locations and 6thGeneration (6G) edge locations. DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] The term ‘eNRF’ as used herein, refers to an enhance Network Repository Function (eNRF). The eNRF provides an ability to efficiently manage a substantial volume of Network Functions (NFs) at edge locations by prioritizing servicing of local service requests received from the NFs.

[0005] The term ‘centralized NRF’ as used herein, refers to a centralized Network Repository Function (NRF) that is located at a centralized data centre location that is configured for managing NFs located at various edge locations.

[0006] The term ‘service operation request’ as used herein, refers to a service request, such as a discovery request, a subscribe request, an access token request, or a bootstrapping request, received from the NFs.

[0007] The term ‘local service request’ as used herein, refer to the service operation request received from a NF that the eNRF can handle and fulfil internally by itself.

[0008] The term ‘non-local service request’ as used herein, refer to the service operation request received from a NF that the eNRF cannot fulfil by itself and has to be forwarded to the centralized NRF or an another eNRF in order to be fulfilled.

[0009] The term ‘another eNRF’ refers to any secondary eNRF that is situated at a different edge location in a telecommunications network. BACKGROUND

[0010] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0011] In a current 3rdGeneration Partnership Project (3GPP) architecture, certain Network Functions (NFs) such as a User Plane Function (UPF) are deployed at an edge location near to a customer, while other NFs, for example, an Access and Mobility Management Function (AMF) are mostly deployed at data centre or centralized locations. This architecture works good with current or limited number of cell locations or subscribers. But, in future as a number of cell sites and the subscribers increase many folds, it may lead to possibly tens or hundreds or thousands of edge locations. Further with a current 5thGeneration (5G) network or a 6thGeneration (6G) network, it may be feasible that other than the UPF, other NFs may also be shifted to the edge locations. These NFs may use analytics or Machine Learning (ML) to update edge NFs as well as take decision for scaling of the edge NFs.

[0012] For these NFs, if a Network Repository Function (NRF) is located at a centralized data centre location (i.e., a centralized Network Repository Function),it may pose some key challenges, such as quantity of the NFs that are defined as per an edge location may be very large, thus the centralized NRF may not be able to fulfil such requirements. Further, as data objects in the centralized NRF increase many folds, thus even if the centralized NRF scaled by creating multiple centralized NRFs, it may result in increased signalling delays which may not be good for catering to service specific requirements. Additionally, any of the NFs that may be collocated at the edge location may be communicating within that edge location without a use of the centralized NRF. Thus, for reducing the signalling delay, an NRF type NF should be present at the edge location. Moreover, a common NRF has to be provided for 6G NFs, 5G NFs, and custom NFs.

[0013] There is, therefore, a need in the art to deploy the NRFs at the edge locations for overcoming the deficiencies of the prior arts. OBJECTS OF THE PRESENT DISCLOSURE

[0014] It is an object of the present disclosure to provide a system and a method to deploy an enhanced Network Repository Function (NRF) for edge locations.

[0015] It is an object of the present disclosure to deploy a common enhanced NRF at the edge locations for 6thGeneration (6G) Network Functions (NFs), 5thGeneration (5G) NFs, and custom NFs, thereby ensuring reduction in latency for NRF signaling.

[0016] It is an object of the present disclosure to distribute NRF data across multiple edge locations (also referred as edge sites), which may provide an ability to manage large volumes of NFs at the edge locations.

[0017] It is an object of the present disclosure to accept more current status parameters from the NFs which are personalized for a specific NF or a specific NF type, with support of accepting on-fly predefined measurement parameters or parameters provided during registration of the NFs.

[0018] It is an object of the present disclosure to ensure that the NFs that needs data for analytical or scaling decision may get the data directly from the enhanced NRF rather than depending on multiple NFs. Thereby, reducing a numberof endpoints to be defined at such NFs and reducing running functions at the NFs which may have been used for gathering of the data.

[0019] It is an object of the present disclosure to provide services for the 6G NFs, the 5G NFs, and the custom NFs providing a convergence of a 5G network and a 6G network. SUMMARY

[0020] In one embodiment, a method for deploying an enhanced Network Repository Function (eNRF) at an edge location in a telecommunications network is disclosed. The method includes registering the eNRF with a centralized Network Repository Function (NRF). The method includes receiving, at the eNRF, a service operation request from a network function (NF). The method includes processing, by the eNRF, the service operation request to determine a type of the service operation request. The type of the service operation request is one of a local service request or a non-local service request. The method includes catering, by the eNRF, the service operation request based on the type of the service operation request.

[0021] In an embodiment, when the type of the service operation request is determined to be the local service request, the method further includes catering, by the eNRF, the service operation request locally.

[0022] In an embodiment, when the type of the service operation request is determined to be the non-local service request, the method further includes forwarding, by the eNRF, the non-local service request to the centralized NRF or an another eNRF; receiving, by the eNRF, a response corresponding to the non- local service request from the centralized NRF or another eNRF; and forwarding, by the eNRF, the response to the NF.

[0023] In an embodiment, the method further includes updating, by the eNRF, a local cache comprising a set of frequently accessed NF profiles based on the response.

[0024] In an embodiment, the method further includes maintaining, by the eNRF, a set of key parameters corresponding to a current running status of each NF registered with the eNRF, in the local cache, and wherein the set of key parameterscomprising a load information, a slice load information, a service load information, and a subscriber information.

[0025] In an embodiment, the method further includes re-building, by the eNRF, the local cache comprising the set of frequently accessed NF profiles after a pre-defined time period.

[0026] In an embodiment, the method further includes providing, by the eNRF, a set of additional parameters to each registered NF for updating the current running status, wherein the set of additional parameters comprises a number of served subscribers, an operation failure rate of each service, and an operation request received for each service.

[0027] In an embodiment, the method further includes connecting, by the eNRF to one or more existing eNRFs or a local NRFs, for exchanging data to continue a service corresponding to the NF during an outage of the centralized NRF.

[0028] In another embodiment, a system for deploying an enhanced Network Repository Function (eNRF) at an edge location in a telecommunications network is disclosed. The system includes a memory and a processing engine communicatively coupled to the memory. The processing engine is configured to register the eNRF with a centralized Network Repository Function (NRF). The processing engine is configured to receive a service operation request from a Network Function (NF). The processing engine is configured to process, by the eNRF, the service operation request to determine a type of the service operation request. The type of the service operation request is one of a local service request or a non-local service request. The processing engine is configured to cater, by the eNRF, the service operation request based on the type of the service operation request.

[0029] In an embodiment, when the type of the service operation request is determined to be the local service request, the processing engine is configured to cater, by the eNRF, the service operation request locally.

[0030] In an embodiment, when the type of the service operation request is determined to be the non-local service request, the processing engine is configured to forward, by the eNRF, the non-local service request to the centralized NRF or ananother eNRF; receive, by the eNRF, a response corresponding to the non-local service request from the centralized NRF or the another eNRF; and forward, by the eNRF, the response to the NF.

[0031] In an embodiment, the processing engine is configured to update, by the eNRF, a local cache comprising a set of frequently accessed NF profiles based on the response.

[0032] In an embodiment, the processing engine is configured to maintain, by the eNRF, a set of key parameters corresponding to a current running status of each NF registered with the eNRF, in the local cache, and wherein the set of key parameters comprising a load information, a slice load information, a service load information, and a subscriber information.

[0033] In an embodiment, the processing engine is configured to re-build, by the eNRF, the local cache comprising the set of frequently accessed NF profiles after a pre-defined time period.

[0034] In an embodiment, the processing engine is configured to provide, by the eNRF, a set of additional parameters to each registered NF for updating the current running status, wherein the set of additional parameters comprises a number of served subscribers, an operation failure rate of each service, and an operation request received for each service.

[0035] In an embodiment, the processing engine is configured to connect, by the eNRF to one or more existing eNRFs or a local NRFs, for exchanging data to continue a service corresponding to the NF during an outage of the centralized NRF.

[0036] In an embodiment, a user equipment (UE) communicatively coupled to a system is disclosed. The UE is configured to send a request to the system (108). The request is sent to deploy an enhanced Network Function Repository (eNRF) at an edge location. The UE is configured to receive a response from the system in response to deploying.

[0037] Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0039] FIG.1 illustrates an exemplary network architecture in which or with which embodiments of the present disclosure may be implemented.

[0040] FIG. 2 illustrates an exemplary block diagram of a system configured for deploying an enhanced Network Repository Function (eNRF) at an edge location in a telecommunications network, in accordance with an embodiment of the present disclosure.

[0041] FIGS. 3A-3F illustrate exemplary process flows implementing a method of deploying the eNRF at the edge location in a telecommunications network, in accordance with an embodiment of the present disclosure.

[0042] FIG. 4 illustrates an exemplary architecture of a system configured for deploying the eNRF at the edge location in a telecommunications network, in accordance with an embodiment of the present disclosure.

[0043] FIG. 5 illustrates an exemplary flow diagram of a method of deploying the eNRF at the edge location in a telecommunications network, in accordance with an embodiment of a present disclosure.

[0044] FIG. 6 illustrates an exemplary computer system in which or with which embodiments of the present disclosure may be implemented. LIST OF REFERENCE NUMERALS100 - Network architecture 102-1, 102-2…102-N - One or more users 104-1, 104-2…104-N - One or more computing devices or user equipments 106 - Network 108 - System for deploying an enhanced Network Repository Function (NRF) at an edge location 200 - Exemplary block diagram 202 – Processor(s) 204 - Memory 206 - Interface(s) 208 – Processing engine(s) 210 - Database 400 - Exemplary architecture 402 - Centralized Network Repository Function (NRF) 404 - eNRF1 406 - eNRF2 408 - eNRF3 410 - eNRF4 412 - eNRF5 414 - Edge Network Functions (NFs) 416 - Local NRFs 418 - Main Data Center NFs 420 - eNRFn 500 - Flow Diagram 600 - Exemplary computer system 610 - External storage device 620 - Bus 630 - Main memory 640 - Read only memory 650 - Mass storage device 660 - Communication port(s)670 - Processor DETAILED DESCRIPTION

[0045] In the following detailed description, a reference is made to the accompanying drawings that form a part hereof, and in which the specific embodiments that may be practiced is shown by way of illustration. These embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments and it is to be understood that other changes may be made without departing from the scope of the embodiments. The following detailed description is therefore not to be taken in a limiting sense.

[0046] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.

[0047] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0048] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not toobscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0049] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0050] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0051] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment.Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0052] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items.

[0053] It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0054] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical, and computing device. The user device is capable of receiving and / or transmitting one or parameters, performing function / s, communicating with other user devices, and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery, and an input-means such as a hard keypad and / or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi,Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.

[0055] Further, the user device may also comprise a “processor” or “processing engine” including a processing unit. The processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital Signal Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.

[0056] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace older generations of wireless technologies. In a field of wireless data communications, a dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in an order of a second generation (2G), a third generation (3G), a fourth generation (4G), and now a fifth generation (5G), and more such generations are expected to continue in the forthcoming time.

[0057] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoingdescriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0058] The disclosure herein addresses challenges in managing and scaling Network Functions (NFs) within telecommunications networks, particularly against a backdrop of an evolving 5G network and an upcoming sixth generation (6G) network. With an increase in both NFs and subscribers (users of user equipments (UEs)), alongside an expansion of the telecommunication networks to encompass more edge locations, the centralized Network Repository Function (NRF) confronts several significant hurdles. Firstly, the centralized NRF may find itself overwhelmed by a vast number of NFs per edge, complicating the fulfilment of a rapidly expanding network's (i.e., a telecommunication network) needs. Secondly, a growth in data objects within the centralized NRF could lead to heightened signalling delays, as merely scaling the centralized NRF across multiple instances may not sufficiently meet a latency demands for specific service operations. Thirdly, a tendency for the NFs located at edge locations (or edge sites) to communicate primarily amongst themselves might render the centralized NRF inefficient, thus leading to unnecessary signalling delays. Lastly, a requirement for a common NRF that supports a varied and developing needs of 6G NFs, 5G NFs, and custom NFs underscores a necessity for a solution that can seamlessly integrate and manage these diverse functions.

[0059] The disclosure presents a solution involving a deployment of an enhanced Network Repository Function (eNRF) at edge locations to mitigate challenges previously outlined. This solution introduces a decentralized approach for managing NFs, working in tandem with the centralized NRF. Key features of this solution include the eNRF's ability to efficiently manage a substantial volume of the NFs at the edge locations, significantly alleviating burden on the centralized NRF and facilitating more scalable and efficient network operations. Additionally, by distributing the centralized NRF data across various edge sites, the eNRF effectively reduces signalling delays and enhances the responsiveness of service- specific operations. The eNRF prioritizes local service request servicing to further diminish latency and dependency on the centralized NRF, offering substantialbenefits for the NFs that primarily engage in internal communication at an edge location. It supports a unified framework for the 6G NFs, the 5G NFs, and the custom NFs, promoting compatibility and streamlined management across diverse generations of NFs. In examples, employing artificial intelligence (AI) (or machine learning (ML) algorithms) algorithms, the eNRF generates a local cache of frequently accessed NF profiles, facilitating rapid data access and minimizing a time needed to reconstruct routing tables. Furthermore, the eNRF delivers a comprehensive interface for the NFs to update their operational status (e.g., a current running status) and measurement parameters, thus enabling real-time data analytics and informed decision-making for network scaling and optimization.

[0060] The present disclosure may deploy the eNRF at one or more edge locations. For cases where communication between two or more eNRFs or the eNRF to localized NRFs is required, a routing table is managed by the centralized NRF. This may limit the purpose of the centralized NRF for routing of NRF requests to a correct eNRF or local NRFs. To overcome this, the eNRF may communicate with the centralized NRF in an asynchronous mode via an eNRF- NRF interface. This may be done during registration of new NRFs and may be used by the centralized NRF to build the routing table for a specific new NRF based on associated key parameters which include, but not limited to, a Public Land Mobile Network (PLMN), a Standalone Non-Public Network (SNPN), Tracking Area Code (TAC), a NF type, a service, a slice, a priority, a locality, etc. This may limit the information that needs to be communicated by the eNRF to the centralized NRF and may help in auto building of the routing tables.

[0061] The eNRF may serve a service operation request locally without forwarding the request towards the centralized NRF, in case if the eNRF has to serve the service operation request locally.

[0062] The eNRF may also create a localized limited cache (i.e., a local cache) of NF profiles that are regularly accessed by the NFs registered at the eNRF using the AI algorithms with a specific validity time (or a pre-defined time period) after which it may need to rebuild a frequent visited table of the NFs profile again using a communication via the centralized NRF to one or more other eNRF or localNRFs.

[0063] The eNRF may also store specific key parameters, such as a load information, a slice load information, a service load information, and a subscriber information, and additional parameters, such as a number of served subscribers, an operation failure rate of each service, and an operation request received for each service, etc., corresponding to each specific NF which may be reported to the eNRF using Application Programming Interfaces (APIs). These parameters may be stored at the local cache of the eNRF and may be fetched by various other NFs including analytics NFs as well as NFs that need more information for making a scaling decision, or changing a routing table, or changing Quality of Service (QoS) parameters, etc.

[0064] Other 6G NFs, 5G NFs, and custom NFs may be able to use various services that may be offered by the eNRF including, but not limited to, management, discovery, access token, bootstrap, etc., as per the flow requirements. In addition, the 6G NFs, the 5G NFs, and the custom NFs may also be able to use and define custom services.

[0065] The various embodiments of the present disclosure will be explained in detail with reference to FIGs.1 to 6.

[0066] FIG.1 illustrates an exemplary network architecture (100) in which or with which embodiments of the present disclosure may be implemented.

[0067] Referring to FIG.1, the network architecture (100) may include one or more computing devices or user equipments (104-1, 104-2…104-N) associated with one or more users (102-1, 102-2…102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2…102- N) may be individually referred to as the user (102) and collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more user equipments (104-1, 104-2…104-N) may be individually referred to as the user equipment (104) and collectively referred to as the user equipment (104). A person of ordinary skill in the art will appreciate that the terms “computing device(s)” and “user equipment” may be used interchangeably throughout the disclosure. Although three user equipments (104) are depicted in FIG. 1, howeverany number of the user equipments (104) may be included without departing from the scope of the ongoing description.

[0068] In an embodiment, the user equipment (104) may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the user equipment (104) may include, but is not limited to, smart phones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users (102) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the user equipment (104) may include, but is not limited to, intelligent, multi-sensing, network-connected devices, that can integrate seamlessly with each other and / or with a central server or a cloud-computing system or any other device that is network-connected.

[0069] In an embodiment, the user equipment (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device(e.g., a head- mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of a computer device with wireless communication capabilities, and the like. In an embodiment, the user equipment (104) may include, but is not limited to, any electrical, electronic, electro-mechanical, or an equipment, or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device, wherein the user equipment (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, amicrophone, a keyboard, and input devices for receiving input from the user (102) or an entity (110) such as touch pad, touch enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the user equipment (104) may not be restricted to the mentioned devices and various other devices may be used.

[0070] In an embodiment, the user equipment (104) is configured to communicate with a system (108), for example, a system for deploying an eNRF at edge locations, through a network (106). The system (108) may deploy a common enhanced NRF at the edge locations for 6G NFs, 5G NFs, and custom NFs, thereby ensuring reduction in a latency for NRF signaling. The system may distribute enhanced NRF data across multiple edge locations (also referred as edge sites), which may provide ability to manage large volumes of NFs at the edge locations.

[0071] In an embodiment, the network (106) may include at least one of a 5G network, 6G network, or the like. The network (106) may enable the user equipment (104) to communicate with other devices in the network architecture (100) and / or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), an Internet, a Public Switched Telephone Network (PSTN), or the like.

[0072] In another exemplary embodiment, the centralized server (112) may include or comprise, by way of example but not limitation, one or more of: a stand- alone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof.

[0073] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) mayinclude fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0074] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) configured for deploying the eNRF at the edge locations in a telecommunications network, in accordance with an embodiment of the present disclosure. The telecommunication network may correspond to a 5G network, a 6G network, and the like. FIG.2 is explained in conjunction with FIG.1.

[0075] In an aspect, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data (i.e., data packets) over a network service. The memory (204) may comprise any non-transitory storage device including, for example, a volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read-Only Memory (EPROM), a flash memory, and the like.

[0076] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices, referred to as I / O devices, storage devices, and the like. The interface(s) (206) may facilitate communication of the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a processing engine (208) and a database (210).

[0077] The processing engine (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non- transitory machine-readable storage medium and the hardware for the processing engine (208) may include a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine- readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine (208). In such examples, the system (108) may include the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine- readable storage medium may be separate but accessible to the system (108) and the processing resource. In other examples, the processing engine (208) may be implemented by an electronic circuitry.

[0078] In an embodiment, the processing engine (208) may include one or more engine(s). The processing engine (208) may communicate with the centralized NRF in an asynchronous mode via an eNRF-NRF interface. This may be done during registration of new NRFs and may be used by the centralized NRF to build the routing table for a specific new NRF based on associated key parameters which include, but not limited to, the PLMN, the SNPN, the TAC, the NF type, the service, the slice, the priority, the locality, etc. This may limit the information that needs to be communicated by the eNRF to the centralized NRF and may help in auto building of the routing tables.

[0079] In an embodiment, the database (210) may include data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor(s) (202), the processing engine (208), or the system (108).

[0080] Although FIG. 2 shows an exemplary block diagram (200) of the system (108), in other embodiments, the system (108) may include fewercomponents, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).

[0081] FIGS. 3A-3F illustrate exemplary process flows implementing a proposed method of deploying the eNRF at the edge locations in the telecommunications network, in accordance with an embodiment of the present disclosure. FIGS.3A – 3F are explained in conjunction with FIGS.1 – 2.

[0082] In FIGS.3A-3F, the method may include providing a common eNRF from which each edge NF (i.e., the NF) such as a 5G NF, a 6G NF, and a custom NF may use management / discovery / access token / bootstrap services based on predefined flows. The method may also define new custom NFs and custom services that may be consumed based on a Service Based Interface (SBI).

[0083] The eNRF may connect with predefined centralized NRFs (based on NF set configurations) or may use a Domain Name System (DNS) discovery to get the centralized NRF end points. The eNRF may register with the centralized NRF which may intimate the centralized NRF to start building the routing table for the eNRF.

[0084] When a NF registers at the eNRF, the eNRF may communicate with the centralized NRF to provide the specific NF information for the registered NF. The centralized NRF may automatically start updating the routing table based on information received from the eNRF.

[0085] When the eNRF receives a service operation request like discovery / subscribe / access token / bootstrapping, etc., from the registered NF, the eNRF may check if the service operation request may be catered locally. If yes, the eNRF may cater the service operation request locally. In case, if the eNRF may not serve the service operation request locally, then the eNRF may forward the service operation request to the centralized NRF which may forward to the registered eNRF or a local NRF based on the routing table built by the centralized NRF. A local NRF or an another NRF in the telecommunication network which serves the service operation request may also provide a target Uniform Resource Identifier (URI) tothe eNRF for catering to a future similar service operation request along with an appropriate timestamp (e.g., 2 days) for which the target Uniform Resource Locator (URL) may be valid.

[0086] Upon receipt of a response, the eNRF is configured to relay this response to the NF that initiated the service operation request. Additionally, the eNRF undertakes two further actions to enhance network management and resilience. Firstly, the AI algorithms within the eNRF commence data collection activities. A scope of data acquisition may encompass various parameters, including a nature of the data requested by the NF, an identity of the eNRF or a target NRF (i.e., the local NRF) which processed the service operation request, a profile information of the target NRF along with a frequency at which local NFs utilize this data. This collected data is then subject to analysis by the eNRF with an objective of constructing and updating intelligent data tables. Such data tables prove critical in scenarios where the centralized NRF is inaccessible, whether due to network disruptions or outages affecting other eNRFs.

[0087] A second action involves the eNRF storing detailed endpoint information of the target eNRF that serviced the request. This stored information is crucial for future instances where direct communication with the target eNRF may be necessary, thereby allowing the eNRF to establish direct reachability without a need to traverse the centralized NRF. This mechanism not only bolsters an efficiency of network operations but also ensures continuity of a service in an event of failure of the centralized NRF.

[0088] Further, the eNRF may provide the set of additional parameters support that may be used by the NF to update the current running information. For example, the set of additional parameters may include a number of served subscribers, an operation failure rate of each service, and an operation request received for each service, etc. The set of additional parameters may be updated by the NF in a local cache based on a local NF configuration. In addition, the NF may also provide an array of current running status information in NFUpdate operation that may be stored as a plain JavaScript Object Notation (JSON) array object with current measurement parameters (i.e., the set of key parameters, such as, a load, aslice load, a service load and a subscriber information associated with the NF) and corresponding value pair usage. The NF while registering may use these measurement parameters to be reported as a one-dimensional array to the eNRF which may be read by the eNRF and may be stored by creating a NF profile correspond to the NF. These measurement parameters may be used for discovery / subscribe condition specific action as per need. This may provide large flexibility for the data that needs to be gathered by analytics and scaling NFs. This is because, the analytics and scaling NFs that needs to perform analytics and scaling decision may gather the data directly from the eNRF rather than depending on multiple NFs, reducing overall functional load of the multiple NFs.

[0089] The eNRF may also maintain a profile for self and may internally update its own measurement parameters (e.g., a latency, a throughput, a resource utilization, a cache hit rate, etc.) that may also be used by the NFs needing to make analytical or scaling decision.

[0090] Individual service operation may be divided into microservices and may be deployed at same edge location or may further be distributed across as per need. Further, the eNRF may be able to share the microservices with an another eNRF. For example, Register / NFUpdate of two eNRF may be different but discovery may use a shared microservice.

[0091] FIG.3A to FIG.3F are now described in more detail hereinafter. In FIG. 3A, a process flow (300A) illustrates a communication sequence between eNRFs (302A), a Local NRF (304A), and a centralized NRF (306A). The process flow (300A) begins, at step (308A), when the eNRF (302A) sends a request that may include a registration request, an updation request, a deregistration request, a list retrieval request, or a NF profile retrieval request to the centralized NRF (306A). At step (310A), the centralized NRF (306A) returns a response to the eNRFs (302A). In a similar manner, the request, i.e., the registration request, the updation request, the deregistration request, the list retrieval request, or the profile retrieval request may be sent by the Local NRF (304A) to the centralized NRF (306A) at step (312A). Upon processing these requests, the centralized NRF (306A) delivers a response back to the Local NRF (304A) at step (314A). The depicted process flow(300A) emphasizes a hierarchical communication protocol designed to manage and update NF profiles across different levels of network repository functions within the telecommunications network.

[0092] In FIG. 3B, a process flow (300B) depicting a communication sequence between edge NFs (302B), the eNRF (302A), and the centralized NRF (306A). The process flow (300B) initiates at step (304B) when the edge NFs (302B) sends a registering request to the eNRF (302A). It should be noted that, the eNRF (302A) is registered at the centralized NRF (306A). Upon receiving the registering request, at step (306B), the eNRF (302A) may create and store a NF profile corresponding to the edge NFs (302B) from which the registering requests are received. Upon registration, at step (308B) the eNRF (302A) performs an asynchronous custom update with information corresponding to the edge NFs (302B), a procedure in which it communicates relevant NF profile data of each of the edge NFs (302B) to the centralized NRF (306A). The centralized NRF (306A), upon receipt of this NF profile data, is responsible for constructing a routing table based on the information received from the eNRF (302A) at step (310B). This routing table is essential for directing communication within the telecommunications network. Subsequent to these interactions, a response is transmitted back down a chain: first from the Centralized NRF (306A) to the eNRF (302A) at step (312B), and then from the eNRF (302A) to the edge NFs (302B) at step (316B). This process flow (300B) ensures that NF profile information is accurately stored and disseminated, allowing for an efficient operation and management of the telecommunication network.

[0093] In FIG.3C, a process flow (300C) depicts a communication between the edge NFs (302B) and the eNRF (302A). The process flow (300C) starts at step (302C), when the edge NFs (302B) sends a discovery / access token / bootstrapping request (i.e., the service operation request) to the eNRF (302A). The eNRF (302A), upon receipt of the service operation request, makes a local decision to determine the type of the service operation request, at step (304C). In other words, the eNRF (302A) may check if the service operation request can be fulfilled locally. When the type of the service operation request is determined to be the type of the localservice request, the eNRF (302A) proceeds to serve the service operation request in a local domain. Consequently, the eNRF (302A) sends a response to the edge NFs (302B), at step (306C), completing the service operation request. The FIG. 3C emphasizes a capability of the eNRF (302A) to autonomously handle service operation requests without a need to escalate to the centralized NRF (306A), thereby improving operational efficiency and reducing the latency in the network's response to servicing the service operation request.

[0094] In FIG. 3D, a process flow (300D) a communication flow between the edge NFs (302D) (same as the edge NFs (302B)), two eNRFs, i.e., an eNRF1 (304D) and an (eNRF2) (308D), and a centralized NRF (306D) (same as the centralized NRF (306A)). The process flow (300D) initiates at step (310D) with the edge NFs (302D) sending a request (i.e., the service operation request), such as, a discovery request, an access token request, a bootstrapping request to the eNRF1 (304D). At step (312D), the eNRF1 (304D) determined whether the type of the service operation request is the local service request or the non-local service operation request. Upon evaluation of the service operation request by the eNRF1 (304D) guided by a local decision-making process and determining the service operation request to be the non-local service request, at step (314D), the eNRF1 (304D) forwards the service operation request to the centralized NRF (306D).

[0095] Upon receipt of the forwarded service operation request, at step (316D), the centralized NRF (306D) makes a determination based on its local routing table to further forward the service operation request to the eNRF2 (308D) as depicted via step (318D). Upon receiving the service operation request, at step (320D), the eNRF2 (308D) makes an independent local decision. If the service operation request matches with existing service operation requests served by the eNRF2 (308D), then the eNRF2 (308D) will process the service operation request; if no match is found, the service operation request is rejected by the eNRF2 (308D) as the centralized NRF (306D) had forwarded it. Further, either of a generated response (i.e., a response generated based on processing of the service operation request or the reject response) is cascaded back to the edge NFs (302D), flowing from the eNRF2 (308D) to the centralized NRF (306D) as depicted via step (322D),from the centralized NRF (306D) to the eNRF1 (304D) as depicted via step (324D), and subsequently from the eNRF1 (304D) to the edge NFs (302D) as depicted via step (326D). In addition, at step (328D), an AI engine implementing the one or more AI algorithms that is present in the eNRF1 (304D) is configured to update the local cache of the eNRF1 with the generated response for reusing it in future, upon receiving same service operation request. In addition, the AI engine also manages the NF profiles within the local cache for reuse if needed at future instances when the same service operation request or a different service operation request is received from a same NF or a different NF. This process flow (300D) underscores a distributed nature of the telecommunication network, where local caching by the eNRFs and decision-making at various network levels contribute to efficient NF and resource optimization.

[0096] In FIG. 3E, a process flow (300E) depicts a communication flow between an edge NF (302D-1) (i.e., one NF of the edge NFs (302D)), two eNRFs, i.e., the eNRF1 (304D) and the eNRF2 (308D), and the centralized NRF (306D). The process flow (300E) begins at step (302E) when the edge NF (302D-1) sends a subscribe request (i.e., the service operation request) to the eNRF1 (304D). At step (304E), the eNRF1 (304D) may process the subscribe request to determine the type of the subscribe request. When the type of the subscribe request is determined to be the non-local service request, at step (306E), the eNRF1 (304D) elects to forward this subscribe request to the centralized NRF (306D). At step (308E), the centralized NRF (306D) process the subscribe request to determine an appropriate course of action. Further, after determining the appropriate course of action based on its local routing table, at step (310E), the centralized NRF (306D) forwards the subscribe request to the eNRF2 (308D).

[0097] At step (312E), after making a local decision, the eNRF2 (308D) chooses to either serve the subscribe request or reject it; a rejection occurs if no existing service operation requests matches with the subscribe request as the request was forwarded by the centralized NRF (306D). Suppose the eNRF2 decides to serve the subscribe request, in this case, a response containing a subscription ID (e.g., a subscription D1) and a location of a target NRF serving the subscribe request(identified here as NRF3) is sent back flowing from the eNRF2 (308D) to the centralized NRF (306D) as depicted via step (314E), and from the centralized NRF (306E) to the eNRF1 (304E) as depicted via step (316E), which then relays it back to the edge NF (302D-1) as depicted via step (318E). Additionally, at step (320E), the edge NF (302D-1) issue a subscribe patch or unsubscribe action for the subscription D1 to the eNRF2 (308D). Further, at step (322E) the eNRF2 (308D) provides a corresponding response to the edge NF (302D-1) for the subscribe patch or unsubscribe action. The process flow (300E) illustrates a multi-tiered nature of subscription management within the telecommunication network, showcasing a distributed interaction model that enhances responsiveness and network efficiency.

[0098] In FIG. 3F, the process flow (300F) diagram depicts a communication process involving the edge NFs (302B), the eNRF (302A), and analytics NFs (302F). At step (304F), the edge NFs (302B) initiate the process flow (300F) by transmitting a request including a Register / Heartbeat / Update message including information associated with the edge NFs (302B) to the eNRF (302A). Upon receipt of this message, at step (306F), the eNRF (302A) processes the information and performs additional functions such as checking custom measurement attributes (i.e., the set of key parameters) provided in an array, thereafter, storing these values within the array for access by other NFs within the telecommunication network.

[0099] Subsequently, at step (308F), the eNRF (302A) issues a notification to the Analytics NFs (302F), which may contain relevant data or alerts based on measurements attributes received from the edge NFs (302A). Further, at step (310F) the eNRF (302A) sends a response to the edge NFs (302B) confirming a completion of the request. This process flow (300F) illustrates the eNRF (302A) role in not only managing the registration and state updates of the edge NFs (302B) but also in facilitating a sharing of pertinent data with analytical components of the telecommunication network to inform further processing or decision-making.

[0100] FIG. 4 illustrates an exemplary architecture (400) of the system (108) configured for deploying the eNRFs at the edge locations in the telecommunications network, in accordance with an embodiment of the presentdisclosure. FIG.4 is explained in conjunction with FIGS.1 – 3F.

[0101] In FIG. 4, the system (108) may include a centralized NRF (402), and one or more edge NFs (also referred as the NFs). The system (108) may deploy NRFs at edge location which may be called as an enhanced NRF or eNRF at the edge locations, ensuring reduction in the latency for the NRF signaling. Common eNRF may be deployed for the 6G NFs, the 5G NFs and the custom NFs. The system (108) may distribute NRF data across multiple edge locations, which may provide ability to manage large volumes of the NFs at the edge locations, rather than locating all data for the NFs at centralized NRF clusters. With increase in database sizes at centralized locations, there may be internal latency introduced for handling the NRF specific service operations. With the eNRFs, smaller scale NFs may remain feasible while controlling the latency that is introduced due to heavier NFs in the telecommunication network. The eNRFs may provide services for the 6G NFs, the 5G NFs, and the custom NFs providing a convergence of the 5G network and the 6G network.

[0102] More specifically, in FIG. 4, the architecture (400) depicts the hierarchical and distributed relationship between various network repository functions within the telecommunications network. At the core of this architecture lies a centralized NRF (402) (same as the centralized NRF (306D)), which serves as a pivotal node for managing NFs across the telecommunication network.

[0103] Surrounding the centralized NRF (402) are multiple eNRFs labeled as an eNRF1 (404), an eNRF2 (406), an eNRF3 (408), an eNRF4 (410), and an eNRF5 (412), each connected to the centralized NRF (402) and responsible for localized management of edge Network Functions (NFs) (414) (same as the edge NFs (302B)). These eNRFs (i.e., the eNRF1 (404), the eNRF2 (406), the eNRF3 (408), the eNRF4 (410), and the eNRF5 (412)) (same as the eNRFs (302A)) provide a decentralized approach to managing the NFs (414), enabling efficient scaling and reduced latency by handling NFs registrations and operations closer to a edge location of the telecommunication network where data is generated and consumed.

[0104] Additionally, the architecture (400) integrates local NRFs (416) (same as the local NRF (304A)) which interface with a main data center NFs (418),facilitating communication and management between the centralized NRF (402) and edge components (i.e., the eNRFs (404, 406), (408), (410), (412)) of the telecommunication network. A final element in this architecture is an eNRFn (420), symbolizing a potential scalability of the telecommunication network with additional eNRFs to be deployed as needed. Each eNRF is designed to interoperate within this ecosystem, ensuring that network operations are streamlined across both central and edge domains of a telecommunication network infrastructure. This configuration illustrates a flexibility and an efficiency of telecommunication network's design, capable of adapting to dynamic requirements of the 5G network and the 6G network.

[0105] FIG. 5 illustrates an exemplary flow diagram of a method (500) of deploying an enhanced Network Repository Function (eNRF) at edge locations in a telecommunications network, in accordance with an embodiment of the present disclosure. FIG.5 is explained in conjunction with FIGS.1 – 4.

[0106] In order to deploy the eNRF at an edge location, initially at step 502, the eNRF is registered with a centralized NRF (same as the centralized NRF 402). In particular, registering the eNRF with the centralized NRF involves a process by which the eNRF communicates associated information such as, an availability (e.g., 5G network services, IOT services, a network slicing, etc), capabilities (e.g., frequency bands, a throughput a coverage, etc.), and a current status (e.g., an operational state, a load and capacity, a health and performance, etc.) to the centralized NRF entity within the telecommunications network. Upon receiving the information associated with the eNRF, the centralized NRF start building the routing table for the eNRF.

[0107] Once the eNRF is registered at the centralized NRF, at step 504, a service operation request is received by the eNRF from a NF. The NF may correspond to the edge NF 302D-1. Upon receiving the service operation request, at step 506, the service operation request is processed by the eNRF to determine a type of the service operation request. In an embodiment, the type of the service operation request is one of a local service request or a non-local service request. Further, upon determining the type of the service operation request, at step 508, theservice operation request is catered by the eNRF based on the type of the service operation request.

[0108] In one embodiment, when the type of the service operation request is determined to be the local service request, the service operation request is catered locally by the eNRF. In other words, when the service operation request is the local service request, the eNRF may handle and fulfil the service operation request internally by leveraging its information and capabilities to execute the service operation request. In another embodiment, when the type of the service operation request is determined to be the non-local service request, the eNRF forwards the non-local service request to the centralized NRF or an another eNRF. Further, in response to forwarding the non-local service request, the eNRF receives a response corresponding to the non-local service request from the centralized NRF or an another eNRF in the telecommunications network. Further, the eNRF forwards the response to the NF to fulfil the service operation request.

[0109] The eNRF is configured to update a local cache (i.e., a local memory) based on the response. The local cache is updated based on the response using, for example, one or more Artificial Intelligence (AI) algorithms. The local cache includes a set of frequently accessed NF profiles. Example of the one or more AI algorithms may include, but are not limited to, a reinforcement learning algorithm, a Q-learning algorithm, and a Deep Q-network. In an embodiment, a NF profile of the set of frequently accessed NF profiles corresponds to a NF profile that are accessed often within the telecommunications network. The NF profile typically contains information about NFs, their configurations, capabilities, and other relevant metadata. The NF profile is accessed frequently because it is either commonly used across various services or is critical for specific network operations. In other words, updating the local cache by the eNRF involves analyzing the response and determining which NF profiles are frequently accessed the one or more AI algorithms. These one or more AI algorithms analyses the response and prioritize NF profiles based on usage patterns, ensuring the local cache reflects current and relevant NF data associated with the NF profiles for efficient service delivery within the telecommunication network. In an embodiment, theeNRF is configured to re-build the local cache including the set of frequently accessed NF profiles after a pre-defined time period (e.g., after every 30 days). In other words, the eNRF is configured to periodically reconstruct its local cache containing the set of frequently accessed NF profiles, for example, after every 30 days. In some embodiments, each of the set of NF functions profile maintained by the eNRF is used by one or more NFs needing to make analytical or scaling decision.

[0110] In addition, the eNRF is configured to maintain a set of key parameters corresponding to a current running status of each NF registered with the eNRF, in the local cache. The set of key parameters includes a load information, a slice load information, a service load information, and a subscriber information. Further, the eNRF is configured to provide a support of a set of additional parameters to each registered NF for updating the current running status. The set of additional parameters includes a number of served subscribers, an operation failure rate of each service, and an operation request received for each service. The set of parameters may be representative of status. Based on the set of additional parameters, the current running status may be updated. For example, if the status is passive, and the set of parameters, for example, the load information says moderate load, then the current running status may be changed to active.

[0111] The eNRF is also configured to connect to one or more existing eNRFs or a local NRFs in the telecommunication network, for exchanging data to continue a service corresponding to the NF during an outage of the centralized NRF. In this context, the outage of the centralized NRF refers to a situation where the centralized NRF responsible for managing and coordinating operations, becomes unavailable or inaccessible. This outage could be due to the network disruptions, hardware failures, maintenance issues, or similar other factors that prevent the eNRF from accessing the centralized server.

[0112] FIG. 6 illustrates an exemplary computer system (600) in which or with which embodiments of the present disclosure may be implemented. As shown in FIG.6, the computer system (600) may include an external storage device (610), a bus (620), a main memory (630), a read only memory (640), a mass storage device(650), a communication port(s) (660), and a processor (670). A person skilled in the art will appreciate that the computer system (600) may include more than one processor (670) and communication ports (660). The processor (670) may include various modules associated with embodiments of the present disclosure.

[0113] In an embodiment, the communication port(s) (660) may be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) (660) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects.

[0114] In an embodiment, the memory (630) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor (670).

[0115] In an embodiment, the mass storage (650) may be any current or future mass storage solution, which may be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).

[0116] In an embodiment, the bus (620) communicatively couples the processor (670) with the other memory, storage and communication blocks. The bus (620) may be, e.g., a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (670) to the computer system (600).

[0117] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (620) to support direct operator interaction with the computer system (600). Other operator and administrative interfaces may be provided through network connections connected through the communication port(s) (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.

[0118] While the foregoing describes various embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof. The scope of the present disclosure is determined by the claims that follow. The present disclosure is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the present disclosure when combined with information and knowledge available to the person having ordinary skill in the art.

[0119] The present disclosure provides technical advancement related to managing large volumes of NFs at edge locations. This advancement addresses the limitations of existing solutions by deploying of an eNRF at the edge locations in a telecommunication network. The disclosure involves configuring registering the eNRF with a centralized NRF, which offer significant improvements in reduction in a latency for NRF signaling, enabling a faster response time, reducing a number of endpoints to be defined at such NFs and reducing running functions at the NFs which may have been used for gathering of data, providing a convergence of a 5G architecture and a 6G architecture, enhancing reliability and fault tolerance of the telecommunication network, etc. ADVANTAGES OF THE PRESENT DISCLOSURE

[0120] The present disclosure provides a system and a method to deploy an enhanced Network Repository Function (NRF) at edge locations in a telecommunication network.

[0121] The present disclosure deploys a common enhanced NRF at the edge locations for 6thGeneration (6G) Network Functions (NFs), 5thGeneration (5G) NFs, and custom NFs, thereby ensuring reduction in a latency for NRF signaling.

[0122] The present disclosure distributes NRF data across multiple edge locations (also referred as edge sites), which may provide an ability to manage large volumes of NFs at the edge locations.

[0123] The present disclosure accepts more current status parameters from the NFs which are personalized for a specific NF or a specific NF type, with support of accepting on-fly predefined measurement parameters or parameters provided during registration of the NFs.

[0124] The present disclosure ensures that the NFs that need data for analytical or scaling decision may get the data directly from the enhanced NRF rather than depending on multiple NFs. Thereby, reducing a number of endpoints to be defined at such NFs and reducing running functions at the NFs which may have been used for gathering of the data.

[0125] The present disclosure provides services for the 6G NFs, the 5G NFs, and the custom NFs providing a convergence of a 5G architecture and a 6G architecture.

Claims

We claim:

1. A method (500) for deploying an enhanced Network Repository Function (eNRF) at an edge location in a telecommunications network, the method comprising: registering (502) the eNRF with a centralized Network Repository Function (NRF); receiving (504), by the eNRF, a service operation request from a network function (NF); processing (506), by the eNRF, the service operation request to determine a type of the service operation request, wherein the type of the service operation request is one of a local service request or a non-local service request; and catering (508), by the eNRF, the service operation request based on the type of the service operation request.

2. The method (500) as claimed in claim 1, wherein, when the type of the service operation request is determined to be the local service request, catering, by the eNRF, the service operation request locally.

3. The method (500) as claimed in claim 1, wherein, when the type of the service operation request is determined to be the non-local service request: forwarding, by the eNRF, the non-local service request to the centralized NRF or an another eNRF; receiving, by the eNRF, a response corresponding to the non-local service request from the centralized NRF or the another eNRF; and forwarding, by the eNRF, the response to the NF.

1. The method (500) as claimed in claim 3, further comprising: updating, by the eNRF, a local cache comprising a set of frequently accessedNF profiles based on the response 2. The method (500) as claimed in claim 4, further comprising: maintaining, by the eNRF, a set of key parameters corresponding to a current running status of each NF registered with the eNRF, in the local cache, and wherein the set of key parameters comprising a load information, a slice load information, a service load information, and a subscriber information.

3. The method (500) as claimed in claim 4, further comprising: re-building, by the eNRF, the local cache comprising the set of frequently accessed NF profiles after a pre-defined time period.

4. The method (500) as claimed in claim 5, further comprising: providing, by the eNRF, a set of additional parameters to each registered NF for updating the current running status, wherein the set of additional parameters comprises a number of served subscribers, an operation failure rate of each service, and an operation request received for each service.

5. The method (500) as claimed in claim 1, further comprising: connecting, by the eNRF to one or more existing eNRFs or a local NRFs, for exchanging data to continue a service corresponding to the NF during an outage of the centralized NRF.

6. A system (108) for deploying an enhanced Network Repository Function (eNRF) at an edge location in a telecommunications network, the system (108) comprising: a memory (204); and a processing engine (208) communicatively coupled to the memory (204), configured to: register (502) the eNRF with a centralized Network Repository Function (NRF);receive (504), by the eNRF a service operation request from a Network Function (NF); process (506), by the eNRF, the service operation request to determine a type of the service operation request, wherein the type of the service operation request is one of a local service request or a non-local service request; and cater (508), by the eNRF, the service operation request based on the type of the service operation request.

7. The system (108) as claimed in claim 9, wherein, when the type of the service operation request is determined to be the local service request, the processing engine (208) is configured to cater, by the eNRF, the service operation request locally.

8. The system (108) as claimed in claim 9, wherein, when the type of the service operation request is determined to be the non-local service request, the processing engine (208) is configured to: forward, by the eNRF, the non-local service request to the centralized NRF or an another eNRF; receive, by the eNRF, a response corresponding to the non-local service request from the centralized NRF or the another eNRF; and forward, by the eNRF, the response to the NF.

9. The system (108) as claimed in claim 11, wherein the processing engine (208) is configured to: update, by the eNRF, a local cache comprising a set of frequently accessed NF profiles based on the response.

10. The system (108) as claimed in claim 12, wherein the processing engine (208) is further configured to:maintain, by the eNRF, a set of key parameters corresponding to a current running status for each NF registered with the eNRF, in the local cache, wherein the set of key parameters comprising a load information, a slice load information, a service load information, and a subscriber information.

11. The system (108) as claimed in claim 12, wherein the processing engine (208) is further configured to: re-build, by the eNRF, the local cache comprising the set of frequently accessed NF profiles after a pre-defined time period.

12. The system (108) as claimed in claim 13, wherein the processing engine (208) is further configured to: provide, by the eNRF, a set of additional parameters to each registered NF for updating the current running status, wherein the set of additional parameters comprises a number of served subscribers, an operation failure rate of each service, and an operation request received for each service.

13. The system (108) as claimed in claim 13, wherein the processing engine (208) is further configured to: connect, by the eNRF to one or more existing eNRFs or a local NRFs, for exchanging data to continue a service corresponding to the NF during an outage of the centralized NRF.

14. A user equipment (UE) communicatively coupled to a system (108), configured to: send a request to the system (108), wherein the request is sent to deploy an enhanced Network Function Repository (eNRF) at an edge location; and receive a response from the system (108) in response to deploying.

15. A computer program product comprising a non-transitory computer- readable medium comprising instructions that, when executed by one or moreprocessors, cause the one or more processors to: register (502) the eNRF with a centralized Network Repository Function (NRF); receive (504), at the eNRF, a service operation request from a network function (NF); process (506), by the eNRF, the service operation request to determine a type of the service operation request, wherein the type of the service operation request is one of a local service request or a non-local service request; and cater (508), by the eNRF, the service operation request based on the type of the service operation request.

Images