DESC:FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
The Patent Rules, 2003
COMPLETE SPECIFICATION
(See section 10 & rule 13)
1. TITLE OF THE INVENTION

SYSTEM AND METHOD FOR PERFORMING AUTHENTICATION AND AUTHORIZATION OF SUBSCRIBERS AT EDGE OF A NETWORK
2. APPLICANT (S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED IN Office-101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi,
Ahmedabad - 380006, Gujarat, India.
3. PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the invention and the manner in which it is to be performed.

RESERVATION OF RIGHTS
[0002] 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 (hereinafter 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.
FIELD OF THE DISCLOSURE
[0003] The embodiments of the present disclosure generally relate to the field of subscriber data management. In particular, the present disclosure relates to systems and methods for performing authentication and authorization of subscribers at edge of a network.
DEFINITION
[0004] 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.
[0005] eNF (Edge Network Function) refers to a network function deployed at the edge of a network to handle various operations, including initial registration requests from subscribers.
[0006] eUDR (Enhanced Unified data repository) refers to a specialized data repository deployed at the network edge to store and manage subscriber data locally.
[0007] eNRF (Enhanced Network Repository Function) refers to a function that facilitates communication between edge components and centralized components of the network.
[0008] cUDR (Centralized Unified data repository) refers to a central repository that stores comprehensive subscriber data and synchronizes with eUDRs as needed.
[0009] cNRF (Centralized Network Repository Function) refers to a centralized function that manages repository functions and responds to queries from eNRFs.
[0010] SUPI (Subscription Permanent Identifier) refers to a unique identifier assigned to each subscriber, used to retrieve correct subscriber information.
[0011] OSS (Operation Support Systems) refers to systems that ensure smooth network operation and efficient resource utilization.
[0012] BSS (Business Support Systems) refers to systems used in conjunction with OSS to support various end-to-end telecommunications services.
[0013] PLMN (Public Land Mobile Network) refers to a network established and operated by an administration or by a recognized operating agency for the specific purpose of providing land mobile telecommunications services to the public.
[0014] mTLS (Mutual Transport Layer Security) refers to a security protocol that provides mutual authentication between two parties communicating over a network.
[0015] HTTP2 (Hypertext Transfer Protocol 2) refers to a major revision of the HTTP network protocol used by the World Wide Web, designed for improved performance and security.
[0016] OAuth (Open Authorization) refers to an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.
[0017] IoT (Internet of Things) refers to the interconnected network of physical devices, vehicles, home appliances, and other items embedded with electronics, software, sensors, and network connectivity which enables these objects to collect and exchange data.
[0018] mMTC (Massive Machine Type Communication) refers to a service category in 5G networks designed to support a very large number of connected devices that typically transmit a relatively low volume of non-delay-sensitive data.
[0019] cMTC (Critical Machine Type Communication) refers to a service category in 5G networks designed to meet the requirements of ultra-reliable, low latency communications for mission-critical applications.
BACKGROUND OF THE DISCLOSURE
[0020] 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.
[0021] The evolution of mobile networks from 1G to 5G has ushered in unprecedented advancements in connectivity, data speeds, and network capabilities. This progression has not only enabled a myriad of new applications and services but has also given rise to complex challenges in network management and subscriber data handling.
[0022] Central to the 5G network architecture is the Network Repository Function (NRF), a critical component that serves as a repository for network function profiles. The NRF facilitates service consumers in discovering and selecting appropriate service providers within the network ecosystem. However, with the exponential growth in edge computing and the deployment of numerous Network Functions (NFs) at edge locations, centralized NRFs are increasingly strained, struggling to efficiently manage the sheer volume of the distributed NFs.
[0023] Subscriber Data Management (SDM) emerges as a cornerstone of 5G network architecture, encompassing the intricate processes of storing, retrieving, and managing subscriber-related information crucial for seamless network operations. The SDM encompasses two pivotal components: the Unified Data Management (UDM) and the Unified data repository (UDR). The UDM is tasked with the complex responsibilities of authentication, authorization, and user profile management, while the UDR serves as the central repository for storing and managing user-related data.
[0024] Concurrent with these developments, the Internet of Things (IoT) has revolutionized device interconnectivity, presenting both opportunities and challenges for network infrastructure. 5G networks, with their promise of ultra-low latency, high data rates, and massive connection density, are positioned as the ideal substrate for diverse and demanding IoT applications. In this context, SDM plays a crucial role in ensuring secure onboarding, authentication, and authorization of myriad IoT devices, while also facilitating efficient management of device-specific information and configurations.
[0025] The convergence of these factors, the proliferation of cellular users, the explosion of massive IoT (mIoT) devices, and the increasing sophistication of network services has led to unprecedented loads on core network infrastructure. This surge in network traffic and processing requirements has resulted in significant challenges, particularly in the realms of subscriber authentication and authorization, often manifesting as unacceptable delays in these critical processes.
[0026] While 3GPP specifications provide for the deployment of certain Network Functions (NFs) at edge locations to mitigate latency in the control plane, a significant hurdle remains. Authentication and authorization-related NFs, such as the Unified Data Management (UDM) and Unified Data Repository (UDR), demand substantial memory resources. This resource intensity poses practical limitations on their widespread deployment at edge locations, creating a tension between the need for reduced latency and the constraints of available edge computing resources.
[0027] This complex interplay of advancing technology, escalating user demands, and practical deployment constraints underscores the pressing need for innovative solutions in subscriber data management and network function deployment strategies. Addressing these challenges is crucial for realizing the full potential of 5G and beyond, particularly in supporting the burgeoning IoT ecosystem and ensuring seamless, low-latency services for an ever-growing user base.
[0028] Therefore, there is a need for a system that overcomes the limitations of the prior art and reduces latency and signalling load toward a central plane.
SUMMARY OF THE DISCLOSURE
[0029] In an exemplary embodiment, a system for performing authorization of subscribers at an edge of a network is described. The system comprises a memory and a processing engine configured to execute a set of instructions stored in the memory. The instructions are for receiving, by at least one edge network function (eNF), a registration request from at least one subscriber. The at least one eNF determines a target enhanced unified data repository (eUDR) from a plurality of enhanced unified data repositories (eUDRs). The target eUDR queries a centralized network repository function (cNRF) to discover a centralized unified data repository (cUDR), wherein an enhanced network repository function (eNRF) forwards the query from the target eUDR to the cNRF. The target eUDR then establishes a connection with the cUDR. The cUDR receives a request to fetch a subscriber profile from the target eUDR corresponding to a subscription permanent identifier (SUPI) of the at least one subscriber. The cUDR, upon receiving the request, provides the subscriber profile to the target eUDR. The target eUDR fetches subscriber data corresponding to the subscriber profile from the cUDR. The at least one eNF establishes a session with the at least one subscriber by verifying the received request based on the subscriber data.
[0030] In some embodiments, the processing engine is further configured to transmit, by the target eUDR, a register request to the eNRF, and receive, by the target eUDR, a response from the eNRF indicating acceptance or decline of the register request.
[0031] In some embodiments, the processing engine is further configured to transmit, by the cUDR, a register request to the cNRF, and receive, by the cUDR, a response from the cNRF indicating acceptance or decline of the register request.
[0032] In some embodiments, the processing engine is further configured to transmit, by the target eUDR, a cUDR discovery request to the eNRF. The eNRF forwards the cUDR discovery request to the cNRF. The eNRF receives a response from the cNRF including details of available one or more cUDR instances. The eNRF forwards the response to the target eUDR.
[0033] In some embodiments, the processing engine is further configured to transmit, by the target eUDR, a register request to the cUDR for a subscriber session. The target eUDR receives a response from the cUDR indicating initialization of the subscriber session. The target eUDR sends a request for getting subscriber data to the cUDR. The target eUDR receives a response from the cUDR including the subscriber data. The target eUDR sends stored session data to the cUDR. The target eUDR receives a response from the cUDR indicating completion of updation of the subscriber data.
[0034] In some embodiments, the processing engine is further configured to receive, by the target eUDR, a notification from the cUDR indicating a change in the subscriber profile, and transmit, by the target eUDR, a notification response to the cUDR.
[0035] In some embodiments, the processing engine is further configured to send, by a new eUDR, a register request to the cUDR when the at least one subscriber moves from an old location to a new location. The new eUDR receives a response from the cUDR corresponding to the register request, wherein the response comprises details of an old eUDR. The new eUDR transmits a UE context transfer request to the old eUDR. The new eUDR receives a context transfer response from the old eUDR including details of UE context.
[0036] In some embodiments, the processing engine is further configured to establish the connection between the target eUDR and the cUDR using at least one of a Hypertext Transfer Protocol 2 (HTTP2) service-based interface and a streaming protocol.
[0037] In some embodiments, the processing engine is further configured to implement mutual transport layer security (mTLS) between the target eUDR and the cUDR.
[0038] In some embodiments, the processing engine is further configured to authorize the target eUDR by the cUDR based on an OAuth 2.0 access token.
[0039] In some embodiments, the processing engine is further configured to integrate the cUDR and the target eUDR with one of an Operation Support System (OSS) and a Business Support System (BSS) for subscriber provisioning and profile management.
[0040] In some embodiments, the processing engine is further configured to implement a caching model, wherein the target eUDR fetches the subscriber data from the cUDR using a service-based interface, caches the subscriber data for a lifetime of the session, and stores the subscriber data for a defined time interval before deleting the subscriber data.
[0041] In some embodiments, the processing engine is further configured to implement a storage model, wherein the plurality of eUDRs corresponding to various edge locations of a public land mobile network (PLMN) fetch all subscriber data for the PLMN from the cUDR using a streaming interface and store the subscriber data in a local storage when each eUDR of the plurality of eUDRs is initialized.
[0042] In another exemplary embodiment, a method for performing authentication and authorization of subscribers at an edge of a network is described. The method comprises receiving, by at least one edge network function (eNF), a registration request from at least one subscriber. The at least one eNF determines a target enhanced unified data repository (eUDR) from a plurality of enhanced unified data repositories (eUDRs). The target eUDR queries a centralized network repository function (cNRF) to discover a centralized unified data repository (cUDR), wherein an enhanced network repository function (eNRF) forwards the query from the target eUDR to the cNRF. The target eUDR establishes a connection with the cUDR. The cUDR receives a request to fetch a subscriber profile from the target eUDR corresponding to a subscription permanent identifier (SUPI) of the at least one subscriber. The cUDR, upon receiving the request, provides the subscriber profile to the target eUDR. The target eUDR fetches subscriber data corresponding to the subscriber profile from the cUDR. The at least one eNF establishes a session with the at least one subscriber by verifying the received request based on the subscriber data.
[0043] In some embodiments, the method further comprises transmitting, by the target eUDR, a register request to the eNRF, and receiving, by the target eUDR, a response from the eNRF indicating acceptance or decline of the register request.
[0044] In some embodiments, the method further comprises transmitting, by the cUDR, a register request to the cNRF, and receiving, by the cUDR, a response from the cNRF indicating acceptance or decline of the register request.
[0045] In some embodiments, the method further comprises transmitting, by the target eUDR, a cUDR discovery request to the eNRF. The eNRF forwards the cUDR discovery request to the cNRF. The eNRF receives a response from the cNRF including details of available cUDR instances. The eNRF forwards the response to the target eUDR.
[0046] In some embodiments, the method further comprises transmitting, by the target eUDR, a register request to the cUDR for a subscriber session. The target eUDR receives a response from the cUDR indicating initialization of the subscriber session. The target eUDR sends a request for getting subscriber data to the cUDR. The target eUDR receives a response from the cUDR including the subscriber data. The target eUDR sends stored session data to the cUDR. The target eUDR receives a response from the cUDR indicating completion of updation of the subscriber data.
[0047] In some embodiments, the method further comprises receiving, by the target eUDR, a notification from the cUDR indicating a change in the subscriber profile, and transmitting, by the target eUDR, a notification response to the cUDR.
[0048] In some embodiments, the method further comprises send, by a new eUDR, a register request to the cUDR when the at least one subscriber moves from an old location to a new location. The new eUDR receives a response from the cUDR corresponding to the register request, wherein the response comprises details of an old eUDR. The new eUDR transmits a UE context transfer request to the old eUDR. The new eUDR receives a context transfer response from the old eUDR including details of UE context.
[0049] In some embodiments, establishing the connection between the target eUDR and the cUDR comprises using at least one of a Hypertext Transfer Protocol 2 (HTTP2) service-based interface and a streaming protocol.
[0050] In some embodiments, the method further comprises implementing mutual transport layer security (mTLS) between the target eUDR and the cUDR.
[0051] In some embodiments, the method further comprises authorizing the target eUDR by the cUDR based on an OAuth 2.0 access token.
[0052] In some embodiments, the method further comprises integrating the cUDR and the target eUDR with one of an Operation Support System (OSS) and Business Support System (BSS) for subscriber provisioning and profile management.
[0053] In some embodiments, the method further comprises implementing a caching model, wherein the target eUDR fetches the subscriber data from the cUDR using a service-based interface, caches the subscriber data for a lifetime of the session, and stores the subscriber data for a defined time interval before deleting the subscriber data.
[0054] In some embodiments, the method further comprises implementing a storage model, wherein a plurality of eUDRs corresponding to various edge locations of a public land mobile network (PLMN) fetch all subscriber data for the PLMN from the cUDR using a streaming interface and store the subscriber data in a local storage when each eUDR of the plurality of eUDRs is initialized.
[0055] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
OBJECTS OF THE DISCLOSURE
[0056] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.
[0057] An object of the present disclosure is to provide a system and a method that handles authentication and authorization requests at the edge of a network, thereby reducing latency in a control plane.
[0058] An object of the present disclosure is to provide a system and a method that reduces signalling load towards a centralized data center for authentication of numerous devices by utilizing enhanced unified data repositories (eUDRs) at the edge of the network.
[0059] An object of the present disclosure is to provide a highly distributed architecture for subscriber data management, resulting in improved reliability and reduced risk of a single point of failure.
[0060] An object of the present disclosure is to enable efficient discovery and communication between edge network functions (eNFs), enhanced unified data repositories (eUDRs), and centralized unified data repositories (cUDRs) through the use of enhanced network repository functions (eNRFs) and centralized network repository functions (cNRFs).
[0061] An object of the present disclosure is to provide a system and method for secure and efficient transfer of subscriber profiles and data between edge and centralized repositories.
[0062] An object of the present disclosure is to implement flexible data management models, including caching and storage models, to optimize subscriber data handling at the edge of the network.
[0063] An object of the present disclosure is to enhance network security by implementing mutual transport layer security (mTLS) and OAuth 2.0 based authorization between edge and centralized components.
[0064] An object of the present disclosure is to provide seamless subscriber mobility support by enabling efficient UE context transfer between old and new eUDRs when subscribers move between locations.
[0065] An object of the present disclosure is to integrate edge and centralized unified data repositories with Operation Support System/Business Support System (OSS/BSS) for comprehensive subscriber provisioning and profile management.
[0066] An object of the present disclosure is to provide a system and method that enables edge deployment of network functions related to authentication, authorization, and policy charging, thereby improving overall network performance and user experience.
[0067] 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 DRAWINGS
[0068] 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.
[0069] FIG. 1 illustrates an exemplary network architecture of a system for performing authentication and authorization of subscribers at edge of a network, in accordance with embodiments of the present disclosure.
[0070] FIG. 2 illustrates an exemplary micro service-based architecture of the system, in accordance with embodiments of the present disclosure.
[0071] FIG. 3 illustrates a network diagram of the system for performing authentication and authorization of a plurality of subscribers at edge of a network, in accordance with an embodiment of the present disclosure.
[0072] FIG. 4 illustrates an exemplary method for registration of an enhanced unified data repository (eUDR) with an enhanced network repository function (eNRF), in accordance with an embodiment of the present disclosure.
[0073] FIG. 5 illustrates an exemplary flow diagram depicting a method for registration of the enhanced unified data repository (eUDR) with the enhanced network repository function (eNRF), in accordance with an embodiment of the present disclosure.
[0074] FIG. 6 illustrates an exemplary flow diagram depicting a method for registration of a centralized unified data repository (cUDR) with a centralized network repository function (cNRF), in accordance with an embodiment of the present disclosure.
[0075] FIG. 7 illustrates an exemplary flow diagram depicting a method for discovering the cUDR by the eUDR, in accordance with an embodiment of the present disclosure.
[0076] FIG. 8 illustrates an exemplary flow diagram depicting a method for communicating between the cUDR and the eUDR, in accordance with an embodiment of the present disclosure.
[0077] FIG. 9 illustrates an exemplary flow diagram depicting a method for communicating between a new eUDR and the cUDR when a subscriber moves from an old location to a new location, in accordance with an embodiment of the present disclosure.
[0078] FIG. 10 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0079] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100 – Network architecture
102 – System
104 – Network
106 – Centralized server
108 – Computing device
110 – User
202 – One or more processor(s)
204 – Memory
206 – Interface
208 – Processing engine
212 – Network function management module
214 – Enhanced unified data repository management module
216 – Enhanced network repository function management module
218 – Centralized unified data repository management module
220 – Centralized network repository function management module
222 – Data center network functions management module
224 – Unified data repository management module
226 – Network repository function management module
228 – Other module(s)
230 – Database
300 - network diagram
302a, 302b, 302c – Edge network function
304a, 304b, 304c – Enhanced unified data repository
306a, 306b, 306c – Enhanced network repository function
308 – Centralized unified data repository
310 – Centralized network repository function
312x, 312y – Data center network function
314x, 314y – Unified data repository
316x, 316y – Network repository function
402, 404, 406, 408, 410, 412, 414 - Steps of method (400)
502, 504 - Steps of flowchart (500)
602, 604 - Steps of flowchart (600)
702, 704, 706, 708 - Steps of flowchart (700)
802, 804, 806, 808, 810, 812, 814, 816 - Steps of flowchart (800)
902, 904, 906, 908 - Steps of flowchart (900)
1000- Computer System
1010 – External Storage Device
1020 – Bus
1030 – Main Memory
1040 – Read Only Memory
1050 – Mass Storage Device
1060 – Communication Port
1070 – Processor
DETAILED DESCRIPTION OF THE DISCLOSURE
[0080] 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.
[0081] 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.
[0082] 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 to obscure 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.
[0083] Also, it is noted that individual embodiments may be described as a process which 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.
[0084] 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 in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.
[0085] 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.
[0086] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly 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 and all combinations of one or more of the associated listed items.
[0087] The aspects of the present disclosure are directed to the system and the method for performing authentication and authorization of subscribers at the edge of a network. Efficient authentication and authorization of subscribers in modern telecommunications networks is crucial yet increasingly challenging due to the growing number of transactions between the network functions (NFs) and centralized repositories. This challenge is particularly acute in 5G and emerging 6G networks. While deploying NFs at edge locations can help reduce latency, memory and storage limitations have traditionally hindered the deployment of authentication and authorization NFs at the edge.
[0088] To address these challenges, the present disclosure introduces a novel approach that deploys enhanced Unified data repositories (eUDRs) at various edge locations, complemented by a centralized Unified data repository (cUDR). This architecture is designed to efficiently handle the signalling demands of 5G and 6G networks, managing subscriber data at the edge and significantly reducing latency while improving overall network performance.
[0089] The proposed system comprises several key components working in concert. Edge Network Functions (eNFs) handle initial registration requests from subscribers at the network edge. Enhanced Unified data Repositories (eUDRs), deployed at edge locations, manage subscriber data locally, reducing the need for constant communication with centralized repositories. A Centralized Unified data repository (cUDR) serves as a central store for comprehensive subscriber data, synchronizing with eUDRs as needed. Enhanced Network Repository Functions (eNRFs) and a Centralized Network Repository Function (cNRF) facilitate discovery and communication between eUDRs, cUDRs, and other network functions.
[0090] The authentication and authorization process in this system follows a sophisticated workflow. When a subscriber sends a registration request, an eNF receives it and determines the appropriate eUDR to handle the request. This eUDR then queries the cNRF via the eNRF to discover the relevant cUDR. Subsequently, the eUDR establishes a secure connection with the cUDR and fetches the necessary subscriber profile and data. Finally, the eNF establishes a session with the subscriber after verifying the request based on the fetched subscriber data.
[0091] This architecture supports a range of advanced features that enhance its efficiency and security. It implements both caching and storage models for efficient data management at the edge. Security is ensured through the use of mutual transport layer security (mTLS) and OAuth 2.0 tokens for communication between components. The system also integrates with Operation Support System/Business Support System (OSS/BSS) for comprehensive subscriber management. Moreover, it efficiently handles subscriber mobility through UE context transfer between eUDRs when the subscribers move between locations.
[0092] By addressing the challenges posed by Massive Machine Type Communication (mMTC) and Critical Machine Type Communication (cMTC) in 5G and future 6G networks, this system provides a scalable and efficient solution for managing the authentication and authorization of a vast number of cellular users and IoT devices. It leverages edge computing and distributed network approaches to optimize subscriber data management, enabling innovative services and applications in next-generation mobile networks.
[0093] As the telecommunications industry progresses towards 6G, the proposed system is well-positioned to meet the evolving challenges and opportunities presented by Subscriber Data Management (SDM) and IoT integration. With the anticipated growth in cellular users and IoT devices, this efficient, scalable, and secure SDM solution becomes increasingly vital. By catering to the unique requirements of IoT in 6G networks, including mission-critical applications and massive device connectivity, this system represents a significant advancement in SDM architectures, potentially playing a pivotal role in shaping the future of mobile networks.
[0094] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGS. 1-9.
[0095] FIG. 1 illustrates a network architecture (100) of a system (102) for performing authentication and authorization of subscribers at edge of a network (104), in accordance with embodiments of the present disclosure.
[0096] In an embodiment, the system (102) may be configured to implement an Operation Support Systems /Business Support Systems (OSS/BSS) service. The system (102) is connected to the network (104), which is further connected to at least one computing device 108-1, 108-2, … 108-N (collectively referred to as a computing device 108, herein) associated with one or more users 110-1, 110-2, … 110-N (collectively referred as a user (110), herein). The computing device (108) may be personal computers, laptops, tablets, wristwatch, or any custom-built computing device integrated within a modern diagnostic machine that can connect to a network as an IoT (Internet of Things) device. In an embodiment, the computing device 108 may also be referred to as User Equipment (UE) or user device. Accordingly, the terms “computing device” and “User Equipment” may be used interchangeably throughout the disclosure. In an aspect, the user (110) is a network operator or a field engineer. Further, the network (104) can be configured with a centralized server (106) that stores compiled data.
[0097] In an embodiment, the system (102) may receive at least one input data from the user (110) via the at least one computing device (108). In an aspect, the user (110) may be configured to initiate the process of authentication and authorization of subscribers at the edge of the network (104), through an application interface of a mobile application installed in the computing device 108. The mobile application may be configured to communicate with a network analysis server. In some examples, the mobile application may be a software or a mobile application from an application distribution platform. Examples of application distribution platforms include the App Store, Play Store., and such application distribution platforms. In an embodiment, the computing device 108 may transmit the at least one captured data packet over a point-to-point or point-to-multipoint communication channel or the network (104) to the system (102). In an embodiment, the computing device (108) may perform collection, analysis, and sharing of data received from the system (102) via the network (104).
[0098] In an exemplary embodiment, the network 104 may include, but not be limited to, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. In an exemplary embodiment, the network 104 may include, but not be limited to, a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0099] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include 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).
[00100] FIG. 2 with reference to FIG. 1, illustrates an exemplary architecture (200) of the system (102) for authentication and authorization of subscribers at the edge of the network (104), in accordance with an embodiment of the present disclosure.
[00101] The system (102) includes one or more processor(s) (202), a memory (204), a processing engine (208), a database (230), and an interface(s) (206). In an exemplary embodiment, the processing engine (208) may include one or more modules/engines selected from any of a network function management module (212), an enhanced unified data repository management module (214), an enhanced network repository function management module (216), a centralized unified data repository management module (218), a centralized network repository function management module (220), a Data center network functions management module (222), a Unified data repository management module (224), Network repository function management module (226) and other module(s) (228) having functions that may include but are not limited to receiving data, processing data, testing, storage, and peripheral functions, such as wireless communication unit for remote operation, audio unit for alerts and the like.
[00102] The one or more processor(s) (202) is configured to initiate the process of authentication and authorization of subscribers at the edge of the network 104 through the application interface of the User Equipment (UE) (108). In an embodiment, the application interface is configured to transmit one or more instructions to the one or more processor(s) (202).
[00103] In an embodiment, 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, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in the memory (204) of the system (102). 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 packets over a network service. The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as Random Access Memory (RAM), or non-volatile memory such as Erasable Programmable Read-Only Memory (EPROM), flash memory, and the like.
[00104] The interface(s) (206) is included within the system (102) to serve as a medium for data exchange, configured to facilitate user interaction with the mobile application. The interface(s) (206) may be composed of interfaces for data input and output devices, storage devices, and the like, providing a communication pathway for the various components of the system (102).
[00105] The interface(s) (206) may comprise 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 to/from the system (102). The interface(s) (206) may also provide a communication pathway for one or more components of the system (102). Examples of such components include but are not limited to, the processing unit/engine(s) (208) and the database (230).
[00106] In an embodiment, the processing unit/engine(s) (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(s) (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(s) (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (208) may comprise 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(s) (208). In such examples, the system (102) may comprise 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 (102) and the processing resource. In other examples, the processing engine(s) (208) may be implemented by electronic circuitry.
[00107] In an embodiment, the database (230) is configured for serving as a centralized repository for storing and retrieving various operational data. The database (230) is designed to interact seamlessly with other components of the system (102) to support the system's functionality effectively. The database (230) may store data that may be either stored or generated as a result of functionalities implemented by any of the components of the one or more processor(s) (202) or the processing engines (208). In an embodiment, the database (230) may be separate from the system (102).
[00108] In one embodiment, the system (102) may include at least one edge network function (eNF) (302a, 302b, 302c) that may be configured to receive a registration request from at least one subscriber. The eNF (302a, 302b, 302c) may be implemented by the network function management module (212) that handles various network functions at the edge of the network (104). Upon receiving the registration request, the eNF (302a, 302b, 302c) may determine a target enhanced unified data repository (eUDR) (304a) from a plurality of enhanced unified data repositories (eUDRs) (304a, 304b, 304c). This determination may be carried out by the enhanced unified data repository management module (214) that manages the operations and interactions of the eUDRs within the system (102).
[00109] The target eUDR (304a), once determined, may query a centralized network repository function (cNRF) (310) via a connected enhanced network repository function (eNRF) (306a, 306b, 306c) to discover a centralized unified data repository (cUDR) (308). The eNRF (306a, 306b, 306c) may be managed by the enhanced network repository function management module (216), which may facilitate the communication between the eUDR (304a) and the cNRF (310). The cNRF (310), in turn, may be managed by the centralized network repository function management module (220). The centralized network repository function management module (220) may handle the centralized repository functions and respond to queries from the eNRFs (306a, 306b, 306c).
[00110] Upon discovering the cUDR (308), which may be managed by the centralized unified data repository management module (218), the target eUDR (304a) may establish a connection with the cUDR (308). This connection may enable the secure transfer of subscriber data between the edge and centralized components of the system (102).
[00111] The cUDR (308) may receive a request from the target eUDR (304a) to fetch a subscriber profile corresponding to a subscription permanent identifier (SUPI) of the at least one subscriber. This request may initiate the process of retrieving the necessary subscriber data for authentication and authorization.
[00112] Following this request, the target eUDR (304a) may fetch subscriber data corresponding to the subscriber profile from the cUDR (308). This fetching process may involve secure data transfer protocols to ensure the integrity and confidentiality of the subscriber data.
[00113] Once the subscriber data has been fetched, the at least one eNF (302a, 302b, 302c) may establish a session with the at least one subscriber by verifying the received request based on the subscriber data. This verification process may ensure that only authorized subscribers are granted access to the network resources.
[00114] The system (102) may further incorporate additional functionalities to enhance its operation and security. For instance, the target eUDR (304a) may be configured to transmit a register request to the eNRF (306a, 306b, 306c) and receive a response indicating acceptance or decline of the register request. This registration process may ensure that only authorized eUDRs are allowed to participate in the system's operations.
[00115] Similarly, the cUDR (308) may transmit a register request to the cNRF (310) and receive a response indicating acceptance or decline of the register request. This process may help maintain the integrity of the centralized repository functions within the system (102).
[00116] The system (102) may also implement a discovery mechanism. The target eUDR (304a) may transmit a cUDR discovery request to the eNRF (306a, 306b, 306c). The eNRF (306a, 306b, 306c) may forward this request to the cNRF (310), which may respond with details of available cUDR instances. The eNRF (306a, 306b, 306c) may then forward this response to the target cUDR (304a), facilitating efficient discovery of appropriate cUDRs for different subscriber profiles.
[00117] To manage subscriber sessions effectively, the system (102) may enable the target eUDR (304a) to transmit a register request to the cUDR (308) for a subscriber session. The cUDR (308) may respond with an indication of session initialization. The target eUDR (304a) may then send a request for subscriber data to the cUDR (308), receive the subscriber data, send stored session data back to the cUDR (308), and receive a response indicating completion of subscriber data update.
[00118] The system (102) may also handle changes in subscriber profiles efficiently. The target eUDR (304a) may receive a notification from the cUDR (308) indicating a change in the subscriber profile and transmit a notification response back to the cUDR (308). This mechanism may ensure that any changes in subscriber profiles are promptly communicated and acted upon within the system (102).
[00119] To handle subscriber mobility, the system (102) may allow a new eUDR (304n) to register with the cUDR (308) when a subscriber moves from an old location to a new location. The new eUDR (304n) may receive details of the old eUDR (304o) from the cUDR (308), transmit a UE context transfer request to the old eUDR (304o), and receive the UE context details in response. This process may ensure seamless service continuity for subscribers as they move between different network locations.
[00120] Further, the connection between the target eUDR (304a) and the cUDR (308) may be established using either a Hypertext Transfer Protocol 2 (HTTP2) service-based interface or a streaming protocol. This flexibility in connection protocols may allow the system (102) to adapt to different network conditions and requirements.
[00121] To enhance security, the system (102) may implement mutual transport layer security (mTLS) between the target eUDR (304a) and the cUDR (308). This may provide a secure channel for data exchange between these components.
[00122] Furthermore, the cUDR (308) may authorize the target eUDR (304a) based on an OAuth 2.0 access token, adding an additional layer of security to the system (102). The system (102) may also integrate the cUDR (308) and the target eUDR (304a) with the Operation Support System/Business Support System (OSS/BSS) for subscriber provisioning and profile management. This integration may allow for more comprehensive and efficient management of subscriber data across the network (104).
[00123] The system (102) may implement two different models for managing subscriber data namely a caching model and a storage model. In the caching model, the target eUDR (304a) may fetch subscriber data from the cUDR (308) using a service-based interface, cache the data for the lifetime of the session, and store it for a defined time interval before deletion. This approach may reduce the need for frequent data fetches from the centralized repository.
[00124] In the storage model, all eUDRs corresponding to various edge locations of a public land mobile network (PLMN) may fetch all subscriber data for the PLMN from the cUDR (308) using a streaming interface and store the data in local storage when each eUDR is initialized. This approach may allow for faster access to subscriber data at the edge of the network (104). The streaming interface may refer to an interface that provides a continuous flow of data as compared to static or batch-based data retrieval, for applications requiring up-to-date information, such as policy enforcement, billing, network slicing, and Quality of Service (QoS) management. The streaming interface enables network elements to access subscriber profile data on-demand or in real-time as changes occur. In examples, the streaming interface enables fetching the subscriber profile that may include, for example, profile information, service entitlements, data plans, policies, etc. for various network operations. The streaming interfaces supports data delivered efficiently to the requesting entities, like as eUDR, Session Management Function (SMF), Policy Control Function (PCF), or other network functions.
[00125] The Data center network functions management module (222) may oversee the operations of various network functions within the data center, ensuring efficient processing and routing of network traffic. The Unified data repository management module (224) may handle the storage and retrieval of unified data, working in conjunction with the eUDRs and cUDRs to ensure data consistency and availability. The Network repository function management module (226) may manage the overall repository functions, coordinating between the enhanced and centralized repository functions to maintain an up-to-date view of the network topology and available resources.
[00126] This system (102) may provide several benefits. It may reduce latency in authentication and authorization processes by handling these requests at the network edge. The distributed architecture may result in improved reliability and reduced risk of a single point of failure. The system (102) may also enable efficient handling of a large number of IoT devices and support for mission-critical applications requiring low latency. The flexible data management models may optimize subscriber data handling, potentially reducing network congestion and improving overall performance. The security measures implemented, such as mTLS and OAuth 2.0 based authorization, may enhance the overall security posture of the network.
[00127] By addressing the challenges of Massive Machine Type Communication (mMTC) and Critical Machine Type Communication (cMTC) in 5G and future 6G networks, this system (102) provides a scalable and an efficient solution for managing the authentication and authorization of a vast number of cellular users and IoT devices. It may leverage edge computing and distributed network approaches to optimize subscriber data management, potentially paving the way for innovative services and applications in next-generation mobile networks.
[00128] FIG. 3 illustrates a network diagram (300) of the system (102) for performing authentication and authorization of subscribers at the edge of the network (104), in accordance with an embodiment of the present disclosure.
[00129] In an example, the system (102) may include at least one network function (302a, 302b, 302n), a plurality of enhanced unified data repositories (eUDRs) (304a, 304b, 304c), a plurality of enhanced network repository functions (eNRFs) (306a, 306b, 306c), a centralized unified data repository (cUDR) (308), a centralized network repository function (cNRF) (310), a plurality of data center network elements (DC NFs) (312x, 312y), a plurality of unified data repositories (UDRs) (314x, 314y), and a plurality of network repository functions (NRFs) (316x, 316y).
[00130] The at least one network function (302a, 302b, 302n) may include a User Plane Function (UPF), a Session Management Function (SMF), an Access and Mobility Management Function (AMF), and other functions such as a Policy Control Function (PCF), an Unified Data Management (UDM), a Network Exposure Function (NEF), a NR Repository Function (NRF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), an Unified Data Repository (UDR), and an Application Function (AF). The at least one network function (302a, 302b, 302n) may be implemented in many ways, such as all the functions being implemented in a single physical node, distributed across multiple nodes, or executed on a cloud platform.
[00131] The at least one edge network function (eNF) (302a, 302b, 302c) may be configured to receive a registration request from at least one subscriber. The at least one edge network function (eNF) (302a, 302b, 302c) may be configured to determine a target enhanced unified data repository (eUDR) (304a) from the plurality of enhanced unified data repositories (304a, 304b, 304c). In an example, the determined eUDR(s) may be configured to register themselves with a separate eNRF.
[00132] In an aspect of the present disclosure, the plurality of eUDRs (304a, 304b, 304c) may be deployed at various edge locations such that the plurality of eUDRs (304a, 304b, 304c) may be configured to handle the signalling load for subscriber data management at the edge location itself. Further, during implementation of the present disclosure, the cUDR (308) may be deployed at a centralized location.
[00133] The determined target eUDR (304a) may be configured to discover the cUDR (308) via a registered eNRF (306a, 306b, 306c). The eNRF may be configured to query a centralized network repository function (cNRF) to get the details of a centralized unified data repository (cUDR) (308). In an example, the plurality of eNRFs (306a, 306b, 306c) may be configured to receive requests from plurality of edge network functions (302a, 302b, 302n). Each of the plurality of eNRFs (306a, 306b, 306c) may be connected with a corresponding dedicated eUDR. Each of the plurality of eUDRs (304a, 304b, 304c) may be configured to register itself with the eNRF (306a, 306b, 306c) with NFType “eUDR”.
[00134] The target eUDR (304a) may be configured to establish a connection with the discovered cUDR. The target eUDR (304a) may be configured to generate a request to fetch a subscriber profile corresponding to a subscription permanent identifier (SUPI) of said at least one subscriber. The cUDR may be configured to receive the generated request from the target eUDR (304a). The target eUDR (304a) may be configured to fetch a plurality of subscriber data corresponding to said fetched subscriber profile from said cUDR (308) accordingly. The at least one eNF (302a, 302b, 302c) may be configured to establish a session with said at least one subscriber by verifying said received request based on said plurality of subscriber data.
[00135] On receiving the request, each of the plurality of eNRFs (306a, 306b, 306c) may be configured to establish a connection with the cNRF (310). In an aspect, the cNRF (310) may be connected with the cUDR (308). In an example, the cUDR (308) may be configured to register itself with the cNRF (310) with NFType “cUDR”. In an operative aspect, each of the plurality of eUDRs (304a, 304b, 304c) eUDR(s) may be configured to discover the cUDR (308) via the eNRF (306a, 306b, 306c). The eNRF (306a, 306b, 306c) may be configured to query cNRF (310) to get the details of cUDR (308). The plurality of eUDRs (304a, 304b, 304c) may be configured to communicate with the cUDR (308). In an example, the target eUDR (304a) may be configured to initiate the connection with the cUDR (308) over an HTTP2 service-based Interface or over some Streaming Protocol (e.g. Kafka). In another example, the system (102) may be configured to employ a mutual transport layer security (mTLS) between the target eUDR (304a) and cUDR (308) to provide transport layer security. The cUDR (308) and the target eUDR (304a) may be configured to mutually authenticate each other based on client side and server-side certificates during a transport layer security (TLS) connection formation.
[00136] In addition to authentication, the cUDR (308) may optionally authorize the target eUDR (304a) based on OAUTH2 access token. The target eUDR (304a) may be configured to fetch the OAUTH2 access token from the eNRF (306a) and send it to the cUDR (308) in all subsequent requests towards cUDR (308).
[00137] In an example, the cUDR (308) and the plurality of eUDRs (304a, 304b, 304c) may be integrated with an Operation Support Systems /Business Support Systems (OSS/BSS). The Operational Support Systems (OSS) ensures that the network runs smoothly, and resources are used efficiently. Together with operations support systems (OSS), BSSs are used to support various end-to-end telecommunications services (e.g. telephone services). In an operative aspect, the target eUDR (304a) and the cUDR (308) may be configured to handle the signalling demand of 6G as well as 5G. The BSS system may be configured to provide provision all subscribers in the cUDR (308).
[00138] The target eUDR (304a) may be configured to fetch a plurality of subscriber data from the cUDR (308) directly. In an operative aspect, the cUDR (308) may be configured to either synchronize the data with the target eUDR (304a) using streaming protocols or send the subscriber profile to the target eUDR (304a) on receiving subscriber data get from target eUDR (304a) based on the deployment model of the target eUDR (304a).
[00139] The 6G/5G-CN NFs deployed at the edge location may be configured to discover the target eUDR (304a) via the eNRF (306a). In case of delegated discovery, the service communication proxy (SCP) may discover the target eUDR (304a) via the eNRF (306a). The service communication proxy (SCP) is a new HTTP/2-based network function enabling dynamic scaling and management of communication and services in the 5G network.
[00140] The eNF (302a) may be configured to verify the received request based on the plurality of subscriber data. If the request is a valid request, the eNF (302a) may be configured to establish a session with the subscriber. If the request is an invalid request, the eNF (302a) may be configured to discard the received request. In an example, the eNF (302a) may be configured to ask authentication and authorization of the request based on the plurality of subscriber data.
[00141] The target eUDR (304a) may be configured to store a session data corresponding to an established session. In an example, the session data may include login and logout times, IP addresses, user IDs, and the actions taken during the session.
[00142] In an implementation aspect, when a UE (subscriber) (108) connects to a 6G/5G network and the request to fetch a subscriber profile. The target eUDR (304a) may register itself in the cUDR (308) for a Subscription Permanent Identifier (SUPI) of the UE (108). When the UE (108) moves from one edge location to another within the PLMN and eUDR changes, the new eUDR (304n) may configured to register itself with cUDR (308) and fetch the details of old eUDR (304o) for “UEContext transfer” request.
[00143] The target eUDR (304a) may be configured to update the plurality of subscriber data in the cUDR (308) based on the stored session data. The target eUDR (304a) may be configured to asynchronously update the dynamic data related to UE’s session in cUDR (308). The target eUDR (304a) may be configured to subscribe to cUDR (308) for any changes in the subscriber profile at cUDR (308) by the OSS/BSS. If the profile changes at cUDR (308), the cUDR (308) may be configured to notify the target eUDR (304a) of the Changes. Only the delta changes may be synced between target eUDR (304a) and cUDR (308).
[00144] In case of inter PLMN roaming, the visited network NFs (VUDM, VPCF) may be configured to discover the cUDR (308) via VeNRF. The VeNRF may be configured to send the query to cNRF (310) where the cUDR (308) is registered. The cNRF (310) may be configured to return the NF profile of cUDR (308) to the VeNRF.
[00145] In case eUDR at edge site fails, the eNRF may be configured to detect the failure based on heartbeat, for any new Discovery, the eNRF may be configured to forward the query to cNRF (310) and cNRF (310) may return the NF profile of cUDR (308) for that edge.
[00146] Based on the resources available to store subscriber Data at the edge, the eUDR may be configured to apply following models.
[00147] Caching Model: In this model, the target eUDR (304a) may be configured to serve the subscriber at a particular location and may be configured to fetch the Subscriber data from cUDR (308) using Service Based Interface of cUDR (308). The target eUDR (304a) may be configured to cache it for the lifetime of the Subscriber Session. If the subscriber moves to a different edge location within PLMN, the eUDR at the new edge location may be configured to fetch the Context from the old eUDR (304o). The old eUDR (304o) may be configured to keep the Subscriber data for a defined interval of time before deleting the data so that if the Subscriber comes back to the old location eUDR may use the cached Data. In this model, all kinds of data i.e., subscriber profile related data and dynamic data (like AMF, and SMF registration data) may be cached at eUDR and during context transfer, all the Data may be transferred to new eUDR (304n).
[00148] Storage Model: In this model, all the eUDRs corresponding to various edge locations of a PLMN may be configured to fetch all subscriber data for that PLMN from cUDR (308) using the streaming interface and store the subscriber data in the local storage whenever eUDR comes up for the first time. When the UE moves to a different location within PLMN, the eUDR at the new location may be configured to only fetch the dynamic data from the old eUDR (304o). The old eUDR (304o) may be configured to keep the dynamic data for a defined interval of time before deleting the data so that if the subscriber comes back to the old location eUDR may use the cached data.
[00149] FIG. 4 illustrates an exemplary flow diagram of a method (400) for performing authentication and authorization of subscribers at an edge of the network (104), in accordance with embodiments of the present disclosure.
[00150] At step (402), the at least one edge network function (eNF) (302a, 302b, 302c) is configured for receiving a registration request from at least one subscriber. This step may initiate the authorization process at the network edge. The eNF (302a, 302b, 302c) may be a component of the network infrastructure deployed closer to end-users, potentially providing faster and more efficient network services. Upon receiving this registration request, the eNF (302a, 302b, 302c) may begin the process of authorizing the subscriber. This edge-based approach may contribute to reduced latency and improved overall network performance, particularly in 5G and future network architectures where low-latency services are crucial.
[00151] At step (404), the at least one eNF (302a, 302b, 302c) is configured for determining a target enhanced unified data repository (eUDR) (304a) from a plurality of enhanced unified data repositories (eUDRs) (304a, 304b, 304c). This determination may be based on various factors such as the subscriber's location, the current load on different eUDRs, or specific routing policies implemented in the network. The eUDRs may be specialized data repositories designed to store and manage subscriber data at the network edge. By selecting an appropriate eUDR, the method may optimize data access and distribution across the network.
[00152] At step (406), the target eUDR (304a) is configured for querying a centralized network repository function (cNRF) (310) to discover a centralized unified data repository (cUDR) (308). This querying process facilitates the discovery of the appropriate centralized repository for subscriber data. This step may further involve a specific discovery mechanism. The target eUDR (304a) may transmit (702) a cUDR discovery request to an eNRF (306a, 306b, 306c). The eNRF (306a, 306b, 306c) may then forward (704) this request to the cNRF (310). In response, the eNRF (306a, 306b, 306c) may receive (706) details of available cUDR instances from the cNRF (310) and forward (708) this response to the target eUDR (304a). This discovery process may enable efficient routing of requests and load balancing across one or more cUDR instances.
[00153] At step (408), the target eUDR (304a) is configured for establishing a connection with the cUDR (308). In particular, the connection is established between the target eUDR (304a) and the cUDR (308). This connection may serve as a secure channel for exchanging subscriber data between the edge and centralized components of the network. This connection may be established using either a Hypertext Transfer Protocol 2 (HTTP2) service-based interface or a streaming protocol, providing flexibility to adapt to different operational requirements and network conditions. Furthermore, the method may implement mutual transport layer security (mTLS) between the target eUDR (304a) and the cUDR (308), enhancing the security of the communication channel.
[00154] At step (410), the cUDR (308) is configured for receiving a request to fetch a subscriber profile from the target eUDR (304a) corresponding to a subscription permanent identifier (SUPI) of the at least one subscriber. This step initiates the process of retrieving the necessary subscriber data for authentication and authorization. The SUPI serves as a unique identifier for each subscriber, enabling the network to retrieve the correct profile and associated data. The cUDR (308), upon receiving the request, provides the subscriber profile to the target eUDR (304a).
[00155] At step (412) the target eUDR (304a) is configured for fetching subscriber data corresponding to the subscriber profile from the cUDR (308). This fetching process may involve secure data transfer protocols to protect sensitive subscriber information during transmission. The method (400) may implement a caching model where the target eUDR (304a) fetches the subscriber data using a service-based interface, caches the data for the lifetime of the session, and stores it for a defined time interval before deletion. Alternatively, a storage model may be implemented where all eUDRs corresponding to various edge locations of a public land mobile network (PLMN) fetch all subscriber data for the PLMN from the cUDR (308) using a streaming interface and store the data in local storage when each eUDR is initialized.
[00156] At step (414), the at least one eNF (302a, 302b, 302c) is configured for establishing a session with the at least one subscriber by verifying the received request based on the subscriber data. This verification at the network edge may potentially reduce latency and improve the overall user experience. The method (400) may also incorporate additional steps for comprehensive session management. These steps may include the target eUDR (304a) transmitting a register request to the cUDR (308) for a subscriber session, receiving a response indicating initialization of the subscriber session, sending a request for subscriber data, receiving the subscriber data, sending stored session data back to the cUDR (308), and receiving a response indicating completion of subscriber data update.
[00157] The method (400) may further include additional steps to enhance its functionality and security. The target eUDR (304a) may transmit (502) a register request to the eNRF (306a, 306b, 306c) and subsequently receive (504) a response indicating acceptance or decline of the register request. This registration process may ensure that only authorized eUDRs participate in the network's operations, potentially enhancing overall system security.
[00158] Similarly, the method (400) may include the cUDR (308) transmitting a register request to the cNRF (310) and receiving a response indicating acceptance or decline of the register request. This process may help maintain the integrity of the centralized repository functions within the network.
[00159] The method (400) may also handle changes in subscriber profiles efficiently. It may include the target eUDR (304a) receiving a notification from the cUDR (308) indicating a change in the subscriber profile and transmitting a notification response back to the cUDR (308). This mechanism may ensure that any changes in subscriber profiles are promptly communicated and acted upon within the network.
[00160] To handle subscriber mobility, the method (400) may incorporate additional steps. For example, when a subscriber moves from an old location to a new location, it may include a new eUDR (304n) registering with the cUDR (308), receiving details of the old eUDR (304o) from the cUDR (308), transmitting a UE context transfer request to the old eUDR (304o), and receiving UE context details in response. This process may ensure seamless service continuity for subscribers as they move between different network locations.
[00161] The method (400) may further include the cUDR (308) authorizing the target eUDR (304a) based on an OAuth 2.0 access token. This additional layer of security may help prevent unauthorized access to sensitive subscriber data.
[00162] The method (400) may also facilitate integration with broader network management systems. It may include integrating the cUDR (308) and the target eUDR (304a) with an Operation Support System/Business Support System (OSS/BSS) for subscriber provisioning and profile management. This integration may allow for more comprehensive and efficient management of subscriber data across the network.
[00163] By implementing this method (400), networks may potentially achieve more efficient and secure subscriber authentication and authorization at the network edge. The distributed architecture and edge-based processing may contribute to reduced latency and improved overall network performance. The various security measures incorporated in the method may enhance the protection of sensitive subscriber data. Furthermore, the flexibility in data management models may allow networks to optimize their operations based on specific requirements and network conditions.
[00164] As networks continue to evolve towards 5G and beyond, methods like this may play a crucial role in managing the increasing number of connected devices and the growing demand for low-latency, high-performance network services. The method's ability to handle Massive Machine Type Communication (mMTC) and Critical Machine Type Communication (cMTC) may make it particularly suitable for emerging IoT and industrial applications.
[00165] The method (400) may also contribute to the efficient handling of edge computing scenarios, where processing and data storage are brought closer to the location where it is needed. This approach may not only reduce latency but also help in managing network congestion and bandwidth usage more effectively.
[00166] Moreover, the method's design may allow for scalability, potentially enabling it to handle the authentication and authorization of a vast number of devices simultaneously. This scalability may be crucial in scenarios involving smart cities, large-scale industrial IoT deployments, or other applications where a high density of connected devices is expected.
[00167] In conclusion, the method (400) for performing authentication and authorization of subscribers at an edge of a network represents a comprehensive approach to addressing the challenges of modern and future network architectures. By leveraging edge computing, implementing robust security measures, and providing flexible data management models, this method may contribute significantly to the evolution of network technologies and services. The steps performed in the method (400) are further elaborated with reference to figure 5-9 as below.
[00168] FIG. 5 illustrates an example flow diagram depicting a method (500) for registration of the target enhanced unified data repository (eUDR) (304a) with the enhanced network repository function (eNRF) (306a, 306b, 306c), in accordance with an embodiment of the present disclosure.
[00169] At step (502), the target eUDR (304a) may transmit a register request to the eNRF (306a, 306b, 306c). This register request may include essential information about the eUDR, such as its capabilities, capacity, and network address. The eNRF (306a, 306b, 306c) may process this request, verifying the authenticity and eligibility of the eUDR to participate in the network.
[00170] At step (504), the eNRF (306a, 306b, 306c) may send a response to the target eUDR (304a). The response may indicate an acceptance or decline of the register request. If accepted, the eNRF (306a, 306b, 306c) may add the target eUDR (304a) to its list of available network functions. If declined, the response may include a reason for the rejection, allowing the target eUDR (304a) to address any issues and potentially retry the registration process. This registration process ensures that only authorized and properly configured eUDRs participate in the network's operations, enhancing overall system security and reliability.
[00171] FIG. 6 illustrates an example flow diagram depicting a method (600) for registration of the centralized unified data repository (cUDR) (308) with the centralized network repository function (cNRF) (310), in accordance with an embodiment of the present disclosure.
[00172] At step (602), the cUDR (308) may transmit a register request to the cNRF (310). This request may contain detailed information about the cUDR's capabilities, including its storage capacity, supported protocols, and security features. The cNRF (310) may then validate this information against network policies and requirements.
[00173] At step (604), the cNRF (310) may send a response to the cUDR (308), indicating an acceptance or decline of the register request. An acceptance is indicative of the cUDR being recognized as a valid centralized data repository within the network, while a decline may be accompanied by specific reasons, allowing the cUDR to make necessary adjustments before attempting to register again. This registration process helps maintain the integrity and security of the centralized repository functions within the network by ensuring that only properly configured and authorized cUDRs are utilized.
[00174] FIG. 7 illustrates an example flow diagram depicting a method (700) for discovering the cUDR (308) by the target eUDR (304a), in accordance with an embodiment of the present disclosure.
[00175] At step (702), the target eUDR (304a) may transmit a cUDR discovery request to the eNRF (306a, 306b, 306c). This request may include parameters such as the type of data needed, geographical preferences, or specific capability requirements.
[00176] At step (704), the eNRF (306a, 306b, 306c) may forward the received cUDR discovery request to the cNRF (310). This forwarding ensures that the discovery process spans both edge and centralized network components.
[00177] At step (706), the cNRF (310) may transmit a response to the eNRF (306a, 306b, 306c), including details of available cUDR instances. This response may contain information such as network addresses, capabilities, current load, and priority levels of various cUDRs.
[00178] At step (708), the eNRF (306a, 306b, 306c) may forward the received response to the target eUDR (304a). The eNRF may also apply local policies or perform additional filtering based on network conditions before forwarding this response. This discovery process facilitates efficient routing of requests and load balancing across multiple cUDR instances, ensuring optimal use of network resources.
[00179] FIG. 8 illustrates an example flow diagram depicting a method (800) for communicating between the cUDR (308) and the target eUDR (304a), in accordance with an embodiment of the present disclosure.
[00180] At step (802), the target eUDR (304a) may transmit a register request to the cUDR (308) for a subscriber session. This request may include session identifiers, subscriber information, and specific data requirements for the session.
[00181] At step (804), the cUDR (308) may transmit a response to the target eUDR (304a), indicating initialization of the subscriber session. This response may include session tokens or other security credentials necessary for the ongoing communication.
[00182] At step (806), the target eUDR (304a) may send a request for getting subscriber data to the cUDR (308). This request may specify the exact data fields required, potentially including subscriber preferences, service entitlements, or network access permissions.
[00183] At step (808), the cUDR (308) may transmit a response including the requested subscriber data to the target eUDR (304a). This data transfer may be secured using encryption protocols to protect sensitive subscriber information.
[00184] At step (810), the target eUDR (304a) may send stored session data to the cUDR (308). This step allows for synchronization of any changes or updates made at the edge of the network.
[00185] At step (812), the cUDR (308) may transmit a response to the target eUDR (304a), indicating completion of updation of the subscriber data. This confirmation ensures data consistency across the network. This process ensures comprehensive session management and data synchronization between edge and centralized repositories.
[00186] FIG. 8 also illustrates steps related to handling changes in subscriber profiles. At step (814), the cUDR (308) may send a notification indicating a change in a subscriber profile to the target eUDR (304a). This notification may be triggered by various events such as subscription changes, policy updates, or administrative actions. The notification may include details of the changes made to the subscriber profile.
[00187] At step (816), the target eUDR (304a) may transmit a notification response to the cUDR (308), which may be an acceptance of the received notification. This response may also include an acknowledgment of the successful application of the profile changes at the edge. This mechanism ensures that any changes in subscriber profiles are promptly communicated and acted upon within the network, maintaining consistency between edge and centralized data repositories.
[00188] FIG. 9 illustrates an example flow diagram depicting a method (900) for communication between a new eUDR (304n) and the cUDR (308) when a subscriber moves from an old location to a new location, in accordance with an embodiment of the present disclosure.
[00189] At step (902), the new eUDR (304n) may send a register request to the cUDR (308) to register itself with the cUDR (308) when the subscriber moves to a new location. This registration may include information about the subscriber's new location and the new eUDR (304n)'s capabilities.
[00190] At step (904), the cUDR (308) may transmit a response to the new eUDR (304n), including details of the old eUDR (304o). This information facilitates the handover process between the old and new eUDR (304n)s.
[00191] At step (906), the new eUDR (304n) may transmit a UE context transfer request to the old eUDR (304o). This request may specify the subscriber identifier, and the specific context information needed for service continuity.
[00192] At step (908), the old eUDR (304o) may transmit a context transfer response to the new eUDR (304n), including details of the UE context. This context may include session information, quality of service parameters, security keys, and other relevant data. The new eUDR (304n) can then use this information to maintain service continuity for the subscriber. This process ensures seamless service continuity for subscribers as they move between different network locations, minimizing service disruptions and maintaining consistent user experience.
[00193] In another exemplary embodiment, a user equipment (UE) (108) configured to communicate with a system (102) for performing authentication and authorization of subscribers at an edge of a network is described. The UE (108) may be configured to transmit a registration request to at least one edge network function (eNF) (302a, 302b, 302c). This initial step initiates the authentication and authorization process at the network edge, potentially reducing latency and improving the user experience.
[00194] The UE (108) may be further configured to provide a subscription permanent identifier (SUPI) for fetching a subscriber profile. This SUPI serves as a unique identifier for the UE (108), enabling the network to retrieve the correct subscriber information from the centralized unified data repository (cUDR) (308) via the target enhanced unified data repository (eUDR) (304a). By utilizing this identifier, the system can ensure that the appropriate subscriber data is accessed and used for authentication and authorization purposes.
[00195] Upon verification of the registration request based on subscriber data fetched from the cUDR (308) by the target eUDR (304a), the UE (108) may be configured to establish a session with the at least one eNF (302a, 302b, 302c). This process leverages the edge-based architecture of the system (102), potentially allowing for faster session establishment and improved network performance. The UE (108) may then be able to access network services and resources based on its authenticated and authorized status.
[00196] In yet another exemplary embodiment, a computer program product comprising a non-transitory computer readable medium having a computer readable program embodied therein is described. When executed on a computing device, this program causes the device to perform a series of operations for authentication and authorization of subscribers at the edge of a network. The program enables the computing device to receive, by at least one edge network function (eNF) (302a, 302b, 302c), a registration request from at least one subscriber, and subsequently determine a target enhanced unified data repository (eUDR) (304a) from a plurality of eUDRs (304a, 304b, 304c).
[00197] The computer program further causes the computing device to query, by the target eUDR (304a) via a connected enhanced network repository function (eNRF) (306a, 306b, 306c), a centralized network repository function (cNRF) (310) to discover a centralized unified data repository (cUDR) (308). Once discovered, the program establishes a connection between the target eUDR (304a) and the cUDR (308). This connection facilitates the exchange of subscriber data, with the cUDR (308) receiving a request to fetch a subscriber profile from the target eUDR (304a) corresponding to a subscription permanent identifier (SUPI) of the at least one subscriber.
[00198] The computer program then instructs the target eUDR (304a) to fetch subscriber data corresponding to the subscriber profile from the cUDR (308). Finally, the program enables the at least one eNF (302a, 302b, 302c) to establish a session with the at least one subscriber by verifying the received request based on the fetched subscriber data. This computer program product thus encapsulates the entire edge-based authentication and authorization process, potentially allowing for efficient deployment and management of this functionality across various network environments.
[00199] FIG. 10 illustrates an exemplary computer system (1000) in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 10, the computer system (1000) may include an external storage device (1010), a bus (1020), a main memory (1030), a read only memory (1040), a mass storage device (1050), a communication port (1060), and a processor (1070). A person skilled in the art will appreciate that the computer system (1000) may include more than one processor (1070) and communication ports (1060). Processor (1070) may include various modules associated with embodiments of the present disclosure.
[00200] In an embodiment, the communication port (1060) 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 (1060) 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 (1000) connects.
[00201] In an embodiment, the memory (1030) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (1040) 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 (1070).
[00202] In an embodiment, the mass storage (1050) 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).
[00203] In an embodiment, the bus (1020) communicatively couples the processor(s) (1070) with the other memory, storage and communication blocks. The bus (1020) 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 (1070) to the computer system (1000).
[00204] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (1020) to support direct operator interaction with the computer system (1000). Other operator and administrative interfaces may be provided through network connections connected through the communication port (1060). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (1000) limit the scope of the present disclosure.
[00205] The present disclosure provides technical advancement related to authentication and authorization in edge computing networks. This advancement addresses the limitations of existing centralized authentication solutions by introducing a distributed, edge-based approach. The disclosure involves deploying enhanced unified data repositories (eUDRs) at network edges and implementing a sophisticated discovery and communication mechanism between edge and centralized components, which offer significant improvements in latency reduction and network efficiency. By implementing a target eUDR that can fetch and cache subscriber data locally, the disclosed invention enhances the speed and reliability of subscriber authentication and authorization processes, resulting in improved user experience and more efficient utilization of network resources. Furthermore, the system's ability to handle subscriber mobility and implement different data management models provides a flexible and scalable solution for evolving network architectures, particularly in the context of 5G and future 6G networks.
[00206] While considerable emphasis has been placed herein on 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 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 foregoing descriptive matter to be implemented merely as illustrative of the disclosure and not as limitation.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00207] The present disclosure provides a system and method for performing authentication and authorization of subscribers at the edge of a network, which may significantly reduce latency in the control plane.
[00208] The present disclosure provides a system and method for decreasing response times and improving overall network performance by utilizing edge network functions (eNFs) and enhanced unified data repositories (eUDRs) at the network edge.
[00209] The present disclosure introduces a distributed architecture that may substantially reduce the signalling load towards the main data center or centralized data center for authentication of numerous devices.
[00210] The present disclosure, by employing target eUDRs at various edge locations, the system can manage subscriber data locally, minimizing the need for frequent communications with the centralized unified data repository (cUDR), which may result in more efficient use of network resources.
[00211] The present disclosure implements a highly distributed architecture that may enhance system reliability by eliminating single points of failure. With multiple eUDRs and eNRFs deployed across various edge locations, the system can maintain operation even if individual components fail, potentially improving the overall robustness and availability of the network.
[00212] The present disclosure enables the deployment of enhanced unified data repositories (eUDRs) at the network edge, which may facilitate the edge deployment of other network functions related to authentication, authorization, and policy charging.
[00213] Finally, the present disclosure enables a system and method for maintaining efficient subscriber data management and network performance.
,CLAIMS:CLAIMS

I/We Claim
1. A system (102) for performing authorization of subscribers at an edge of a network (104), the system (102) comprising:
a memory (204); and
a processing engine (208) coupled with the memory to execute a set of instructions stored in the memory (204), the processing engine (208) is configured to:
receive, by at least one edge network function (eNF) (302a, 302b, 302c), a registration request from at least one subscriber;
determine, by the at least one eNF (302a, 302b, 302c), a target enhanced unified data repository (eUDR) (304a) from a plurality of enhanced unified data repositories (eUDRs) (304a, 304b, 304c);
query, by the target eUDR (304a), a centralized network repository function (cNRF) (310) to discover a centralized unified data repository (cUDR) (308) associated with the target eUDR, wherein an enhanced network repository function (eNRF) (306a, 306b, 306c) forwards the query from the target eUDR (304a) to the cNRF (310);
establish, by the target eUDR (304a), a connection between the target eUDR and the discovered cUDR (308);
receive, by the cUDR (308), a request to fetch a subscriber profile from the target eUDR (304a) corresponding to a subscription permanent identifier (SUPI) of the at least one subscriber, wherein the cUDR (308), upon receiving the request, provides the subscriber profile to the target eUDR (304a);
fetch, by the target eUDR (304a), subscriber data corresponding to the subscriber profile from the cUDR (308); and
establish, by the at least one eNF (302a, 302b, 302c), a session with the at least one subscriber by verifying the received request based on the subscriber data.
2. The system (102) as claimed in claim 1, wherein the processing engine (208) is further configured to:
transmit, by the target eUDR (304a), a register request to the eNRF (306a, 306b, 306c); and
receive, by the target eUDR (304a), a response from the eNRF (306a, 306b, 306c) indicating acceptance or decline of the register request.
3. The system (102) as claimed in claim 1, wherein the processing engine (208) is further configured to:
transmit, by the cUDR (308), a register request to the cNRF (310); and
receive, by the cUDR (308), a response from the cNRF (310) indicating acceptance or decline of the register request.
4. The system (102) as claimed in claim 1, wherein for querying the cNRF (310) to discover the cUDR (308) associated with the target eUDR (304a), the processing engine (208) is further configured to:
transmit, by the target eUDR (304a), a cUDR discovery request to the eNRF (306a, 306b, 306c);
forward, by the eNRF (306a, 306b, 306c), the cUDR discovery request to the cNRF (310);
receive, by the eNRF (306a, 306b, 306c), a response from the cNRF (310) including details of available one or more cUDR instances; and
forward, by the eNRF (306a, 306b, 306c), the response to the target eUDR (304a).
5. The system (102) as claimed in claim 1, wherein the processing engine (208) is further configured to:
transmit, by the target eUDR (304a), a register request to the cUDR (308) for a subscriber session;
receive, by the target eUDR (304a), a response from the cUDR (308) indicating initialization of the subscriber session;
send, by the target eUDR (304a), a request for getting subscriber data to the cUDR (308);
receive, by the target eUDR (304a), a response from the cUDR (308) including the subscriber data;
send, by the target eUDR (304a), stored session data to the cUDR (308); and
receive, by the target eUDR (304a), a response from the cUDR (308) indicating completion of updation of the subscriber data.
6. The system (102) as claimed in claim 5, wherein the processing engine (208) is further configured to:
receive, by the target eUDR (304a), a notification from the cUDR (308) indicating a change in the subscriber profile; and
transmit, by the target eUDR (304a), a notification response to the cUDR (308).
7. The system (102) as claimed in claim 1, wherein the processing engine (208) is configured to:
send, by a new eUDR (304n), a register request to the cUDR (308) when the at least one subscriber moves from an old location to a new location;
receive, by the new eUDR (304n), a response from the cUDR (308) corresponding to the register request, wherein the response comprises details of an old eUDR (304o);
transmit, by the new eUDR (304n), a UE context transfer request to the old eUDR (304o); and
receive, by the new eUDR (304n), a context transfer response from the old eUDR (304o) including details of UE context.
8. The system (102) as claimed in claim 1, wherein the one or more processors (202) are further configured to establish the connection between the target eUDR (304a) and the cUDR (308) using at least one of a Hypertext Transfer Protocol 2 (HTTP2) service-based interface and a streaming protocol.
9. The system (102) as claimed in claim 8, wherein the one or more processors (202) are further configured to implement mutual transport layer security (mTLS) between the target eUDR (304a) and the cUDR (308).
10. The system (102) as claimed in claim 1, wherein the one or more processors (202) are further configured to authorize the target eUDR (304a) by the cUDR (308) based on an OAuth 2.0 access token.
11. The system (102) as claimed in claim 1, wherein the processing engine (208) is further configured to integrate the cUDR (308) and the target eUDR (304a) with one of an Operation Support System (OSS) and a Business Support System (BSS) for subscriber provisioning and profile management.
12. The system (102) as claimed in claim 1, wherein the processing engine (208) is further configured to implement a caching model, wherein the target eUDR (304a):
fetches the subscriber data from the cUDR (308) using a service-based interface;
caches the subscriber data for a lifetime of the session; and
stores the subscriber data for a defined time interval before deleting the subscriber data.
13. The system (102) as claimed in claim 1, wherein the processing engine (208) is further configured to implement a storage model, wherein:
the plurality of eUDRs (304a, 304b, 304c) corresponding to various edge locations of a public land mobile network (PLMN) fetch all subscriber data for the PLMN from the cUDR (308) using a streaming interface; and
store the subscriber data in a local storage when each eUDR of the plurality of eUDRs (304a, 304b, 304c) is initialized.
14. A method (400) for performing authorization of subscribers at an edge of a network (104), the method (400) comprising:
receiving (402), by at least one edge network function (eNF) (302a, 302b, 302c), a registration request from at least one subscriber;
determining (404), by the at least one eNF (302a, 302b, 302c), a target enhanced unified data repository (eUDR) (304a) from a plurality of enhanced unified data repositories (eUDRs) (304a, 304b, 304c);
querying (406), by the target eUDR (304a), to a centralized network repository function (cNRF) (310) to discover a centralized unified data repository (cUDR) (308) associated with the target eUDR, wherein an enhanced network repository function (eNRF) (306a, 306b, 306c) forwards the query from the target eUDR (304a) to the cNRF (310);
establishing (408), by the target eUDR (304a), a connection between the target eUDR and the discovered cUDR (308);
receiving (410), by the cUDR (308), a request to fetch a subscriber profile from the target eUDR (304a) corresponding to a subscription permanent identifier (SUPI) of the at least one subscriber, wherein the cUDR (308), upon receiving the request, provides the subscriber profile to the target eUDR (304a);
fetching (412), by the target eUDR (304a), subscriber data corresponding to the subscriber profile from the cUDR (308); and
establishing (414), by the at least one eNF (302a, 302b, 302c), a session with the at least one subscriber by verifying the received request based on the subscriber data.
15. The method (400) as claimed in claim 14, further comprising:
transmitting (502), by the target eUDR (304a), a register request to the eNRF (306a, 306b, 306c); and
receiving (504), by the target eUDR (304a), a response from the eNRF (306a, 306b, 306c) indicating acceptance or decline of the register request.
16. The method (400) as claimed in claim 14, further comprising:
transmitting (602), by the cUDR (308), a register request to the cNRF (310); and
receiving (604), by the cUDR (308), a response from the cNRF (310) indicating acceptance or decline of the register request.
17. The method (400) as claimed in claim 14, wherein querying the cNRF (310) to discover the cUDR (308) associated with the target eUDR (304a)further comprises:
transmitting (702), by the target eUDR (304a), a cUDR discovery request to the eNRF (306a, 306b, 306c);
forwarding (704), by the eNRF (306a, 306b, 306c), the cUDR discovery request to the cNRF (310);
receiving (706), by the eNRF (306a, 306b, 306c), a response from the cNRF (310) including details of available one or more cUDR instances; and
forwarding (708), by the eNRF (306a, 306b, 306c), the response to the target eUDR (304a).
18. The method (400) as claimed in claim 14, further comprising:
transmitting (802), by the target eUDR (304a), a register request to the cUDR (308) for a subscriber session;
receiving (804), by the target eUDR (304a), a response from the cUDR (308) indicating initialization of the subscriber session;
sending (806), by the target eUDR (304a), a request for getting subscriber data to the cUDR (308);
receiving (808), by the target eUDR (304a), a response from the cUDR (308) including the subscriber data;
sending (810), by the target eUDR (304a), stored session data to the cUDR (308); and
receiving (812), by the target eUDR (304a), a response from the cUDR (308) indicating completion of updation of the subscriber data.
19. The method (400) as claimed in claim 18, further comprising:
receiving (814), by the target eUDR (304a), a notification from the cUDR (308) indicating a change in the subscriber profile; and
transmitting (816), by the target eUDR (304a), a notification response to the cUDR (308).
20. The method (400) as claimed in claim 14, further comprising:
sending (902), by a new eUDR (304n), a register request to the cUDR (308) when the at least one subscriber moves from an old location to a new location;
receiving (904), by the new eUDR (304n), a response from the cUDR (308) corresponding to the register request, wherein the response comprises details of an old eUDR (304o);
transmitting (906), by the new eUDR (304n), a UE context transfer request to the old eUDR (304o); and
receiving (908), by the new eUDR (304n), a context transfer response from the old eUDR (304o) including details of UE context.
21. The method (400) as claimed in claim 14, wherein establishing the connection between the target eUDR (304a) and the cUDR (308) comprises using at least one of a Hypertext Transfer Protocol 2 (HTTP2) service-based interface and a streaming protocol.
22. The method (400) as claimed in claim 21, further comprising implementing mutual transport layer security (mTLS) between the target eUDR (304a) and the cUDR (308).
23. The method (400) as claimed in claim 14, further comprising authorizing the target eUDR (304a) by the cUDR (308) based on an OAuth 2.0 access token.
24. The method (400) as claimed in claim 14, further comprising integrating the cUDR (308) and the target eUDR (304a) with one of an Operation Support System (OSS) and a Business Support System (BSS) for subscriber provisioning and profile management.
25. The method (400) as claimed in claim 14, further comprising implementing a caching model, wherein the target eUDR (304a):
fetches the subscriber data from the cUDR (308) using a service-based interface;
caches the subscriber data for a lifetime of the session; and
stores the subscriber data for a defined time interval before deleting the subscriber data.
26. The method (400) as claimed in claim 14, further comprising implementing a storage model, wherein:
the plurality of eUDRs (304a, 304b, 304c) corresponding to various edge locations of a public land mobile network (PLMN) fetch all subscriber data for the PLMN from the cUDR (308) using a streaming interface; and
store the subscriber data in a local storage when each eUDR of the plurality of eUDRs (304a, 304b, 304c) is initialized.