Description:RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as but are not limited to, copyright, design, trademark, integrated circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (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.

TECHNICAL FIELD
[0002] The embodiments of the present disclosure generally relate to telecommunication networks. More particularly, the present disclosure relates to a system and a method for allowing a Radio Access Network (RAN) node to operate independently of a core network.

BACKGROUND
[0003] The following description of the 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 is used only to enhance the understanding of the reader with respect to the present disclosure, and not as an admission of the prior art.
[0004] The fifth generation (5G) communication system, which offers significantly more features than the fourth generation (4G) system, is currently in use. Looking ahead, the sixth generation (6G) communication system is expected to introduce a new paradigm in wireless communication with comprehensive support for artificial intelligence (AI). Beyond 5G, several fundamental issues need to be addressed, such as increasing system capacity, enhancing data rates, reducing latency, and improving quality of service (QoS) compared to the 5G communication system.
[0005] 6G communication systems are expected to introduce novel radio and access architectures for both communications and sensing purposes, AI-optimized wide area networks, and data center co-design, as well as dynamic orchestration of personalized services, to cater to niche consumer interests. While the demand for mobile broadband continues to grow for both consumers and enterprises, the adoption of ultra-reliable and low-latency services is primarily driven by specialized and local use cases in conjunction with non-public networks, often incorporating augmented intelligence, as an integral part of automated and secure network transformation.
[0006] Objects ranging from cars, industrial machines, and appliances to watches and apparel learn and organize to meet the needs by automatically adapting to user’s behaviour, environment, and business processes. Energy efficiency remains a critical design criterion for 6G networks, as the performance of the 6G networks depends on the energy available in the respective architectural domains. One of the most challenging requirements arises from remote control combined with augmented reality and immersive media experiences. This necessitates not only extreme ultra-reliable low latency (URLLC) performance but also ultra-high data rates of 100 Gbit/s or higher, enabling uncompressed transmission of high-quality 360-degree video. Achieving this requires a level of flexibility and specialization beyond what 5G networks can offer.
[0007] Therefore, the 6G networks need to be intent-driven and open-service-driven, with business needs driving the creation of 6G products and services. Product and service creation constitutes an integral part of the automated end-to-end service workflow, steered and guided by policy and intent. In other words, using case-driven approaches meets the diverse needs and preferences of each user or specialized 6G sub-network, whether it involves a human, a physical machine, or a digital twin. Key requirements for 6G architecture include network programmability, deployment flexibility, simplicity and efficiency, security, robustness, reliability, and automation.
[0008] Earlier generations of communication networks supported a concept known as local breakout of data, where data is branched out from a radio access entity into an enterprise/local network. However, such architectures still relied on a core network for signaling and making subsequent decisions for data breakout at the core network entity. Technologies like Local Internet Protocol (IP) Access (LIPA) and Selected IP Traffic Offload (SIPTO) facilitated this process. LIPA is used to offload IP traffic within the enterprise network, completely avoiding the mobile core network or external internet for data traffic. SIPTO is used to selectively offload IP traffic over the internet, bypassing the mobile core network for data traffic.
[0009] In both cases, IP offloading is achieved by introducing a local gateway (LGW) that enables local data breakout as described in various architectural scenarios. However, these solutions still depended on the core network for certain functionalities, limiting their flexibility and independence. The need for interaction with the core network precludes the possibility of operating the radio access entities independently of the core network, which is one of the requirements for 6G.
[0010] There is, therefore, a need for a system and method that can mitigate the problems associated with prior art(s).

OBJECTS OF THE PRESENT DISCLOSURE
[0011] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are listed herein below.
[0012] It is an object of the present disclosure to provide a system and method for operating a radio access network (RAN) independently of a core network.
[0013] It is an object of the present disclosure to enable local authentication and registration of a user equipment without relying on the core network.
[0014] It is an object of the present disclosure to facilitate local allocation of network resources using policies and subscription data maintained within the RAN.
[0015] It is an object of the present disclosure to establish data paths between the user equipment and local/enterprise networks through the RAN.
[0016] It is an object of the present disclosure to improve network efficiency, reduce latency, and enhance reliability in wireless communications.

SUMMARY
[0017] Aspects of the present disclosure generally relate to telecommunications. More particularly, the present disclosure relates to a system and a method for operating a radio access network (RAN) independently of a core network.
[0018] In an aspect, a system for core network independent operation of a RAN includes one or more processors and a memory operatively coupled to the one or more processors. The memory includes processor-executable instructions that, when executed, cause the one or more processors to register a user equipment (UE) with a RAN based on authentication data available at a RAN data repository (RDR), wherein the RDR is coupled to the RAN, and establish a data path between the UE and an enterprise/local network.
[0019] In some embodiments, to register the UE, the one or more processors may be configured to receive a registration request through a corresponding base station, retrieve or create a UE context based on the registration request, and authenticate the UE based on a Subscription Concealed Identifier (SUCI) associated with the UE.
[0020] In some embodiments, if the SUCI is not provided in the registration request, the one or more processors may be configured to transmit an identity request to the UE and receive an identity response from the UE containing the SUCI.
[0021] In some embodiments, to authenticate the UE, the one or more processors may be configured to retrieve the one or more authentication parameters from a data management entity, which may include an authentication vector, a master key, or a Subscription Permanent Identifier (SUPI). The one or more processors may be configured to perform authentication procedures based on the authentication parameters and allocate an Internet Protocol (IP) address to the UE upon successful authentication.
[0022] In some embodiments, the one or more processors may be configured to generate keys based on a security algorithm to secure messages transmitted between the one or more processors and the UE. In some embodiments, the one or more processors may be configured to verify the identity of the UE based on a permanent equipment identity (PEI) or a SUPI, retrieve subscriber data, UE policies, or control policies based on the UE’s identity to update the UE context, and activate one or more Protocol Data Unit (PDU) sessions, allocating a UE IP address and an Uplink Tunnel Endpoint Identifier (UL TEID) for each session based on the UE policies and the control policies.
[0023] In some embodiments, the one or more processors may establish the direct data path between the UE and the local data network based on the UL TEID.
[0024] In an aspect, a method for operating a core-independent RAN includes processing registration requests from UEs based on authentication data available at a RAN data repository (RDR), wherein the RDR is coupled to the RAN, and establishing a direct data path between the UEs and an enterprise or local network. The method includes receiving a registration request from a UE. To register the UE, the method includes verifying the UE’s identity based on a SUCI, retrieving or creating a UE context, and authenticating the UE using the SUCI.
[0025] In some embodiments, if the SUCI is not provided in the registration request, the method may include transmitting an identity request to the UE and receiving an identity response that contains the SUCI. In some embodiments, to perform authentication, the method may include retrieving authentication parameters from a data management entity. These parameters may include an authentication vector, a master key, or a SUPI. The authentication procedures may be performed using these parameters, and upon successful authentication, an IP address may be allocated to the UE.
[0026] In some embodiments, the method may include generating security keys based on a security algorithm to ensure the confidentiality and integrity of messages transmitted between the processors and the UE. This ensures secure communication within the core-independent RAN.
[0027] In an aspect, a UE device includes one or more processors, and a memory operatively coupled to the one or more processors, the memory having one or more processor-executable instructions. Execution of the one or more processor-executable instructions causes the one or more processors to connect with a base station using a Radio Resource Control (RRC) procedure, transmit a registration request to a system through the base station, receive a RRC reconfiguration request, and reconfigure a Data Radio Bearer (DRB), and transmit uplink data and receive downlink data through a data path established by the system associated with a RAN.
[0028] In some embodiments, the one or more processors may be configured to: receive an identity request from the system, generate a SUCI from Public Land Mobile Network (PLMN) public key, and transmit the SUCI through an identity response to the system.
[0029] In some embodiments, the one or more processors may be configured to receive a broadcast from the system indicating that the RAN is in a coreless mode, and switch to RAN-only mode for authorization and authentication.
[0030] Various objects, features, aspects, and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF DRAWINGS
[0031] The accompanying drawings, which are incorporated herein and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems, where like reference numerals refer to the same parts/components 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.
[0032] FIG. 1 illustrates a network architecture of an example system, in accordance with embodiments of the present disclosure.
[0033] FIG. 2 illustrates an example block diagram of a system, in accordance with an embodiment of the present disclosure.
[0034] FIG. 3 illustrates an architecture for a coreless Radio Access Network (RAN) implementing a system, in accordance with an embodiment of the present disclosure.
[0035] FIGs. 4A and 4B illustrate a flow diagram for registration and authentication of a user equipment (UE), and establishment of a data path in a core network-independent RAN, in accordance with an embodiment of the present disclosure.
[0036] FIGs. 5A and 5B illustrate a flow diagram for registration and initial authentication process for the UE, and establishment of a data path in the core network-independent RAN using a RAN data management entity, in accordance with another embodiment of the present disclosure.
[0037] FIG. 6 illustrates an example computer system in which or with which embodiments of the system can be utilized in accordance with embodiments of the present disclosure.
[0038] The foregoing shall be more apparent from the following more detailed description of the disclosure.

BRIEF DESCRIPTION OF THE PRESENT DISCLOSURE
[0039] In the following description, for explanation, various specific details are outlined in order to provide a thorough understanding of the 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.
[0040] 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 scope of the disclosure as set forth.
[0041] 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 to avoid obscuring the embodiments.
[0042] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0043] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0044] 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.
[0045] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items.
[0046] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGs. 1-6.
[0047] FIG. 1 illustrates an example network architecture (100) for implementing a system (202), in accordance with an embodiment of the present disclosure. As illustrated in FIG. 1, one or more computing devices/User Equipment (UE) (102-1, 102-2) (collectively referred to as the UEs (102)) may be connected to a base station (104-1, 104-2) (collectively referred to as the base station (104)) either directly or via a network entity (106). Multiple base stations (104) may be interconnected to form a radio access network (RAN) (108). In an embodiment, each of the base stations (104) may be interconnected via an interface labelled “X2” in FIG. 1. The interfaces X2 may allow for coordination between the base stations (104), such as for handover management and load balancing. In some embodiments, the base stations (104) may be implemented in immovable structures, such as cell towers, for example. In other embodiments, the base stations (104) may be implemented using movable structures, such as unmanned aerial vehicles (UAVs), satellite, and the like, for example. In some embodiments, the base stations (104) may be connected to the system (202) via an interface labelled “S1” in FIG. 1. The interfaces S1 may be used for signaling and data transfer between the base stations (104) and the system (202).
[0048] In some embodiments, the UEs (102) may be configured to directly connect with the base station (104) using the transceivers in the UEs (102). In other embodiments, the network entity (106) may facilitate communication between the RAN (108) and the UEs (102). In some embodiments, the network entity (106) may be indicative of any one or combination of including, but not limited to, Local Area Network (LAN), Wireless Local Area Network (WLAN), Wide Area Network (WAN), Virtual Private Networks (VPN), Intranet, Extranet, and the like, which may allow the UEs (102) to be connected thereto. The network entity (106) may be further connected to the base station (104) using a corresponding set of transceivers. In such embodiments, the network entity (106) may be implemented for providing satellite internet access, or as a dongle Wireless-Fidelity (Wi-Fi) device. In some embodiments, the network entity (106) may be a non-Third-Generation Partnership Project (3GPP) network.
[0049] In some embodiments, the system (202) may include or be associated with a data lake (110), which may be configured to store data from a plurality of data sources. The plurality of data sources may include, but is not limited to, a RAN Data Management Entity (RDM), RAN Data Repository (RDR), Equipment Identity Register (EIR), and the like, as described subsequently in reference to FIG. 3.
[0050] In some embodiments, the UE (102) may include, but not be limited to, a mobile, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, a tablet, a phablet, a dongle, an Internet-of-Things (IoT) device, a drone, an electronic device, and the like. Further, the UEs (102) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, audio aid, microphone, or keyboard. Additionally, input devices for receiving input from a user such as a touchpad, touch-enabled screen, electronic pen, and the like may be used. A user may use the UEs (102) to communicate with other users using UEs (102) connected to the RAN (108). The services that may be availed by the UEs (102) from the RAN (108) may include, but are not limited to, voice calls, video calls, messaging, internet connectivity, and the like. In some embodiments, the services may involve the transmission and reception of data packets between the UEs (102) and the RAN (108). For example, the RAN (108) may enable two or more UEs (102) to initiate a communication session through the network entity (106). Although two UEs (102) are depicted in FIG. 1, it may be appreciated that any number of UEs (102) may be implemented without departing from the scope of the present disclosure.
[0051] In some embodiments, the RAN (108) may conform to standards set by the 3rd Generation Partnership Project (3GPP) or represent one or more Radio Access Networks (RANs) associated with Radio Access Technologies (RATs) such as Sixth-Generation (6G), Fifth-Generation (5G), and Fourth-Generation (4G), though not limited to these generations. In some embodiments, the RAN (108) may be configured to communicate with a core network (not shown). The core network may include a plurality of network functions/network entities which may allow the RAN (108) to provide the services to the UEs (102).
[0052] In some embodiments, each of the network functions may be implemented on a hardware component, or a software component, or a combination thereof. In some examples, the network functions may be implemented on a processor, a microcontroller, a digital signal processor, a central processing unit, an integrated circuit, or the like. In such examples, the network functions may be configured to execute one or more processor-executable instructions to perform a predetermined set of operations. The network functions may be communicatively coupled to transmit and receive requests from each other to allow the RAN (108) to provide services to the UEs (102).
[0053] In some embodiments, the RAN (108) may include a system (202) that allows the RAN (108) to provide the services to the UEs (102) without requiring communication with the core network. The system (202) may be configured to perform activities otherwise performed by the network functions (such as registration and/or authentication of the UEs (102), among other activities, for example) and may allow the UEs (102) to be connected to an enterprise/local network (302). The local network (302) may be a network distinct from the core network, which is operated by a separate organization/entity. For example, the local network (302) may be a LAN network implemented and operated by a particular enterprise. The local network (302) may include local databases and servers that may be configured to provide data and/or other services that are specific to the entity. For example, the local network (302) may be configured to provide dashboards, platforms, or interfaces for enterprise specific data. In other examples, the local network (302) may be indicative of IoT devices operated by an entity, where the IoT devices may be configured to sense and process data in their vicinity. The UEs (102) may be allowed to access and communicate with the IoT devices using the system (202). In some embodiments, the system (202) may be configured to operate as a core-independent gateway that allows the RAN (108) to register and authenticate the UEs (102) independently of the core network, and establish data paths between the UEs (102) and the local network (302).
[0054] In an embodiment, the system (202) may receive a registration request from the UEs (102). Upon receiving the registration request, the system (202) authenticates and registers the UEs (102) using authentication data stored and generated locally within the RAN (108), which may involve receiving the registration request through a corresponding base station (104). In some embodiments, the authentication data may be stored in the RDR (such as RDR (312) of FIG. 3). In some embodiments, the data in the RDR may be accessible through the RDM. In some embodiment, once the registration request is received, the system (202) retrieves or creates a UE context based on the registration request, and authenticates the UEs (102) based on a Subscription Concealed Identifier (SUCI) associated with the UEs (102). In cases where the SUCI is not provided in the registration request, the system (202) may transmit an identity request to the UEs (102) and receive an identity response containing the SUCI.
[0055] In some embodiments, the authentication process may involve retrieving authentication parameters from a data management entity (such as the RDM) within the RAN (108). The authentication parameters may include an authentication vector, a master key, or a Subscription Permanent Identifier (SUPI). Upon successful authentication, the system (202) may be configured to allocate an Internet Protocol (IP) address to the UEs (102). The system (202) may also be configured to generate keys based on a security algorithm to secure messages transmitted between the system (202) and the UEs (102). The system (202) may be configured to allocate network resources to the UEs (102) using policies and subscription data maintained within the RAN (108), such as in the RDR thereof. The RDR may be used for verifying the identity of the UEs (102) based on a permanent equipment identity (PEI) or SUPI, and also for retrieving subscriber data, UE policies, or control policies to update the UE context, and activating one or more Packet Data Unit (PDU) sessions. The system (202) may be configured to establish a direct data path between the UEs (102) and the enterprise/local network (302) through the RAN (108). The data path may be based on an Uplink Tunnel Endpoint Identifier (UL TEID) for each (PDU) session, determined by the UE policies and control policies associated with the UEs (102).
[0056] The system (202), may be configured to provide a core-independent RAN, thereby enhancing performance, security, and flexibility, particularly for enterprise and campus environments. Details of the system (202) are further described in the forthcoming disclosure.
[0057] 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). The network architecture (100) may be suitably adapted based on the requirements.
[0058] FIG. 2 illustrates an example block diagram (200) of the system (202), in accordance with an embodiment of the present disclosure.
[0059] With reference to FIG. 2, the system (202) may include one or more processor(s) (204) that may be implemented as one or more microprocessors, microcomputers, 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) (204) may be configured to fetch and execute computer-readable instructions stored in a memory (206) of the system (202). The memory (206) 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 (206) may include 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.
[0060] In an embodiment, the system (202) may include an interface(s) (208). The interface(s) (208) may include a variety of interfaces, for example, interfaces for data input and output (I/O) devices, storage devices, and the like. The interface(s) (208) may also provide a communication pathway for one or more components of the system (202). Examples of such components include, but are not limited to, processing engine(s) (210) and a database (222), where the processing engine(s) (210) may include, but not be limited to, a receiving engine (212), a determination engine (214), an authentication engine (216), a service providing engine (218), and other engine(s) (220). The other engine(s) (220) may include, but is not limited to, a monitoring engine, and the like. [0061] In an embodiment, the processing engine(s) (210) may be implemented as a combination of hardware and software/programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) (210). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the software/programming for the processing engine(s) (210) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (210) may include a processing resource (for example, one or more processors), to execute such instructions.
[0062] In the present examples, the computer-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (210). In such examples, the system (202) may include the computer-readable storage medium storing the instructions and the processing resource to execute the instructions, or the computer-readable storage medium may be separate but accessible to the system (202) and the processing resource. In other examples, the processing engine(s) (210) may be implemented by electronic circuitry.
[0063] In an embodiment, the processors (204), via the receiving engine (212), may be configured to receive a registration request from a UE, such as the UEs (102). For example, the registration request may be received first at a base station, such as the base station (104) corresponding to the UE (102), and the base station (104) transmits the request to the receiving engine (212) of the system (202).
[0064] In an embodiment, after the receiving engine (212) receives the registration request from the UE (102) via the base station (104), the determination engine (214) may be configured to perform an integrity check on the registration request to ensure its validity. The determination engine (214) may be configured to determine whether there is an existing UE context associated with the UE (102). The determination engine (214) may use identification parameters from the registration request, such as a SUCI, International Mobile Subscriber Identity (IMSI), or another unique identifier provided by the UE (102), to search for the UE context. The system (202) may be configured to maintain the database (222) where all the active and previously registered UE contexts are stored. The determination engine (214) queries the database (222) using the unique identification parameters to check if there is a pre-existing entry for the UE (102). If a matching UE context is found in the database (222), the determination engine (214) retrieves this UE context. The UE context may include all previously established information about the UE (102), such as its security keys, session information, policies, IP addresses, and other relevant data. Using the existing UE context allows the system (202) to resume communication with the UE (102) without repeating the entire setup process. In an embodiment, if no existing UE context for the UE (102) is found in the database (222), the determination engine (214) may create a new UE context for the UE (102) based on the registration request.
[0065] In an embodiment, once the UE context is created, the authentication engine (216) may be configured to send an identity request to the UE (102) through the base station (104) to obtain the SUCI, if the SUCI is not provided in the registration request. The UE (102) may generate the SUCI using a Public Land Mobile Network (PLMN) public key and send the identity response including the SUCI back to the authentication engine (216). Once the SUCI is received, the authentication engine (216) may send a UE authentication request to an authentication, such as a RAN-Authentication Server Function (R-AUSF). The UE authentication request may include the SUCI therein. Upon receiving the SUCI, the R-AUSF may decrypt the SUCI to retrieve the SUPI. The SUPI, once retrieved, may be used to fetch the authentication credentials and parameters of the UE (102) from the RDM entity. Accordingly, the R-AUSF may send a UE authentication request to the RDM entity along with the SUPI. The RDM entity may initiate the authentication process for the UE (102) and may generate one or more authentication vectors (AVs) (or alternatively authentication certificates, keys, and the like) for the session based on the SUPI. The RDM entity may respond with a UE authentication response, providing the AVs to the R-AUSF. Based on the response from the RDM entity, the R-AUSF may reply back to the authentication engine (216) with the AVs, a master key, and the SUPI.
[0066] In an embodiment, the authentication engine (216) may send/transmit the authentication request having the AVs, back to the UE (102) through the base station (104). The UE (102) processes the authentication request using the AVs and generates an authentication response. The UE (102) may send the response back to the authentication engine (216). The authentication engine (216) performs a final check to ensure the response from the UE (102) matches the expected outcome. Upon successful authentication of the UE (102), the authentication engine (216) may send a security mode command to the UE (102) via the base station (104), specifying security algorithms to use, such as Non-Access Stratum (NAS) for example. The UE (102) may acknowledge the security mode command by sending a security mode complete message back to the authentication engine (216) via the base station (104). In an embodiment, the authentication engine (216) may send an equipment identity check request to an EIR to verify the PEI of the UE (102) and the SUPI. The EIR may respond with the result of the equipment identity check, indicating whether the UE (102) is valid and allowed on the RAN (108). Once the UE (102) is validated, the authentication engine (216) may retrieve subscriber data, UE policies, or control policies from the RDM entity based on the identity of the UE (102) to update the UE context and activate one or more PDU sessions, and allocates a UE IP address and UL TEID for each session based on the UE policies and control policies associated with the UE (102).
[0067] In an embodiment, the service providing engine (218) establishes a data path between the UE (102) and the local network (302) based on the UL TEID, and a downlink TEID generated by the base station (104).
[0068] Thus, by managing registration, authentication, policy enforcement, and session management locally within the RAN (108) without relying on a centralized core network, the system (202) achieves core-independent functionality, which allows for faster, more efficient processing and local data handling, enhancing the overall performance and reliability of the network.
[0069] Although FIG. 2 shows some components of the system (202), in other embodiments, the system (202) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (202) may perform functions described as being performed by one or more other components of the system (202).
[0070] FIG. 3 illustrates an example architecture (300) for implementing a coreless operation of the RAN (108), in accordance with an embodiment of the present disclosure.
[0071] Referring to FIG. 3, in an embodiment, the architecture (300) includes the local network (302). In some embodiments, the local network (302) may include an Enhanced Data rates for Global System for Mobile Communications (GSM) Evolution (EDGE) server (304), which provides local services and data processing services to the UE (102). The architecture (300) may support local authentication of the UEs (102), through the local network (302) at the RAN (108) itself. The architecture (300) may also include the base station (104) that handles communication with the UEs (102). The base station (104) may include different components, such as a plurality of Central Units (CUs) (such as 6gNB-CU 1 (306-1) to 6gNB-CU N (306-N)), a plurality of Distributed Units (DUs) (such as 6gNB-DU 1 (308-1) to 6gNB-DU M (308-M)), and a plurality of Radio Units (RUs) (such as 6gNB-RU 1 (310-1) to 6gNB-RU P (310-P)). In one embodiment, entities such as an RDR entity (312) and an RDM entity (314) may be included in the RAN (108).
[0072] In an embodiment, the RDR entity (312) may be configured to store RAN/UE policy, subscription data, EIR, security keys, and the like. The RDR entity (312) may also store data collected on control and data planes during RAN operation. In some embodiments, the RDR entity (312) may be implemented as a database. In some embodiments, the RDR entity (312) may be configured to store data associated with the local network (302) and/or the UEs (102) that request services from the local network (302). In some embodiments, the RDR entity (312) may be configured to intermittently connect to the core network, and fetch and store information/data therefrom. For example, for the UEs (102) that frequently connect to the local network (302), the RDR entity (312) may be configured to fetch and store the corresponding subscriber data, UE policy data, and the like, when the RDR entity (312) connected to the core network. The RDM entity (314) may be configured to generate authentication keys/certificates/vectors, may be configured to perform equipment identity checks using the PEI, and utilizes whitelist and/or blacklist tables. The RDM entity (314) may also manage access and mobility subscription data, handles UE policy, access and mobility control policies, and the like, and prepare policy association information.
[0073] In some embodiments, to facilitate the UE (102) to function in a coreless RAN mode, the base station (104) may be configured to advertise/broadcast that the RAN (108) is working/operating in a core-independent mode. Once the UE (102) receives the broadcast, the UE (102) switches to a RAN-only mode of authentication and authorization. In such embodiments, the UE (102) may be configured to initiate a connection by sending a registration request to the 6gNB-RU 1 (310-1). The 6gNB-RU 1 (310-1) may forward the registration request to the 6gNB-DU 1 (308-1) for processing. The 6gNB-DU 1 (308-1) communicates with the 6gNB-CU 1 (306-1), which then sends a subscriber data management get request to the RDM entity (314) through the system (202). The RDM entity (314) may respond with access and mobility subscription data, which the 6gNB-CU 1 (306-1) may use to update the UE context.
[0074] The 6gNB-CU 1 (306-1) may send a UE policy info request to the RDM entity (314) for policy association, access, and mobility control. The RDM entity (314) may be configured to retrieve and create UE policy associations and respond with the necessary policies. The 6gNB-CU 1 (306-1) may activate the list of PDU sessions, allocates IP addresses, and assigns UL TEIDs for each session. The 6gNB-CU 1 (306-1) may send an initial context setup request to the 6gNB-DU 1 (308-1), which may process the registration and configures the Data Radio Bearers (DRBs). The 6gNB-DU 1 (308-1) may complete the Radio Resource Control (RRC) reconfiguration and updates the 6gNB-CU 1 (306-1). The 6gNB-CU 1 (306-1) may allocate DL TEIDs for each PDU session and sends the initial context setup response. The UE (102) may complete the registration process and begins data transmission.
[0075] The local network (302) may process UL and DL data locally, ensuring low latency and enhanced performance for services used within the campus or enterprise. The EDGE server (304) in the local network (302) provides services directly within the RAN (108), facilitating efficient handovers and mobility management without core network involvement.
[0076] Thus, the elements of the architecture (300) provide a core-independent 6G RAN. Local data processing, direct communication, localized control functions, and the ability to operate in dual modes ensure that the RAN (108) operates effectively without depending on a core network.
[0077] FIGs. 4A to 5B illustrate flow diagrams of the system (202) interacting with other components/entities in order to provide services to the UEs (102) without requiring connection with the core network. FIGs. 4A and 4B illustrate embodiments where the R-AUSF (such as R-AUSF (402)) and EIR (such as EIR (404)) are implemented outside the RDM entity (314). FIGs. 5A and 5B illustrate embodiments where the R-AUSF (402) and the EIR (404) are implemented within the RDM (314). FIG. 4A illustrates a flow diagram of a method (400) for registration and authentication of UE (102) in the core network-independent RAN (108).
[0078] As is illustrated in FIG. 4A, at step (406), once the UE (102) completes RRC setup, the UE (102) may send a registration request to a base station, such as the base station (104). At step (408), the system (202) may receive the registration request from the base station (104). At step (410), the system (202) may perform an integrity check, and at step (412), the system (202) may search/retrieve the UE context. If the UE context is not found, the system (202) creates the UE context, at (414), the system (202) may transmit an identity request to the base station (104) which is then relayed to the UE (102). At step (416), the UE (102) may generate the SUCI using a Public Land Mobile Network (PLMN) public key, and at step (418), the UE (102) may transmit the identity response having the SUCI back to the system (202) via the base station (104).
[0079] Further, at step (420), the system (202) may transmit a UE authentication request to the R-AUSF (402), with the SUCI. At step (422), the R-AUSF (402) may request AVs from the RDM (314). At step (424), the RDM (314) may generate the AVs for the PDU session. At step (426), the RDM (314) may transmit the generated AVs back to the R-AUSF (402) as a UE authentication get response message. At step (428), the R-AUSF (402) may transmit the AVs to the system (202) in a UE authentication response message. At step (430), the system (202) may transmit an authentication request to the UE (102) via the base station (104). At step (432), the UE (102) may process the authentication request, and transmit an authentication response back to the system (202) via the base station (104). Upon successful authentication, at step (434), the system (202) may transmit a security mode command to the UE (102) via the base station (104), specifying the NAS security algorithms to use. At step (436), the UE (102) may acknowledge the security mode command by sending a security mode complete message back to the system (202) via the base station (104), and provide International Mobile Station Equipment Identity Software Version (IMSEISV) therein. At step (438), the system (202) may transmit an equipment identity check request to the EIR (404) to verify the PEI and the SUPI associated with the UE (102). The EIR (404) may respond with the result of the equipment identity check, indicating whether the equipment is valid and allowed on the network at step (440).
[0080] This ensures that the UE (102) is securely registered and authenticated within the core network-independent RAN before data transmission can take place. The system (202) which is the RAN gateway plays a central role in coordinating the communication between the UE (102) and the various network entities (base station, R-AUSF, RDM, and EIR) to achieve secure and efficient registration and authentication. The core-independence is indicated by the local handling of the SUCI, AVs, and equipment identity verification, which are all managed within the RAN infrastructure without requiring constant interaction with the core network.
[0081] FIG. 4B illustrates continues the flow diagram of the method (400) from FIG. 4A.
[0082] On successful identification, at step (442), the system (202) may transmit a subscriber data management get request to the RDM (314), requesting access and mobility subscription data for the UE (102). At (444), the RDM (314) may respond with the subscriber data management get response, providing access and mobility subscription data. At step (446), the system (202) may update the UE context with the retrieved subscription data. At step (448), the system (202) may transmit a UE policy info request to the RDM (314), requesting UE policy association, access, and mobility control policies. At step (450), the RDM (314) may retrieve and create UE policy associations, such as based on the subscription data. At step (452), the RDM (314) may respond with the UE policy info response, providing UE policy association, access, and mobility control policies. On receiving the UE policy info response, the system (202) may be configured to activate a corresponding set of PDU sessions, and UE IP addresses and UL TEIDs for each PDU session.
[0083] At step (454), the system (202) may transmit an initial context setup request to the base station (104), which may be forwarded to the UE (102). The initial context setup request may include registration accept, UE IP address, and UL TEIDs, but not limited thereto. At step (456), access stratum (AS) ciphering and integrity protocols may be activated between the UE (102) and the base station (104). At step (458), the base station (104) may transmit an RRC reconfiguration message to the UE (102), which includes the registration accept and bearer setup information. The UE (102) may configure its data radio bearer (DRB) based on the RRC reconfiguration message. At step (460), the UE (102) responds with RRC reconfiguration complete, indicating that the RRC reconfiguration (or DRB configuration) has been completed. At step (462), the base station (104), may be configured to allocate the DL TEIDs for the PDU sessions. At step (464), the base station (104) may transmit an initial context setup response back to the system (202), providing the DL TEIDs. At step (466), the UE (102) may transmit a registration complete message to the system (202) via the base station (104). Based on the allocated UL TEID and the DL TEID, the data path between the UE (102) and the local network (302) may be established.
[0084] This process ensures that the UE (102) is securely registered, authenticated, and connected to the local data network within a core network-independent RAN (108). The system (202) coordinates the communication between the UE (102) and other network entities (base station (104), R-AUSF (402), RDM (314), and EIR (4040)) to establish a secure and efficient data path for uplink and downlink data transmission.
[0085] As stated, FIGs. 5A and 5B illustrate an example embodiment where the R-AUSF (402) and the EIR (404) may be part of the RDM (314). In such a case, the registration procedure for the UE (102) may be provided through method (500).
[0086] At step (502), after the UE (102) completes the RRC setup, the UE (102) may transmit a registration request to the base station (104). At step (504), the base station (104) may forward the registration request to the system (202). At step (506), the system (202) may check the integrity of the request, and, at step (508), may search for the UE context if it exists, or create a new UE context. At step (510), the system (202) may transmit an identity request to the UE (102) via the base station (104). At step (512), the UE (102) may create the SUCI using the PLMN public key and, at step (514), respond to the system (202) with an identity response with the SUCI. At step (516), the system (202) may transmit the UE authentication request to the RDM (314). At step (518), the RDM (314) may initiate the authentication process and, at step (520), generate the AVs. At step (522), the RDM (314) may transmit the UE authentication response to the system (202), providing the AVs, the master key, and the SUPI. At step (524), the system (202) may transmit the authentication request to the UE (102) via the base station (104). At step (526), the UE (102) may transmit with the authentication response to acknowledge the authentication request. At step (528), the system (202) may transmit the NAS security mode command to the UE (102) via the base station (104), specifying the non-access stratum (NAS) security algorithms. At step (530), the UE (102) may transmit the NAS security mode complete message, in response to the NAS security mode command. At step (532), the system (202) may transmit the equipment identity check request to the RDM (314), along with the PEI and the SUPI. At step (534), the RDM (314) may return the equipment identity check response to the system (202).
[0087] Further, as continued in FIG. 5B, the method (500) may include step (536), where the system (202) may be configured to transmit the subscriber data management get request to the RDM entity (314), requesting access and mobility subscription data for the UE (102). At step (538), the RDM entity (314) may respond with the subscriber data management get response, providing the requested subscription data. At step (540), the system (202) may be configured to update the UE context with the retrieved subscription data. Further, at step (542), the system (202) transmits the UE policy info request to the RDM entity (314), which at (544), retrieves and creates the necessary UE policy associations and, at step (546), transmits the UE policy info response back to the system (202). At step (548), the system (202) may be configured to activate the list of PDU sessions and allocate UE IP addresses and UL TEIDs for each session.
[0088] At step (550), the system (202) may transmit the initial context setup request to the base station (104), including details such as registration acceptance, UE IP address, and UL TEIDs. At step (552), the AS ciphering and integrity may be activated between the UE (102) and the base station (104).
[0089] At step (554), the base station (104) may transmit the RRC reconfiguration message to the UE (102), which includes registration acceptance and bearer setup information, and at step (556), the UE (102) may respond with the RRC reconfiguration complete message.
[0090] At step (558), the base station (104) may allocate the DL TEIDs for each PDU session. At step (560), the base station (104) may transmit the initial context setup response to the system (202), with the DL TEIDs. At step (562), the UE (102) may transmit the registration complete message to the base station (104) and the system (202). The system (202) may establish the data path between the UE (102) and the local network (302). The data path may allow UL and DL data to be transported locally, ensuring low latency and enhanced performance for services used within the campus or enterprise.
[0091] Since the authentication and registration of the UE (102), and the establishment of the data paths are performed by the system (202) independently, the present disclosure supports a core network-independent operation by enabling local data processing, direct communication, and localized control functions, thereby allowing the RAN (108) can operate without relying on the core network.
[0092] FIG. 6 illustrates an exemplary computer system (600) in which or with which the proposed system (202) may be implemented, in accordance with embodiments of the present disclosure.
[0093] As shown in FIG. 6, the computer system (600) may include an external storage device (610), a bus (620), a main memory (630), a read-only memory (640), a mass storage device (650), a communication port(s) (660), and a processor (670). A person skilled in the art will appreciate that the computer system (600) may include more than one processor and communication ports. The communication port(s) (660) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects. The main memory (630) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor (670). The mass storage device (650) may be any current or future mass storage solution, which can be used to store information and/or instructions.
[0094] The bus (620) may communicatively couple the processor (670) with the other memory, storage, and communication blocks. Optionally, operator and administrative interfaces, e.g., a display, keyboard, and cursor control device may also be coupled to the bus (620) to support direct operator interaction with the computer system (600). Other operator and administrative interfaces may be provided through network connections connected through the communication port(s) (660). In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.
[0095] 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 is to be implemented merely as illustrative of the disclosure and not as a limitation.

ADVANTAGES OF THE PRESENT DISCLOSURE
[0096] The present disclosure reduces latency in data transmission by eliminating the need to communicate with a core network for authentication, resource allocation, data routing, and the like.
[0097] The present disclosure ensures that local network functions can continue to function even in the event of core network failures or connectivity issues.
[0098] The present disclosure enables local authentication and key generation to provide a secure environment for sensitive enterprise or local network communications.
[0099] The present disclosure provides local management of policies and subscription data allowing for efficient allocation and use of network resources.
[00100] The present disclosure provides a core-independent architecture that facilitates easier deployment of private or localized networks without the need for core network infrastructure.
[00101] The present disclosure reduces reliance on core network infrastructure, lowering operational costs for network operators and enterprises.
 
, Claims:1. A system (202) for core network independent operation of radio access network (RAN), comprising:
one or more processors (204); and
a memory (206) operatively coupled to the one or more processors (204), the memory having one or more processor-executable instructions, which, when executed, cause the one or more processors (204) to:
register a user equipment (UE) (102) with a RAN (108) based on authentication data available at a RAN data repository (RDR), wherein the RDR is coupled to the RAN (108); and
establish a data path between the UE (102) and a local network (302).
2. The system (202) as claimed in claim 1, wherein to register the UE (102), the one or more processors (204) are configured to:
receive a registration request through a base station (104);
retrieve or create a UE context based on the registration request; and
authenticate the UE (102) based on Subscription Concealed Identifier (SUCI) associated with the UE (102).
3. The system (202) as claimed in claim 2, wherein the one or more processors (204) are configured to:
transmit an identity request to the UE (102) when the SUCI is not provided in the registration request; and
receive an identity response from the UE (102), wherein the identity response comprises the SUCI.
4. The system (202) as claimed in claim 2, wherein to authenticate the UE (102), the one or more processors (204) are configured to:
retrieve, from a RAN data management entity (314), one or more authentication parameters, wherein the authentication parameters comprise at least one of: an authentication vector, a master key, or a Subscription Permanent Identifier (SUPI);
perform authentication procedures based on the authentication parameters; and
allocate an Internet Protocol (IP) address to the UE (102) based on successful authentication.
5. The system (202) as claimed in claim 1, wherein the one or more processors (204) are configured to generate keys based on a security algorithm to secure messages transmitted between the one or more processors (204) and the UE (102).
6. The system (202) as claimed in claim 1, wherein the one or more processors (204) are further configured to:
verify identity of the UE (102) based on at least one of: permanent equipment identity (PEI) or Subscription Permanent Identifier (SUPI);
retrieve at least one of: subscriber data, UE policies, or control policies, based on the identity of the UE (102) to update the UE context; and
activate one or more Protocol Data Unit (PDU) sessions, and allocate UE Internet Protocol (IP) address and Uplink Tunnel Endpoint Identifier (UL TIED) for each PDU session based on the UE policies and the control policies associated with the UE (102).
7. The system (202) as claimed in claim 1, wherein the one or more processors (204) are configured to establish the data path between the UE (102) and the local data network (302) based on Uplink Tunnel Endpoint Identifier (UL TEID).
8. A method for operating a core-independent radio access network (RAN), comprising:
registering, by one or more processors (204), a user equipment (UE) (102) with a RAN (108) based on authentication data available at a RAN data repository (RDR), wherein the RDR is coupled to the RAN (108); and
establishing, by the one or more processors (204), a data path between the UE (102) and an enterprise/local network (302).
9. The method as claimed in claim 8, wherein for registering the UE (102), the method comprises:
receiving, by the one or more processors (204), a registration request through a corresponding base station (104);
retrieving or creating, by the one or more processors (204), a UE context based on the registration request; and
authenticating, by the one or more processors (204), the UE (102) based on Subscription Concealed Identifier (SUCI) associated with the UE (102).
10. The method as claimed in claim 9, comprising:
transmitting, by the one or more processors (204), an identity request to the UE (102) when the SUCI is not provided in the registration request; and
receiving, by the one or more processors (204), an identity response from the UE (102), wherein the identity response comprises the SUCI.
11. The method as claimed in claim 9, wherein authenticating the UE (102) comprises:
retrieving, by the one or more processors (204), from a RAN data management entity (314), one or more authentication parameters, wherein the authentication parameters comprise at least one of: an authentication vector, a master key, or a Subscription Permanent Identifier (SUPI);
performing, by the one or more processors (204), authentication procedures based on the authentication parameters; and
allocating, by the one or more processors (204), an Internet Protocol (IP) address to the UE (102) based on successful authentication.
12. The method as claimed in claim 8, comprising generating, by the one or more processors (204), keys based on a security algorithm to secure messages transmitted between the one or more processors (204) and the UE (102).
13. A user equipment (UE) (102), comprising:
one or more processors; and
a memory operatively coupled to the one or more processors, the memory having one or more processor-executable instructions, which, when executed, cause the one or more processors to:
connect with a base station (104) using a Radio Resource Control (RRC) procedure;
transmit a registration request to a system (202) through the base station (104);
receive a RRC reconfiguration request, and reconfigure a Data Radio Bearer (DRB); and
transmit uplink data and receive downlink data through a data path established by the system (202) associated with a RAN (108).
14. The UE (102) as claimed in claim 13, wherein the one or more processors are configured to:
receive an identity request from the system (202);
generate Subscriber Concealed Identifier (SUCI) from Public Land Mobile Network (PLMN) public key; and
transmit the SUCI through an identity response to the system (202).
15. The UE (102) as claimed in claim 13, wherein the one or more processors are configured to:
receive a broadcast from the system (202) indicating that the RAN (108) is in a coreless mode; and
switch to RAN-only mode for authorization and authentication.