System and method for coreless radio access network nodes

Abstract

The present disclosure provides systems and methods that enable a coreless network architecture, not connected to or dependent on a core network, by proposing Radio Access Network (RAN) nodes to provide network coverage and network services to user equipment (UE). In one embodiment, the RAN nodes may be mobile RAN nodes that form part of a fleet to provide network coverage and network services to UEs in any geographic location depending on requirements. The present disclosure also proposes mechanisms for the mobile RAN nodes to intermittently communicate with each other and, where available, with the core network and data network (ISP).

Description

[Technical Field]

[0001] Protection of rights Portions of the disclosure of this patent document contain material that is subject to intellectual property rights, including, but 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 the Owner). The Owner has no objection to the facsimile reproduction of the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all rights. All rights to such intellectual property are fully reserved by the Owner.

[0002] Embodiments of the present disclosure generally relate to systems and methods for providing a sixth generation (6G) coreless architecture, and more particularly, to systems and methods for providing a Radio Access Network (RAN) architecture that can operate without a core network. [Background technology]

[0003] The following description of related art is intended to provide background information related to the field of the present disclosure. This section may include specific aspects of technology that may be related to various features of the present disclosure. However, it should be understood that this section is intended solely to enhance the reader's understanding of the present disclosure and is not intended as an admission of prior art.

[0004] Fifth-generation (5G) communications have many more features than fourth-generation (4G) communications and have been launched in many countries. Sixth-generation (6G) systems, a new paradigm of wireless communications with full support for artificial intelligence (AI), are expected to be deployed in the next decade or so. There may be several fundamental issues that need to be resolved in implementing networks beyond 5G (e.g., 6G systems). These network challenges include higher system capacity, higher data rates, lower latency, and higher quality of service (QoS) compared to 5G systems.

[0005] 5G wireless technology, developed by 3GPP (registered trademark), aims to provide more users with higher multi-Gbps peak data speeds, ultra-low latency, higher reliability, higher network capacity, higher availability, and a more uniform user experience. Higher performance and improved efficiency will enable new user experiences and connect new industries. While some of the above goals have been achieved, significant challenges remain, particularly with regard to industry-specific support, architectures supporting private networks, and architectures supporting flexible network deployment. All aspects of network coverage and services are heavily dependent on the core network, limiting solutions to the above problems. Furthermore, the fixed nature of RAN nodes further limits network flexibility and service options in 5G / 6G networks.

[0006] Therefore, there is a strong need for a 5G / 6G network architecture that can address the network flexibility issue and at least the above-mentioned problems, specifically, a coreless mode of operation for the RAN and mobile RAN nodes that provide network coverage / services in the coreless mode.

[0007] Therefore, there is a need in the art to provide a system and method that can alleviate the problems associated with the prior art. Summary of the Invention [Problem to be solved by the invention]

[0008] Some of the objectives of the present disclosure that are met by at least one embodiment herein are listed below.

[0009] The objective of this disclosure is to support coreless RAN functionality that better supports mobile radio access operations and can be used as a fundamental building block in 6G network architectures.

[0010] An objective of the present disclosure is to provide a fleet of Mobile RAN nodes or Unmanned Aerial Vehicles (UAVs) that communicate with each other to provide network coverage and network services to UEs.

[0011] The objective of this disclosure is to provide a mechanism for inter-RAN node communication in a coreless mode of operation for mobile RAN nodes / UAVs.

[0012] The objective of the present disclosure is to provide network facilities in all terrains. [Means for solving the problem]

[0013] Aspects of the present disclosure generally relate to systems and methods for providing a sixth-generation (6G) coreless architecture. Specifically, the present disclosure relates to systems and methods for providing a radio access network (RAN) architecture that can operate without a core network.

[0014] In one aspect, a system for reporting a connection status between a Radio Access Network (RAN) node and a Core Network (CN) includes one or more processors; and a memory operatively coupled to the one or more processors and including one or more processor-executable instructions that, when executed, cause the one or more processors to obtain connection schedule data indicating a schedule for the system to connect to the CN and periodically transmit the connection schedule data in a set of dedicated signals to one or more User Equipments (UEs).

[0015] In another aspect, a user equipment has one or more processors; and a memory operatively coupled to the one or more processors, the memory including one or more processor-executable instructions that, when executed, cause the one or more processors to receive a set of dedicated signals from a Radio Access Network (RAN) node and establish a communication channel with the RAN node based on connection schedule data included in the set of dedicated signals.

[0016] In yet another aspect, a Radio Access Network (RAN) node for providing services to user equipment may include a Uu stack having a Radio Frequency (RF) unit configured to exchange radio signals with one or more UEs requesting service from the RAN node, a RAN-node-to-RAN node interface configured to communicate with other RAN nodes, and a local Core Network (CN) configured to process operational data associated with the one or more UEs and communicate with the one or more UEs using the Uu stack, wherein the local CN may be configured to communicate with the other RAN nodes using the RAN-node-to-RAN node interface to exchange the operational data necessary to provide the service to the one or more UEs.

[0017] In some embodiments, the local CN may comprise a local CN Control Plane (CP) configured to process the operational data to provide services to the one or more UEs, and a local CN User Plane (UP) configured to receive and transmit the operational data between the local CN CP of the RAN node and the one or more UEs, other RAN nodes, or CNs.

[0018] In some embodiments, the RAN node may further comprise a local CN UP cache configured to store the operational data for providing services to the one or more UEs, and if the operational data required to provide services to the one or more UEs may be unavailable in the local CN UP cache, the RAN node may be configured to retrieve the unavailable operational data from a master RAN node having a fully updated database of the operational data and store the operational data in the local CN CP cache.

[0019] In some embodiments, when the RAN node is a master RAN node, the RAN node has a database of fully updated operational data, and the RAN node may be configured to receive operational data requests from one or more assisting RAN nodes to retrieve operational data associated with the one or more UEs, retrieve the requested operational data from the database of fully updated operational data, and transmit the requested operational data in an operational data response to the one or more assisting RAN nodes.

[0020] In some embodiments, the RAN node may be configured by the Uu stack to transmit operational data requests to a master RAN node using directional radio beams.

[0021] In some embodiments, the RAN-to-RAN interface of the RAN node and the RAN-to-RAN interface of the other RAN node exchange operational data requests and operational data responses via a Radio Resource Control (RRC) protocol.

[0022] In some embodiments, the RAN node may further comprise a transport configured to enable movement of the RAN node from a first geographic location to a second geographic location, and the local CN may be configured to move the RAN node from the first geographic location to the second geographic location when the RAN node is in the first geographic location and requires the operational data available to other RAN nodes in the second geographic location.

[0023] In some embodiments, the RAN node may comprise a management plane including a Local Dynamic Map (LDM) configured to store any topographical, location, and status data associated with a geographic region, and a management interface for transmitting and receiving data from the LDM, wherein the management plane may be configured to determine the availability of other RAN nodes. In some embodiments, the management plane may be configured to use data stored in the LDM to determine whether a master RAN node is within a predetermined threshold distance from the RAN node.

[0024] In some embodiments, the RAN node may include a CN interface (I / F) configured to be operatively connected to and communicate with the CN when the RAN node is connected to the CN, and the RAN node may be configured to receive and transmit the operational data from the CN.

[0025] In some embodiments, the RAN node may be configured to: use the CN interface to send to the CN a set of update signals including operational data associated with the one or more UEs, which may include a UE context associated with each of the one or more UEs; upon successful authentication by the CN, receive from the CN a set of validation signals including a set of verified UEs of the one or more UEs; establish a session with each UE of the set of verified UEs; and exchange operational data associated with the set of verified UEs with the CN.

[0026] In yet another aspect, a Security Edge Protection Proxy (SEPP) system may include one or more RAN nodes, each having one or more processors; and a memory operatively coupled to the one or more processors, the memory including one or more processor-executable instructions that, when executed, cause the one or more processors to authenticate identities of other RAN nodes with which communication may be sought, and, if authentication is successful, establish a communication channel between the RAN node and the other RAN node.

[0027] In some embodiments, the communication channel may be one of an Xn interface or an Integrated Access Backhaul (IAB) interface.

[0028] In another aspect, a method of communication between one or more Radio Access Network (RAN) nodes includes: determining, by a RAN node, a first geographic location corresponding to a master RAN node; transmitting, by the RAN node, a set of request signals to the master RAN node to obtain operational data necessary to provide services to one or more user equipments (UEs); receiving, by the RAN node, a set of response signals from the master RAN node including the operational data; and processing, by the RAN node, the operational data to provide one or more services to the one or more UEs.

[0029] In yet another aspect, a method for exchanging operational data between a Core Network (CN) and a Radio Access Network (RAN) node includes: determining, by the RAN node, whether the RAN node is connected to a CN; transmitting, by the RAN node, a set of update signals to the CN including operational data associated with one or more user equipments (UEs), which may include UE context associated with each of the UEs; receiving, by the RAN node, a set of validation signals from the CN having a set of verified UEs of the one or more UEs that have been successfully authenticated by the CN; establishing, by the RAN node, a session with each UE of the set of verified UEs; and exchanging, by the RAN node, operational data associated with the set of verified UEs with the CN.

[0030] In another aspect, the present disclosure relates to a non-transitory computer-readable medium comprising processor-executable instructions for causing the steps of the methods disclosed herein to be performed.

[0031] Various objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description of preferred embodiments, as well as from the accompanying drawings. [Brief explanation of the drawings]

[0032] The accompanying drawings, which are incorporated herein and constitute a part of this disclosure, illustrate exemplary embodiments of the methods and systems disclosed herein. In the drawings, the same reference numbers refer to the same parts throughout the different drawings. The components in the drawings are not necessarily drawn to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings use block diagrams to illustrate components and may not show the internal circuitry of each component. Those skilled in the art will understand that the disclosure of such drawings includes disclosure of electrical or electronic components or circuits commonly used to implement such components. [Figure 1A] FIG. 1 illustrates an exemplary existing 5G network architecture (100) according to one embodiment of the present disclosure. [Figure 1B] FIG. 1 illustrates an exemplary network architecture scenario according to one embodiment of the present disclosure. [Figure 1C] FIG. 1 illustrates an exemplary network architecture scenario according to one embodiment of the present disclosure. [Figure 1D] FIG. 1 illustrates an exemplary network architecture scenario according to one embodiment of the present disclosure. [Figure 2] 2 illustrates an example scenario (200) involving a mobile RAN and UE, such as a UAV, and a fixed RAN node, such as a next generation base station (NgNB), in accordance with one embodiment of the present disclosure. [Figure 3] FIG. 3 illustrates an exemplary communication (300) from a RAN node indicating connected or coreless mode, according to one embodiment of the present disclosure. [Figure 4] FIG. 4 illustrates an exemplary communication (400) from a UE (104) and associated mechanisms for querying a RAN node when the UE (104) is in coreless mode or connected mode, according to one embodiment of the present disclosure. [Figure 5]FIG. 5 illustrates an example mechanism (500) for an independent RAN node to serve a UE (104) independent of the CN, according to one embodiment of the present disclosure. [Figure 6] FIG. 6 illustrates an exemplary independent node architecture (600) according to one embodiment of the present disclosure. [Figure 7] 7 illustrates an example scenario (700) of a mobile RAN node, such as a UAV (702), at various geographic locations and various time instances, in accordance with one embodiment of the present disclosure. [Figure 8] FIG. 8 illustrates an example scenario (800) of a master RAN node and two assist RAN nodes serving different geographic locations at the same time, according to one embodiment of the present disclosure. [Figure 9] A diagram illustrating an example scenario (900) for exchanging control information between a master UAV and an assist UAV over an extended Xn interface / RAN inter-node interface, according to one embodiment of the present disclosure. [Figure 10] A diagram showing another scenario (1000) of exchanging control information between a master UAV and an assist UAV via an extended Xn interface / RAN inter-node interface according to one embodiment of the present disclosure. [Figure 11] A diagram illustrating an exemplary scenario (1100) in which an assist UAV moves towards the coverage of a master UAV due to a lack of operational data to serve some users, according to one embodiment of the present disclosure. [Figure 12A] A diagram illustrating a set of steps (1200) performed by a master UAV and an assist UAV as the assist UAV moves toward the geographic location coverage of the master UAV, according to one embodiment of the present disclosure. [Figure 12B] 12 illustrates a scenario (1220) in which an assist UAV decides to connect with a master UAV, according to one embodiment of the present disclosure. [Figure 12C]12 illustrates a scenario (1220) in which an assist UAV decides to connect with a master UAV, according to one embodiment of the present disclosure. [Figure 12D] FIG. 12 illustrates an example flight schedule (1240) set for all master and assist UAVs at a particular geographic location, according to one embodiment of the present disclosure. [Figure 13] FIG. 13 illustrates an example method 1300 for providing network coverage and network services by a RAN node, such as an assisting UAV, to a requested geographic location, according to one embodiment of the present disclosure. [Figure 14] FIG. 14 illustrates a signal flow diagram (1400) including exemplary communications between various modules / components of a master UAV and an assist UAV for obtaining a subscription, according to one embodiment of the present disclosure. [Figure 15] 15 illustrates a signal flow diagram (1500) for an exemplary docking procedure for a UAV or mobile RAN node to offload data to a core network or ISP when it becomes available, using additional new N32 / N9 messages, according to one embodiment of the present disclosure. [Figure 16A] A diagram illustrating exemplary use cases (1600, 1610, 1620, 1630, 1640, 1650) for implementing a RAN node-to-node interface between a master UAV and an assist UAV according to one embodiment of the present disclosure. [Figure 16B] A diagram illustrating exemplary use cases (1600, 1610, 1620, 1630, 1640, 1650) for implementing a RAN node-to-node interface between a master UAV and an assist UAV according to one embodiment of the present disclosure. [Figure 16C] A diagram illustrating exemplary use cases (1600, 1610, 1620, 1630, 1640, 1650) for implementing a RAN node-to-node interface between a master UAV and an assist UAV according to one embodiment of the present disclosure. [Figure 16D]A diagram illustrating exemplary use cases (1600, 1610, 1620, 1630, 1640, 1650) for implementing a RAN node-to-node interface between a master UAV and an assist UAV according to one embodiment of the present disclosure. [Figure 16E] A diagram illustrating exemplary use cases (1600, 1610, 1620, 1630, 1640, 1650) for implementing a RAN node-to-node interface between a master UAV and an assist UAV according to one embodiment of the present disclosure. [Figure 16F] A diagram illustrating exemplary use cases (1600, 1610, 1620, 1630, 1640, 1650) for implementing a RAN node-to-node interface between a master UAV and an assist UAV according to one embodiment of the present disclosure. [Figure 17] FIG. 17 illustrates a method (1700) for establishing a RAN node-to-node interface between an assist UAV and a master UAV according to one embodiment of the present disclosure. [Figure 18] FIG. 18 illustrates an exemplary representation of a proposed system (1800) for providing a 6G coreless architecture, according to one embodiment of the present disclosure. [Figure 19] FIG. 19 illustrates a typical computing system (1900) according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0033] The above description will become more apparent from a more detailed description of the present disclosure.

[0034] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. However, it will be apparent that embodiments of the present disclosure may be practiced without these specific details. Some of the features described below can be used independently of each other or in any combination with other features. Individual features may not address all of the problems described above, or may only address some of the problems described above. Some of the problems described above may not be completely addressed by any of the features described herein.

[0035] The following description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments will provide those skilled in the art with an effective description for implementing the exemplary embodiments. It will be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as described.

[0036] In the following description, specific details are provided to provide a thorough understanding of the embodiments. However, it will be understood by those 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 so as not to obscure the embodiments in unnecessary detail. In other examples, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail so as not to obscure the embodiments.

[0037] Also, it should be noted that particular 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. While a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. 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 corresponds to the function returning to the calling function or to the main function.

[0038] The words "exemplary" and / or "demonstrative" are 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. Additionally, 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 exclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms "including," "having," "containing," and other similar terms are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the open transitional term "comprising," without excluding additional or other elements.

[0039] Throughout this specification, references to "one embodiment" or "embodiment" or "example" or "example" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment" in various places throughout this specification do not necessarily all refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0040] 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 unless the context indicates otherwise. It will be further understood that as used herein, the terms "comprises" and / or "comprising" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude 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.

[0041] Fifth-generation (5G) network architectures include tightly coupled radio access network (RAN) nodes and core network functions. One objective of this disclosure is to decouple RAN nodes from the core network, thereby eliminating dependency on the core network for network operations / functions such as device authentication / authorization, among other network operations / functions. Such an implementation can support coreless RAN functions that can better support mobile access systems such as UAV-based RANs and can be used as a fundamental building block in 6G network architectures.

[0042] The foundation of the 5G Core architecture is specified in 3GPP Release 15. 5G Core is implemented as a complete service-based architecture (SBA) with a new service-based interface (SBI), thus decoupling service consumers from service producers. A service-based architecture provides a modular framework within which common applications can be deployed using components from various sources and suppliers. For example, 3GPP defines a service-based architecture (SBA) in which the control plane functions and common data repository of the 5G network are provided by a set of interconnected network functions (NFs) with privileged access to each other's services. Furthermore, 5G Core supports many new features, including but not limited to improved session management, which enables session and service continuity with a "make before break" option, essential for ultra-reliable low latency communication (URLLC) use cases. Other features include a flow-based QoS framework that ensures quality of service (QoS) at the application level, and flexible end-to-end seamless network slicing across the RAN, core network, and transport network, allowing user equipment (UE) to access multiple slices simultaneously.

[0043] Furthermore, as shown in Figure 1, the existing 5G network architecture (100) includes a UE (104), a Next Generation Node Base station (NgNB) (102), and a core network with a core Access and Mobility Management Function (AMF) (106) that is responsible for RAN control plane interface termination, non-access stratum (NAS) ciphering and integrity protection, mobility management, and access authentication and authorization, and serves as a Security Anchor Function (SEAF) among other network functions. The AMF (106) interacts with a Unified Data Management (UDM) (118) and the UE (104) as part of the UE authentication process. The AMF (106) is also responsible for Security Context Management (SCM).

[0044] The existing network architecture (100) further includes a Session Management Control Function (SMF) (108) that manages the selection and control of sessions, UE Internet Protocol (IP) address allocation and management (including optional authorization), a User Plane Function (UPF) (110), and the termination of the interface to the Policy Control and Charging Function, which enables the policy enforcement and QoS control portion. The Charging Function also handles roaming functionality, local enforcement for applying QoS SLAs (such as Visited Public Land Mobile Network (VPLMN)), and handling charging data collection and charging interface (VPLMN).

[0045] Additionally, the network architecture (100) includes a core network UPF (110) that performs functions including QoS handling, packet routing and forwarding, packet inspection, policy rule enforcement, and traffic accounting and reporting, and (where applicable) serves as an anchor point for Radio Access Technology (RAT) mobility.

[0046] The network architecture (100) further includes an Application Function (AF) (112) that provides application services to subscribers / users. The network architecture (100) further includes a Data Network (DN) (114) that handles operator services, Internet access, or other services. The network architecture (100) further includes a Policy Control Function (PCF) (116) that provides support for a unified policy framework for controlling network operations. The network architecture (100) further includes a UDM (Unified Device Manager) (118) that supports an Authentication Credential Repository and Processing Function (ARPF). This function stores long-term security credentials used for authentication in the Authentication and Key Agreement (AKA) protocol and assists in storing subscription information. The network architecture (100) also includes an Authentication Server Function (AuSF) (120) that handles authentication with the UE (104).

[0047] Thus, one of the key requirements for 6G network architecture is the support of a coreless network that can assist access via mobile nodes (e.g., UAVs as base stations), i.e., RAN nodes must operate independently of the core network. This disclosure proposes a 6G RAN architecture that can function without relying on the core network. This disclosure provides scenarios in which one or more mobile RANs can operate independently of the core network, and in some scenarios, the mobile RANs can occasionally connect to the core network for other operations, such as offloading connected data.

[0048] In some embodiments, the UE (104) may also know which procedure to use depending on whether the RAN node is connected to a core network. In some embodiments, the present disclosure supports a mechanism by which the RAN node may indicate a lack of core support, or by which the UE (104) may be configured to query the RAN node to learn whether a core network is available.

[0049] 6G networks are expected to offer new radio and access architectures for both communications and sensing purposes, AI-optimized wide area networks (WANs) and data centers co-designed, and dynamic orchestration of personalized services to transform the long tail of niche consumer interests. While demand for mobile broadband will continue to grow among both consumers and businesses, the growing demand for ultra-reliable, low-latency services will be driven primarily by specialized and local use cases in conjunction with private networks, often involving augmented intelligence. This growth will occur as an integral part of automated and secure network transformation. In some embodiments, objects ranging from automobiles, industrial machinery, and home appliances to watches and apparel may learn and self-organize to meet our needs by automatically adapting to our behaviors, environments, and business processes. Energy efficiency is another key design criterion in the design of 6G network architectures, as network performance depends on the energy available in each architectural domain.

[0050] One of the most challenging requirements for 6G network architecture relates to remote control in conjunction with augmented reality (AR) and immersive media experiences. Solutions to these requirements will demand ultrafast speeds—for example, 100 Gbit / s or more—enabling uncompressed transmission of high-quality 360-degree video, in addition to extreme URLLC performance requirements. This will require a degree of flexibility and specialization beyond the capabilities of existing 5G networks. Therefore, 6G networks must be "intent" and "open service" driven, meaning that business needs will drive the delivery of future 6G products and services. Product and service creation will be an integral part of automated exchange-to-exchange (E2E) service workflows, directed and guided by policy and intent. In other words, a use-case-driven network is a network configured to cater to the diverse needs and preferences of each user or specialized 6G subnetwork, whether it be a human, a physical machine, or a digital twin. 6G networks also propose the use of mobile RAN nodes that can be easily and dynamically deployed regardless of the geography or topography of a particular area, for example, in high-density cities where it is difficult to install base stations, in remote areas where it is difficult to procure resources for building base stations, and for dynamic allocation of radio resources based on network traffic / demand at events / concerts, etc. In summary, key requirements for 6G network architecture may include (a) network programmability, (b) deployment flexibility, (c) simplicity and efficiency, (d) security, robustness, and reliability, and (e) automation.

[0051] The present disclosure also addresses the challenge of decoupling the RAN access node from the core network so that authentication / authorization of the UE (104), among other network operations / services provided to the UE (104), can be independent of the core network. The objective of the present disclosure is to better support UE (104)-based radio access operations and to support coreless RAN functionality that can be used as a fundamental building block in 6G network architectures.

[0052] The present disclosure addresses the above-mentioned challenges by providing a coreless RAN network having one or more operational RAN nodes that can be mobile or fixed. In embodiments where the RAN nodes are mobile, the RAN nodes may be implemented in devices including, but not limited to, UAVs, vehicles (cars, buses, trains / public transportation, ships), satellites, etc. In other embodiments, where the coreless RAN is fixed, the RAN may refer to local / traditional base stations that are disconnected from the core network but can intermittently communicate with the core network. Various embodiments throughout this disclosure are described in more detail with reference to Figures 2-19.

[0053] 1B, 1C, and 1D illustrate exemplary network architecture scenarios according to one embodiment of the present disclosure. For example, FIG. 1B illustrates a scenario (122) depicting a docking station for connecting a RAN node and a core network. The radio domain / RAN node may include a local core network (CN) further including a LDM, which further includes one or more network functions / entities, including, but not limited to, an AMF (106), an SMF (108), a UPF (110), an AF (112), a PCF (116), and an AuSF (120). The local CN may further include a gNB / RAN node (102) configured to enable wireless communication with one or more UEs (104). The local CN may communicate with the UEs (104) and may be configured to perform network functions / operations and provide services to the UEs (104). In the embodiment illustrated in FIG. 1B, the local CN may be connected to a central CN, which communicates with a data network (114). In one embodiment, the central CN may include a set of corresponding network functions / entities, such as the AMF (106), SMF (108), UPF (110), AF (112), PCF (116), UDM (118), and AuSF (120). It will be appreciated that the core network functions are split between the local CN and the central CN. In one embodiment, when a RAN node (e.g., a UAV) is in a docking station or in a "docked mode" / "connected mode," the RAN node does not have any network function blocks and may be in communication with a central CN that implements all network function blocks (e.g., the AMF (106), the SMF (108), the UPF (110), the AF (112), the PCF (116), the UDM (118), and the AuSF (120)), as shown in FIG. 1C. In the "flight mode" / "coreless mode" when the UAV is not in a docking station, the RAN node is implemented in the local CN (and its network entities) as shown in Figure 1D and provides core network functions to the UE (104).

[0054] Figure 2 illustrates an example scenario 200 involving a mobile RAN and UE (104), such as a UAV, and a fixed RAN node, such as a next-generation base station (NgNB), in accordance with one embodiment of the present disclosure. As illustrated in Figure 2, one or more computing devices (104-1, 104-2, 104-3, 104-4), referred to herein as computing device (104), may communicate with a first UAV (202-1). Similarly, computing devices (104-5 and 104-6) may communicate with a second UAV (202-2). Those skilled in the art will appreciate that the first and second UAVs (202-1, 202-2) are illustrative examples of mobile RAN nodes, and that the UAVs may be appropriately replaced with other mobile RAN nodes based on requirements without losing their functionality. The computing device (104) may include, but is not limited to, a mobile phone, a smartphone, a virtual reality (VR) device, an augmented reality (AR) device, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, etc. Additionally, the computing device (104) may include one or more built-in or externally connected accessories, including, but not limited to, a camera, an audio assistant, a microphone, or a visual assistant device such as a keyboard. An input device for accepting input from a user, such as a touchpad, a touch-enabled screen, or an electronic pen, may also be used. It should be understood that the terms "computing device" and "user equipment (UE)" may be used interchangeably throughout this disclosure. While several UEs or computing devices are shown in FIG. 2, it should be understood that any number of UEs may be implemented without departing from the scope of this disclosure.

[0055] As shown in FIG. 2, a first UAV (202-1) may communicate with a first gNB (102-1) and a second gNB (102-2) (hereinafter also referred to as NgNB, gNB, or fixed RAN node). The second UAV (202-2) may communicate with a second gNB (102-2). The UAVs (202-1, 202-2) may be collectively referred to as UAVs (202), and the gNBs (102-1, 102-2) may be collectively referred to as gNBs (102). The UE (104) may establish a connection with the UAV (202) or the gNB (102) via a network (not shown). The UAV (202) may be configured to support high-speed data rates and low-speed data rates for the UE (104) using a backhaul link with the gNB (102). As shown, each of the UAVs (202-1, 202-2) may provide network services for coverage of different geographic locations. One or more gNBs (102) may be connected to the same UAV (e.g., 202-1) to provide a backhaul link therebetween.

[0056] In some embodiments, the UAV (202) and the gNB (102) may be radio access technologies (RATs) configured to provide telecommunication services to the UE (104). In some embodiments, the UAV (202) and the gNB (102) may be configured to receive and transmit wireless signals to and from the UE (104) to provide the services to the UE (104). The UAV (202) and the gNB (102) may include a transmitter configured to transmit wireless signals to the UE (104), a receiver configured to receive wireless signals from the UE (104), and a controller / processor configured to control the transmitter and receiver and process operational data exchanged in the wireless signals to provide network services to the UE (104). The controller may also include an interface for connection to a (central) CN. The controller may be configured to coordinate the operation of each component of the UAV (202) and the gNB (102) to, for example, provide telecommunication services to the UE (104). In some embodiments, the UAV (202) and the gNB (102) may include components that enable them to perform operations specific to their implementation. In some examples, the UAV (202) may include wings or propellers that enable the UAV (202) to fly. The controller may include one or more processors and a memory. The memory may include one or more processor-executable instructions that are executed by the one or more processors to orchestrate the components of the RAN node.

[0057] In some embodiments, both the UAV (202) and the gNB (102) may represent RAN nodes forming a coreless RAN network. A RAN node may represent a RAT that may be configured to operate and provide telecommunications services, particularly to UEs (104), without being connected to a CN. In some embodiments, a RAN node may be configured to intermittently connect to a CN based on requirements. A coreless RAN node may intermittently connect to a CN for purposes such as, but not limited to, offloading operational data, updating operational data in the CN after service provision, maintenance, or upgrades, sourcing data unavailable at the RAN node, providing services that require a connection to the CN, etc. A RAN node may be in a "coreless mode" when not connected to a CN, and a "connected mode" when connected to a CN. In some embodiments, a UAV (202) may be in a "flight mode" (FM) when not connected to a CN in a coreless mode, and may be in a "docked mode" when connected to a CN in a coreless mode, based on implementation.

[0058] The UAV (202) may represent an example of a mobile RAN node. In other examples, the mobile RAN node may be implemented in any moving vehicle, including, but not limited to, a car, a train, an aircraft, a balloon, a drone, a satellite, an autonomous land vehicle, or an autonomous water vehicle. In some applications, the mobile RAN node may represent a public transportation vehicle that moves from one location to another while providing network connectivity to the UE (104). The gNB (102) may represent a fixed RAN node. The gNB (102) may represent a fixed RAN node that may be intermittently connected to a CN but can also operate without being connected to a CN. Unlike a mobile RAN node, a fixed RAN node may be permanently or temporarily fixed to a predetermined location.

[0059] In some embodiments, the UAVs (202) and gNBs (102) may be configured to intermittently connect and communicate with the CN based on requirements. In other embodiments, the UAVs (202) and gNBs (102) may be configured to operate in a distributed manner without requiring a connection with the CN. In such embodiments, the UAVs (202) and gNBs (102) may be configured to exchange operational data with each other to provide services to the UEs (104) without requiring communication with a (central) CN. Hereinafter, the UAVs (202) and gNBs (102) may be collectively referred to as RAN nodes.

[0060] In some embodiments, a RAN node may be configured to announce whether it is connected to a CN. In some embodiments, a UE (104) may be configured to determine whether a RAN node is connected to a CN. The UE (104) may connect to the RAN node and select an appropriate communication protocol based on whether the RAN node is connected to a CN. The communication protocol and data flow between the UE (104) and the UAV (202) / gNB (102) may be adapted accordingly based on whether the RAN node is connected to a CN. Means for determining whether a RAN node is connected to a CN are described with reference to Figures 3 and 4.

[0061] In some embodiments, the RAN node may be configured to broadcast / periodically transmit a set of dedicated signals indicating connection with the CN. Figure 3 illustrates an exemplary communication (300) from a RAN node indicating connected or coreless mode, according to one embodiment of the present disclosure. In one embodiment, the RAN node may be configured to obtain (302) connection schedule data indicating a schedule for the RAN node to connect to the CN. In such an embodiment, the connection schedule data may include details such as, but not limited to, when the RAN node is configured to connect to the CN (i.e., the times and durations the RAN node is in either core mode or coreless mode), backhaul support, accepted communication protocols, and identifier attributes. In an example where the RAN node indicates a UAV (202), the schedule data may include the length of time the UAV (202) is in FM / Coreless mode and the length of time the UAV (202) is connected to the CN. By way of example, the connection schedule data is shown in and described with reference to Figure 12D.

[0062] In some embodiments, the RAN node may broadcast (304) connection schedule data to one or more UEs (104) through a set of dedicated signals. By broadcasting the connection schedule data, the RAN node may indicate to UEs (104) communicating with it whether the RAN node is operating in connected mode or coreless mode. Whether the RAN node is connected to a CN may be inferred from the connection schedule data. In some embodiments, the RAN node may be configured to broadcast the set of dedicated signals periodically. The periodicity may be predetermined and optimized to minimize energy consumption while providing continuous telecommunications services. In other embodiments, the set of dedicated signals may include an explicit indication of whether the RAN node is in connected mode or coreless mode.

[0063] In some embodiments, the set of dedicated signals may be transmitted via either a System Information Block (SIB) or a Master Information Block (MIB). In some embodiments, the RAN node may allocate one or more blocks in the SIB or MIB to indicate that the RAN node may be connected to the CN during a specified interval. In other embodiments, the SIB or MIB may be configured to include connection schedule data. The receiving UE (104) may be configured to connect (306) to the RAN node based on the SIB message. In some embodiments, the UE (104) may determine whether a service requested by the UE (104) can be fulfilled by the RAN node based on whether it is connected to the CN.

[0064] In some embodiments, the set of dedicated signals may be transmitted using a Radio Resource Control (RRC) protocol. In one example, the RAN node may request the UE (104) to switch to a security authentication mechanism using one or more RRC-based messages when the RAN (102) is in a coalesce mode. The SIB or MIB may be transmitted to the UE (104) via the RRC-based messages. In some embodiments, the UE (104) may be configured to inquire about whether the RAN node is operating in a coalesce mode or a connected mode via one or more RRC Layer 2 messages. The Layer 2 messages may be signals transmitted via a data link Layer 2 protocol.

[0065] 4 illustrates an exemplary communication (400) from a UE (104) and an associated mechanism for querying a RAN node if the UE (104) is in a coreless mode or a connected mode, according to one embodiment of the present disclosure. Accordingly, the present disclosure provides a mechanism for the UE (104) to query a RAN node as to whether the RAN node is in a coreless mode or a connected mode. In some embodiments, the UE (104) may query a RAN node to ascertain whether the RAN node is in a coreless mode or is about to enter a coreless mode by transmitting a set of request messages. As an example, the UE (104) may transmit a set of request signals to a UAV (202) to inquire whether it is in an FM mode. In some embodiments, the set of request signals may indicate RRC messages (402), (404), and (406). In response, the RAN node may retrieve connection schedule data from a database and transmit dedicated signals, such as RRC messages (408), (410), and (412).

[0066] In some examples, the UE (104) may query the request by setting the flag "FM request" to "1" in any one of the RRC SETUP REQUEST (402), RRC REESTABLISHMENT REQUEST (404), or RRC RESUME REQUEST (406) messages, but is not limited to this. The RAN node may obtain connection schedule data and respond to the query by including, but not limited to, the connection schedule(s), duration of the connection, details of supported backhaul, etc. in any one of the RRC SETUP (408), RRC REESTABLISHMENT (410), or RRC RESUME (412) messages.

[0067] In some embodiments, the UE (104) may be configured to receive a set of dedicated signals having connection schedule data from a RAN node and may use this information to freely utilize scenarios or to switch to a different RAN node based on a specified connection duration. The set of dedicated signals may be received by the RAN node broadcasting these signals or in response to a set of request signals transmitted by the UE (104). The UE (104) may establish a connection with the RAN node based on the connection data included in the set of dedicated signals. In some embodiments, the UE (104) may use the connection schedule data to determine whether the RAN node is connected to the CN and whether a service requested by the UE (104) can be provided by the RAN node.

[0068] In one example, if the UE (104) requires a telecommunication service provided only by the CN, the UE (104) may switch to another RAN node connected to the CN upon receiving the dedicated signal. In another example, if the service required by the UE (104) can be provided by the RAN node, the UE (104) may establish a connection with the RAN node. In such an example, the UE (104) may be configured to select a communication protocol for communicating with the RAN node based on whether the RAN node is connected to the CN. Existing notification mechanisms may be reused to indicate updated information, if any.

[0069] When the UE (104) connects to a RAN node, the RAN node may be configured to provide services to the UE (104), regardless of whether the RAN node is connected to a CN. Services include, but are not limited to, telecommunications services such as voice calls, messaging, and video conferencing, Internet connectivity, file transfer, and data exchange services. In some embodiments, the RAN node may be configured to independently provide services to the UE (104) without requiring a connection to a CN. In such embodiments, the RAN node may include a network entity that enables it to internally store and process operational data to provide services to the UE (104). In other embodiments, the RAN node may be configured to intermittently communicate with the CN or with other RAN nodes to provide services to the UE (104). The RAN node may require interaction with the CN or other RAN nodes to perform services / operations, such as, but not limited to, authorization / authentication, call handover, etc. Furthermore, in such embodiments, the RAN node may be configured to obtain operational data necessary to provide services requested by the UE (104). In some examples, a RAN node may require operational data, such as subscriber data, associated with a UE (104) to determine services and policies applicable to the UE (104) requesting service. If the operational data required to provide service to the UE (104) is not available at the RAN node, the RAN node may request and obtain the operational data from another RAN node or the CN. However, if the operational data, and the corresponding services and policies applicable to the UE (104), are available, the RAN node may obtain the subscriber data and use it to provide service to the UE (104).

[0070] In some embodiments, operational data may include, but is not limited to, subscriber data, policy and enforcement data, authentication keys and security information, (encrypted) messages / data packets sent by the UE (104), etc. Throughout this disclosure, operational data may refer to any data exchanged between a RAN node and the UE (104), other RAN nodes, and intermittently (a central) CN to provide service to the UE (104). While in some examples operational data is described in the context of subscriber data, those skilled in the art will understand that operational data is not limited thereto.

[0071] FIG. 5 illustrates an example mechanism 500 for an independent RAN node that provides services to a UE 104 independently of a CN, according to one embodiment of the present disclosure. The present disclosure proposes a new definition of a RAN node / independent RAN nodes 504-1, 504-2 (hereinafter collectively referred to as an independent node 504) as shown in FIG. 5. An independent node 504 may include one or more network entities that may support / provide multiple network operations / services independently of a CN. Hereinafter, the terms independent node 504 and RAN node may be used interchangeably. In some examples, an independent node may be configured to perform local authentication / authorization of a UE 104 (e.g., device 502-1, 502-2) independently of a CN, among other services.

[0072] In some embodiments, a RAN node (e.g., independent nodes 504-1, 504-2, etc.) may be a standalone entity that does not need to interface with a CN to provide services to a UE (104). Such a RAN node may be configured to communicate with the UE (104) using common wireless-related protocols. In some embodiments, such a RAN node may also support an Internet Service Provider (ISP) interface for providing services from the Internet. In some embodiments, the independent nodes (504-1, 504-2) may include a CN interface for when such a CN becomes available. Data required to perform a particular network service / operation may be stored in the independent nodes (504-1, 504-2) and offloaded to, but not limited to, an appropriate application server, database, DN (114), or CN. In one embodiment, the independent node (504-1) may support a RAN-to-RAN interface for connecting to other independent nodes (504-2). The independent nodes (504-1, 504-2) may support a management plane, as described below with reference to FIG.

[0073] In one example embodiment, the independent nodes (504-1, 504-2) may be implemented in a mobile RAN node, such as a UAV (202), that may provide the functionality / services provided by a traditional RAN. In some embodiments, the mobile RAN node (e.g., UAV (202)) may be configured to provide network coverage and network services to multiple UEs (104) in a given geographic location. In some embodiments, the mobile RAN node may be configured to move from one geographic location to another. While the independent nodes (504-1, 504-2) are preferably implemented as mobile RAN nodes, those skilled in the art will understand that the independent nodes (504-1, 504-2) may also be implemented in fixed RAN nodes as appropriate.

[0074] In such embodiments, the RAN nodes may be configured to provide services to the UEs (104) in a distributed manner. By coordinating with each other in this manner, the RAN nodes may be configured to exchange operational data with each other based on the requirements of the service requested by the UEs (104). In such embodiments, operational data necessary to provide the service, such as subscriber data necessary to uniquely identify the UEs (104) and obtain applicable policies, may be distributed across each RAN node. In some embodiments, the RAN nodes may maintain a partial set of operational data in their respective databases and interact with each other to obtain operational data necessary to provide the service to the UEs (104) that is not available at the RAN node. In some examples, the RAN nodes may be configured to store and maintain operational data typically associated with UEs (104) that utilize service from a geographic location designated for the RAN node. In such examples, the RAN node may be configured to communicate with other RAN nodes to obtain operational data when operational data for a UE newly entering a designated geographic location is unavailable. Distributing operational data across multiple RAN nodes may reduce the resources and costs required to manufacture and deploy the RAN nodes. The low controllability of RAN nodes also allows them to function without requiring constant connectivity with the CN, thereby allowing RAN nodes to be mobile and decentralized.

[0075] In some embodiments, a fleet of mobile RAN nodes, such as a plurality of UAVs (702), may be deployed to corresponding geographic locations assigned to each of the UAVs (702), as shown in FIG. 7. The fleet of UAVs (702) may be configured to move between different geographic locations based on requirements. In some examples, the fleet of UAVs (702) may be programmed to move based on service demands. Furthermore, the mobility of the UAVs (702) allows the UAVs (702) to be rapidly deployed to different geographic locations based on demand / network traffic or other requirements, as described below with reference to FIGS. 7 and 8.

[0076] FIG. 6 illustrates an exemplary independent node architecture (600) according to one embodiment of the present disclosure. As shown in FIG. 6, the present disclosure provides a RAN node-to-RAN node communication mechanism by providing new network entities / modules in the independent node architecture (600). For example, when RAN nodes are independent of the CN, there may be situations where RAN nodes need to communicate with each other to assist with any operational data or call handover between a set of RAN nodes. In some embodiments, an independent node (504) may include a management plane (602) having a local dynamic map (LDM / AuSF) (604) that may be updated based on geographic locations provided by the independent node (504) and UEs (104) connected to the RAN node. In some embodiments, the LDM (604) may be a local database containing topography data, location data, and status data (collectively referred to as LDM data) of objects, including, but not limited to, mobile RAN nodes, fixed RAN nodes, pedestrians, obstacles, etc., within a geographic region / location. In some embodiments, the LDM (604) may be configured to maintain information about the object in real time. In some embodiments, the LDM (604) may enable the RAN nodes / independent nodes (504) to navigate and cooperate with each other. Mobile RAN nodes may be configured to move using any means of transportation, including, but not limited to, wheels, wings, floats, etc., propelled by engines, motors, propellants, etc.

[0077] In some embodiments, the management plane (602) may include an AUSF configured to verify the identity of a subscriber using the UE (104). In some embodiments, the LDM data may be reused to authenticate the UE (104) or to verify the identity of other independent nodes (504). In some embodiments, the management plane (602) may be configured to exchange LDM data via a management interface (I / F) (606).

[0078] In some embodiments, the independent node (504) may include a Layer 3 (L3) application (608), a Uu stack (610), and a radio frequency (RF) unit (612). In some embodiments, the L3 application (608) may include a Light Weight (LW)-AMF configured to perform network operations, including, but not limited to, UE (104) registration and authentication, encryption, security, interconnection between network entities, session management, mobility management, policy enforcement, etc. The LW-AMF may be configured to determine whether the independent node (504) is connected to a CN. The L3 application (608) may further include an LW-UPF that interfaces with a data network (DN), such as the Internet, and enables the exchange of data packets. The LW-AMF and LW-UPF may be adapted to be lightweight in terms of hardware and energy consumption, allowing mobile RAN nodes, such as UAVs (202), to operate while in motion or during FM.

[0079] The L3 application (608) may include a Radio Resource Management (RRM) entity configured to send and receive messages using RRC. The RRM entity may be configured to enable the exchange of messages with entities such as the UE (104), the CN, or other RAN nodes. In some embodiments, the L3 application (608) may further include a Self-Organizing Network (SON) configured to perform one or more of planning, configuration, management, optimization, and repair for the RAN node. In some embodiments, the L3 application (608) may include a Non-Access Stratum (NAS) entity configured to encrypt and decrypt data packets transmitted from the L3 application (608). The aforementioned entities enable the RAN node to securely receive, process, and perform network operations using operational data to provide services to the UE (104). In some embodiments, the L3 application may include a Security Edge Protection Proxy (SEPP). The functionality of the SEPP is described below with reference to Figures 9 and 10. In some embodiments, the L3 application (608) may represent a local CN control plane (CP) (902-1, 902-2) as shown in Figures 9 and 10. The L3 application (608) may be configured to perform the functions of the control plane of the (central) CN.

[0080] In some embodiments, the Uu stack (610) may be configured to control the RF unit (612) to communicate with the UE (104). The Uu stack (610) may refer to a radio interface or physical layer stack. In some embodiments, the Uu stack (610) may use a communication protocol and interface that allows data packets / signals to be exchanged between two entities configured to process such data packets / signals in different formats / channels / mediums. The Uu stack (610) may enable a RAN node to communicate with the UE (104) and may also enable communication with other RAN nodes and the (central) CN using corresponding interfaces. The Uu stack (610) may include a corresponding Uu I / F (614).

[0081] In some embodiments, the independent node (504) may include a core network interface (I / F) stack (616), a RAN-to-RAN node I / F stack (618), and a Layer 2 (L2) application (MAC scheduler) (620). In some embodiments, the core network (CN) I / F (622) may be configured to enable communication with the CN when connected to the CN. In examples where the independent node (504) is a mobile RAN node, such as a UAV (202), the CN I / F (622) may be configured to connect with the CN in a docked mode. In some embodiments, the CN I / F (622) may be configured with a local CN cache, which represents a cache / database that stores a copy (in whole or in part) of the CN. The local CN cache may store operational data to provide services to the UE (104), and the local CN cache allows the RAN node to utilize the operational data. In some embodiments, the RAN inter-node I / F (624) may be configured to enable communication with other RAN nodes / independent nodes (504). The RAN inter-node I / F (624) may enable two or more RAN nodes to exchange operational data necessary to provide service to the UE (104).

[0082] In some embodiments, the Uu I / F (614), the RAN inter-node I / F (624), and the CN I / F (622) may be either wired or wireless communication interfaces and may be configured to transmit data packets as a set of signals, including, but not limited to, signals in the form of electrical signals, digital signals, radio signals, analog signals, optical signals, etc. The RAN node / independent node (504) may be configured to obtain and / or offload operational data from the CN or other RAN nodes, respectively, using the CN I / F (622) or the RAN inter-node I / F (624) to provide services to the UE (104). In some embodiments, the Uu stack (610) may be coupled to the CN I / F (622) or the RAN inter-node I / F (624) and configured to control the flow of data packets / signals.

[0083] In some embodiments, the L2 application (620) may include a MAC scheduler configured to allocate radio resources to enable communication between the independent node (504) and other entities, such as the UE (104), other RAN nodes, and the CN. In some embodiments, the MAC scheduler may be configured to allocate time slots and frequency slots to other entities. The L2 application (620) may represent a local CN user plane (UP) (904-1, 904-2) as shown in FIGS. 9 and 10. The L2 application (620) may be configured to perform user plane functions of the CN. The L2 application (620) / local CN UP (904) and the L3 application (608) / local CN CP (902) may reside in the local CN of the RAN node. The local CN may be configured to provide the functionality of the central CN without requiring an active connection. As described above, the local CN may include one or more network entities corresponding to the network entities of the central CN, adapted to perform network operations / services.

[0084] 6 illustrates an independent node (504), specifically an L3 application (608) and an L2 application (620), having several network entities, although those skilled in the art will appreciate that the independent node (504) may include other entities not shown for clarity. Furthermore, each network entity may be implemented using any one or combination of devices, including, but not limited to, a processor, electrical circuitry, microcontroller, digital signal processor, etc., configured to execute one or more processor-executable instructions to perform a predetermined function.

[0085] The above-described components may enable an independent node (504) to exchange data with other independent nodes (504) or CNs and provide services to UEs (104). Figures 7 and 8 illustrate some example scenarios requiring independent nodes (504) to interact with each other.

[0086] 7 illustrates an example scenario 700 of a mobile RAN node, such as a UAV 702, at various time instances in various geographic locations, in accordance with one embodiment of the present disclosure. As shown, UAV-1 702 is configured to provide network coverage and network services to a first set of UEs (UE1, UE2, UEN) at geographic location 1 704-1 at time T1, to provide network coverage and network services to a second set of UEs (UEN1, UEN2, UEM) at geographic location 2 704-2 at time T2, and to provide network coverage and network services to a third set of UEs (UEM1, UEM2, UEP) at geographic location N 704-N at time T1. As described herein, UAV-1 702 may be scheduled / configured to fly to various locations and provide network coverage and network services at various times in various geographic locations. At each time T1, T2, ... TN, the flight of the UAV through geographic locations (704-1, 704-2, ... 704-N) may be determined based on the expected network traffic (i.e., the number of UEs (104) requesting service from the RAN node) at those geographic locations and time. In one example, geographic location 1 (704-1) may represent a residential area where network traffic may be high at time T1 (e.g., morning), geographic location 2 (704-2) may represent a workplace where network traffic may be high at time T2 (e.g., midday), and geographic location N (704-N) may represent an entertainment venue (e.g., a bar or restaurant) at time TN (e.g., evening). In an operational mode, the mobile RAN node or UAV-1 (702) may serve a set of users at geographic locations (704-1, 704-2, ... 704-N). In some embodiments, the user base may change as the geographic locations change.To support such situations and scenarios, multiple interconnected UAV-1 (702) / Mobile RAN nodes representing independent nodes (504) should have complete subscriber base information.

[0087] In some embodiments, multiple interconnected RAN nodes / independent nodes (504) may be configured to exchange information / operational data among themselves to provide services to UEs (104). In some embodiments, multiple RAN nodes (e.g., independent nodes (504)) may be configured to have a master-assistant paradigm. FIG. 8 illustrates an example scenario (800) of a master RAN node and two assist RAN nodes corresponding to different geographic locations at the same time, in accordance with one embodiment of the present disclosure. As shown, the RAN nodes may be implemented as UAVs (802-1, 802-2, ..., 802-N) (collectively referred to hereinafter as UAVs 802). In some embodiments, there may be one or more UAVs (802) operating in cooperation, where one UAV is the master UAV with a complete set of user subscription information (e.g., a fully loaded LDM) and the other assist UAVs are configured to connect to the master UAV for verification of the user subscription information. As described herein, different UAVs (master and assistant / slave) may connect to each other via the RAN inter-node I / F (624).

[0088] In some examples, the RAN inter-node I / F (624) may represent an extended Xn interface. Additionally, in other examples, the UAVs may be configured to connect via an IAB link (1232), as shown in FIG. 12C, or via any proprietary wireless link or satellite link, without limitation. While the exemplary scenario (800) is described in the context of a mobile RAN node, such as a UAV (802), configured to exchange subscriber information and / or LDMs (804-1, 804-2, ... 804-N), it will be understood by those skilled in the art that, using a master-assistant paradigm, the RAN nodes may be implemented as any mobile or fixed RAN nodes, and may be configured to exchange any operational data required to provide service to the UE (104).

[0089] As shown in Figure 8, the master UAV-1 (802-1) provides network coverage and network services to a set of UEs (UEN1, UEN2, UEM) at a second geographic location 2 (704-2) at time T0. The first assisting UAV-2 (802-2) provides network coverage and network services to a set of UEs (UE1, UE2, UEN) at a first geographic location 1 (704-1) at time T0. Similarly, the second assisting UAV-N (802-N) provides network coverage and network services to a set of UEs (UEM1, UEM2, UEP) at a third geographic location N (704-N) at time T0. The master UAV-1 (802-1), functioning as an independent node (504), may include a fully updated LDM (804-1). The first and second assist UAVs (802-2 and 802-N) may each include a partially updated LDM (804-2 and 804-N). Additionally, each of the UAVs (802-1, 802-2, 802-N) may communicate with each other using an Xn interface via an IAB link (1232) for the exchange of any information, such as subscriber data or any other operational data.

[0090] 9 and 10 illustrate exemplary scenarios (900) and (1000) for exchanging operational data between a master RAN node and an assisting RAN node via an extended Xn interface / inter-RAN node I / F (624) according to one embodiment of the present disclosure. In some embodiments, a new entity called a SEPP in the L3 application (608) is proposed to enable mobile RAN node-to-mobile RAN node communication in the disclosed independent node architecture (e.g., 600). In some embodiments, the SEPP is a non-transparent proxy and may support a set of functions, including but not limited to, message filtering and policy enforcement, using local CN CPs (902-1, 902-2). The SEPP may also be configured to protect the connection between RAN nodes from a security perspective by preventing overlapping service authorizations applied by the master or assisting UAVs (802-1 and 802-2) / RAN nodes. The SEPP may also hide the topology data of the RAN nodes for security reasons. In some embodiments, the SEPP may be implemented as a function between the RAN nodes (master UAV 802-1 and assist UAV 802-2). The SEPP may provide seamless secure inter-RAN node communication over the Xn interface / IAB link (1232). In some embodiments, the SEPP may authenticate the identities of other RAN nodes and may identify and mitigate any form of attack, including but not limited to denial of service attacks, with appropriate further action.

[0091] In one embodiment, the local CN CPs (902-1, 902-2) are connected by an Xn interface / inter-RAN node I / F (624), allowing operational data, such as user subscription information, to be exchanged between the mobile RAN nodes (i.e., the master UAV 802-1 and the assistive UAV 802-2). Note that no data exchange occurs between the RAN nodes. All operational data related to a UE (104) requesting service from a RAN node may be cached in that RAN node, as shown in Figures 9 and 10. In some embodiments, as shown in Figure 9, operational data, such as user subscription information / subscription data, may be exchanged between the local CN CPs (902-1, 902-2) of the master UAV (802-1) and the assistive UAV (802-2), respectively. In some embodiments, operational data may be exchanged between the local CN UPs (904-1, 904-2) of the master UAV (802-1) and its local CN UP caches (906-1, 906-2) and the local CN CPs (902-1, 902-2) of the assisting UAV (802-2). In some embodiments, as shown in FIG. 10, operational data may be exchanged between the local CN UP cache (906-1) and the RF unit of the assisting node (802-2). In some embodiments, the local CN CPs (902-1, 902-2) and local CN UPs (904-1, 904-2) of the master and assisting nodes (802-1, 802-2) may be defined over a newly extended Xn interface / IAB link (1232) to exchange operational data such as user subscription information and data information. In some embodiments, operational data may be exchanged over a new extended N9 interface or an N32 interface, as shown in FIG.

[0092] 11 illustrates an exemplary scenario (1100) in which an assisting UAV moves toward the coverage of a master UAV due to a lack of operational data for serving some users, in accordance with one embodiment of the present disclosure. As illustrated, master UAV-1 (1102-1) provides network coverage at a first geographic location 1 (1104-1) for a first set of UEs (i.e., UEN1, UEN2, and UEM), and assisting UAV-N (1102-N) provides network coverage for a second set of UEs (i.e., UEM1, UEM2, and UEP) at a second geographic location N (1104-N). In one embodiment, during step (1106) of a method for aligning toward the coverage of master UAV-1 performed by assisting UAV-N (1102-N), assisting UAV-N (1102-N) determines that the assisting UAV-N (1102-N) lacks operational data, such as user subscription data, for serving some UEs (or users of UEs) in the second set of UEs. In such embodiments, the assisting UAV-N (1102-N) may be configured to communicate with the master UAV-1 (1102-1) to obtain information regarding the master UAV-1's network coverage and the first geographic location (1104-1). In some embodiments, in response to an inquiry from the assisting UAV-N (1102-N), the master UAV-1 (1102-1) may transmit location details and network coverage information. In some embodiments, in step 1108, the assisting UAV-N (1102-N) may cease providing its service and move toward the master UAV-1's network coverage area or the first geographic location based on the received information.

[0093] 12A illustrates a set of steps (1200) performed by a master UAV and an assisting UAV as the assisting UAV moves toward the geographic location coverage of the master UAV, according to one embodiment of the present disclosure. As shown, the master UAV-1 (1202-1) may communicate with the assisting UAV-N (1202-N) via a Universal Mobile Telecommunications System (UMTS) radio interface or Uu I / F (614) and may provide network coverage to a first set of UEs at a first geographic location 1 (1204-1). In step 1206, the assisting UAV-N (1202-N) establishes an RRC connection with the master UAV-1 (1202-1). In some embodiments, in step 1208, the assisting UAV-N (1202-N) requests operational data, such as user subscription data, from the master UAV-1 (1202-1) using the established RRC connection. In some embodiments, in response to a query from the assisting UAV-N (1202-N), the master UAV-1 (1202-1) may transmit the requested information / operational data. In step 1210, the assisting UAV-N (1202-N) may obtain all operational data, such as user subscription data, necessary to provide service to the UE (104) from the master UAV-1 (1202-1). In step 1212, the assisting UAV-N (1202-N) may disconnect the RRC connection established in step 1206 and, in step 1214, begin moving toward its original geographic location N (1204-N), as shown in FIG. 12A. The flight from the current location to geographic location N (1204-N) is shown as (1216) in FIG. 12A.

[0094] 12B and 12C illustrate scenarios (1220, 1230) in which an assisting UAV determines to connect with a master UAV in accordance with one embodiment of the present disclosure. To provide service to a UE (104), operational data associated with the UE (104) may be required. Therefore, an assisting UAV that receives a service request from the UE (104) may determine whether the operational data is available within a network entity, such as a local CN UP cache (906) or an LDM (604). If the operational data is not available within the UAV, it may be required to obtain the operational data from another UAV, such as the master UAV. In some embodiments, if the assisting UAV determines in step (1106) that it needs to obtain operational data from the master UAV, the assisting UAV may sniff or determine whether a master UAV is present within its geographic location. Once the assisting UAV learns / determines the availability of a master UAV near its geographic location in step 1205, the assisting UAV may, in step 1218, emit / transmit a directional radio beam 1222 toward the master UAV requesting operational data. In such embodiments, the master UAV may, in step 1217, be configured to establish a connection between the assisting UAV's RAN inter-node I / F and the master UAV for the transmission of the radio beam 1222. In some embodiments, the RAN inter-node radio interface may correspond to the X2 / Xn / IAB interface 1232, as shown in scenario 1230 of FIG. 12C. In some embodiments, the assisting UAV may broadcast its Internet Protocol (IP) address and a flag indicating the need for operational data in the radio beam 1222.

[0095] In some embodiments, a RAN node, such as the illustrated UAV, may be configured to either move or transmit based on the geographic location of the master RAN node, as shown in Figures 11 and 12. In some embodiments, the (assisting) RAN node may transmit a radio beam (1222) if the master RAN node is within a threshold distance from the (assisting) RAN node. In other embodiments, the (assisting) RAN node may move toward the master RAN node if it is beyond a threshold distance from the (assisting) RAN node. In some embodiments, the RAN node may use internally stored LDM data to make the above determination. In some embodiments, the LDM data may include connection schedule data of other RAN nodes in addition to the connection schedule data of the master RAN node.

[0096] FIG. 12D illustrates an exemplary flight schedule (1240) configured for all master and assist UAVs in a particular geographic location, according to one embodiment of the present disclosure. In some embodiments, the master UAV may initiate inter-RAN node wireless transmissions, e.g., using Wi-Fi transmissions, when in flight mode. The master UAV learns the availability of assisting RAN nodes, such as assist UAVs, in nearby or adjacent geographic locations, and vice versa, from the details of the UAV schedule configured prior to flight mode. As shown in the figure, the flight schedule may be represented as a two-dimensional matrix. In some examples, the X-axis indicates "time" for the master and assist drones, and the Y-axis indicates "geographic location." In some examples, the assist UAV (A-UAV) and master UAV (M-UAV) may be scheduled to fly geographic location "G1" at times "T4" and "T5," respectively. In some examples, the A-UAV and M-UAV may be scheduled to fly geographic location "G7" at times "T3" and "T0," respectively. In such an example, at time period "T0," the M-UAV may be serving at location "G7" and the A-UAV may be serving at "G2." Because locations "G7" and "G2" are far enough apart, the M-UAV may continue to operate without connecting with the A-UAV. In this scenario, when the AD in "G2" recognizes that additional subscription data is required, it moves toward the MD in "G7" and obtains the required subscription data via the Uu interface (614), as described with reference to Figures 7, 8, 11, and 12A-12D.

[0097] During time period T2, the M-UAV may be serving at the "G3" location, and the A-UAV may be serving at the "G4" location, which are adjacent locations. In this example, if the A-UAV at the "G4" location recognizes the need for additional subscription data, it initiates inter-RAN node wireless transmissions by directing its transmission or radio beam toward the "G3" location and broadcasting its IP address via the appropriate SIB along with a notification of the need for subscription data. The A-UAV may adjust its position so that its transmissions can reach the M-UAV. If the M-UAV learns from its configured flight schedule during time period T2 that an A-UAV is nearby, it activates an inter-RAN node wireless sniffing mode. In this mode, if the M-UAV receives any broadcast data from the A-UAV and there is a notification of the need for subscription data, the M-UAV may read the A-UAV's IP address and initiate the establishment of an X2 / Xn interface between the two RAN nodes (the M-UAV and the A-UAV). The M-UAV may send an X2 / Xn Setup Request to the A-UAV, including its IP address. The A-UAV responds with an X2 / Xn Setup Response message, including a list of UEs for which subscription data is requested. The M-UAV collects all requested UE subscription data and responds to the A-UAV via an X2 / Xn Information Transfer message, including the list of UE subscription data. After the A-UAV successfully acquires the required subscription data, the A-UAV can initiate the release of the X2 / Xn connection with the M-UAV and continue service to all users in that geographic location. In instances where the A-UAV has moved closer to the M-UAV, the A-UAV may return to its original location.

[0098] In time period T3, the M-UAV may be serving at the G8 location and the A-UAV at the G7 location, which are nearby or adjacent locations. Thus, in such an example, the procedure is similar to that described above for time period T2. In such an example, the A-UAV may direct a RAN node-to-RAN node radio beam (1222) to the G8 location. In time period T4, the A-UAV is serving at the G1 geographic location. Because the M-UAV is not providing service at any geographic location in T4, the A-UAV is alone and, if the A-UAV requires additional subscription information, is disabled and unable to provide any service to these users. In time period T5, the M-UAV may be serving at the G1 geographic location alone and may be fully equipped to provide service at the geographic location. In the example described in FIG. 12D, the flight schedule is stored in a data structure representing a 2D matrix, but those skilled in the art will appreciate that the flight schedule may be stored using any other data structure suitable for representing flight schedules for multiple mobile RAN nodes.

[0099] FIG. 13 illustrates an example method 1300 for providing network coverage and network services by a RAN node, such as an assisting UAV, for a requested geographic location, according to one embodiment of the present disclosure. In one embodiment, the assisting UAV 1302-2 may have flight information for other UAVs (not shown) forming a fleet of UAVs. Flight information for other UAVs may include, but is not limited to, flight schedules, IP addresses, geographic locations, unique identifier attributes, etc. In some embodiments, the flight information may be provided to the assisting UAV 1302-2 or the master UAV 1302-1 via an Operation, Administration, and Management (OAM) interface or may be loaded into a given UAV via a management interface. In some embodiments, fleet information, i.e., information about other UAVs / mobile RAN nodes, may be provided to the UAV 1302-2 "dynamically" via the OAM / management interface.

[0100] In an exemplary embodiment, the assisting UAV 1302-2 may verify whether UAVs in the fleet are actually within the coverage range of the wireless inter-RAN link by sniffing other nearby UAVs (not shown in FIG. 13). The assisting UAV 1302-2 (typically a RAN node) may be configured to sniff for other UAVs by determining the master UAV 1302-1's location in a flight schedule or by broadcasting for wireless signals across a geographic location and listening for responses. In other embodiments, the assisting UAV 1302-2 may be configured to locate the nearby master UAV 1302-1 using radar. In some examples, in step 1304, the assisting UAV 1302-2 stops wireless service and moves toward the master UAV 1302-1. The assisting UAV 1302-2 may be configured to stop service to the UE 104. For example, the assisting UAV 1302-2 may be configured to stop serving the UE 104 for purposes such as obtaining operational data required for serving the UE 104, maintenance, software upgrades, etc. In step 1306, the assisting UAV 1302-2 successfully detects cell coverage of the master UAV 1302-1. In some embodiments, the assisting UAV 1302-2 may move from a first geographic location where it was serving the UE 104 to a second geographic location where the master UAV 1302-1 is serving the UE 104. In step 1308, the assisting UAV 1302-2 successfully establishes a communication channel, such as an RRC connection, with the master UAV 1302-1. In step 1310, the assisting UAV 1302-2 transmits a set of request signals, such as a NAS message, i.e., a UL information transfer request for user subscription data, to the master UAV 1302-1 via the established RRC connection. The user subscription information may include a list of UEs, geographic location coordinates, and other details that may be pre-specified.

[0101] In step 1312, the master UAV 1302-1 maps all UEs associated with the requested geographical location coordinates and collects necessary operational data, such as subscription data, from the LDM. In step 1314, the master UAV 1302-1 transmits a set of response signals, for example, to the assisting UAV 1302-2, via a DL Information Transfer Response (NAS) message containing the user subscription information / user subscription data requested in step 1310. The assisting UAV 1302-2 may receive the set of response signals. In step 1316, the assisting UAV 1302-2 updates its LDM using the received operational data. The updated LDM can be used to provide services to the UE. In step 1318, the assisting UAV 1302-2 disconnects the RRC connection established in step 1308 and begins moving toward the first geographical location (e.g., geographical location N). In step 1320, the assist UAV 1302-2 resumes wireless service after reaching the first geographic location.

[0102] In one embodiment, the assisting UAV (1302-2) stops its own radio interface / service and sniffs for the availability of other nearby UAVs by reading the pilot signals and synchronization channels of other UAVs / mobile radio units / RAN nodes using the same radio resources. In one embodiment, if a given assisting UAV (1302-2) has additional radio resources to sniff for other nearby UAVs, the assisting UAV does not need to stop its radio interface / service to the UE (user device).

[0103] Figure 14 illustrates a signal flow diagram (1400) including exemplary communications between various modules / components of a master UAV and an assisting UAV for obtaining a subscription, according to one embodiment of the present disclosure. As shown, in one embodiment, the master UAV includes a local CN-UP (1402), a SEPP (1404), and an L3 application (1406). Similarly, the assisting UAV includes an L3 application (1408), a SEPP (1410), and a local CN-UP (1412). Obtaining operational data, such as subscription data, will be described with reference to the components / modules of the master UAV and the assisting UAV, as illustrated in Figure 14.

[0104] In step 1414, an Xn / IAB link 1232 may be established between the master UAV and the assist UAV by executing the L3 application 1406 and the L3 application 1408, respectively. In step 1416, an N32 link is established between the master UAV and the assist UAV by executing the SEPP 1404 and the SEPP 1410. Then, in step 1418, the local CN 1412 sends an operational data request to the L3 application 1408. In one embodiment, the operational data request may include information such as area, GPS coordinates, coverage, etc. In step 1420, the operational data request message may be forwarded to the L3 application 1406 as an information transfer request using the Xn Application Protocol (XnAP). In step 1422, the L3 application 1406 sends the operational data request to the local CN 1402. In response, in step 1424, the local CN (1402) prepares the requested data in the local LDM (master UAV) according to the area / GPS coordinates. In step 1426, the local CN (1402) sends an operational data response, i.e., a subscription data subset, to, for example, the L3 application (1406). In step 1428, the L3 application (1406) sends a reverse information transfer, i.e., an operational data response message, to the L3 application (1408) using the XnAP interface. In step 1430, the L3 application (1408) sends an operational response, i.e., a subscription data subset, to, for example, the local CN (1412). In step 1432, the local CN-UP (1412) of the assisting node can be configured to update the LDM (604) associated with the assisting node with the operational data received by the assisting node via the operational data response message.

[0105] Figure 15 illustrates a signal flow diagram (1500) for an exemplary docking procedure for a UAV or mobile RAN node to offload data when a core network or ISP becomes available using proposed new N32 / N9 messages, according to one embodiment of the present disclosure. In one embodiment, a docking procedure is defined in which a UAV or mobile RAN node offloads data when a core network or ISP becomes available. This disclosure proposes additional new N32 / N9 messages to help the RAN node connect to an available ISP or core network. The docked UAV (master UAV or assist UAV) includes an LW-AMF (1502) and an LW-UPF (1504) that communicate with a central core network (1506) and a data network (1508). As shown in Figure 15, the method of docking (or offloading data depending on the availability of a core network or ISP) is described with reference to the above components / modules of the UAV.

[0106] In step (1510), the UAV successfully returns to the docking station, and the LW-AMF (1502) determines the UAV's "docked" state. In response to docking, in step (1512), the LW-AMF (1502) sends a set of update signals to the central core network (1506) to update the AMF UE contexts. In one embodiment, the update signals include a list of old and new UE contexts. In step (1514), the central core network (1506) updates the centralized database with the received UE contexts. In step (1516), the central core network (1506) checks and verifies authentication and security for all new UE contexts. In step (1518), the central core network (1506) sends a set of verification signals including a set of UEs (104) verified by the central core network (1506). The LW-AMF (1502) may be configured to receive a set of validation signals addressed to the LW-AMF (1502) for updating AMF UE contexts. In step 1520, the LW-AMF (1502) may blacklist all rejected UEs and delete the corresponding UE contexts. In step 1522, the central core network (1506) establishes a session, such as a Protocol Data Unit (PDU) session, for each validated AMF UE context. The session may represent a communication channel. In step 1524, the LW-AMF (1502) may send an uplink data transfer request to the LW-UPF (1504). In one embodiment, the uplink data transfer request includes a list of accepted UE contexts. The uplink data forwarding request can be used to cause the LW-UPF (1504) to transmit operational data cached in the local CN-UP cache (906) to the CN (1506). In step (1526), ​​the LW-UPF (1504) starts transmitting the accepted UE's cached operational data to the central core network (1506) in the uplink.In step 1528, the central core network 1506 forwards the uplink data to the data network 1508, sending the data toward the Internet. The RAN node may trigger the CN 1506 to forward cached operational data to the DN 1508 by providing a notification thereof in the uplink data forwarding request. In step 1530, the LW-UPF 1504 may delete cached operational data for all rejected UEs 104. In step 1532, the LW-UPF 1504 may send an uplink data forwarding response to the LW-AMF 1502.

[0107] 16A-16F illustrate example use cases (1600, 1610, 1620, 1630, 1640, 1650) for implementing a RAN node-to-node interface between a master UAV and an assisting UAV, according to one embodiment of the present disclosure. As shown in the example use case (1600) of FIG. 16A, in one embodiment, the RAN node-to-node interface between the master UAV and the assisting UAV may be implemented via RF radio beams (1602) based on 5G+ / 6G+ / IEEE technology. In another embodiment, the RAN node-to-node interface between the master UAV and the assisting UAV may be implemented via radio assisted by an intelligent reflective surface (IRS) (1612) to address non-line-of-sight scenarios, as shown in FIG. 16B. In yet another embodiment, as shown in FIG. 16C, the RAN node-to-node interface between the master UAV and the assisting UAV may be realized via RF radio assisted by an airplane (1622) based on 5G+ / 6G+ / IEEE technology. In yet another embodiment, as shown in FIG. 16D, the RAN node-to-node interface between the master UAV and the assisting UAV may be realized via RF radio assisted by a satellite / 5G+ / 6G+ / IEEE technology-based satellite (1632). In another embodiment, as shown in FIG. 16E, the RAN node-to-node interface between the master UAV and the assisting UAV may be realized via RF radio assisted by a deep-sea / 5G+ / 6G+ / IEEE technology-based surface vehicle (1642). In yet another embodiment, as shown in FIG. 16F, the RAN node-to-node interface between the master UAV and the assisting UAV may be realized by another UAV operating as a relay / repeater UAV (1652) using RF radio based on 5G+ / 6G+ / IEEE technology.

[0108] FIG. 17 illustrates a method 1700 for establishing a RAN inter-node interface between an assist UAV and a master UAV according to one embodiment of the present disclosure.

[0109] In one embodiment, the assisting UAV (1704) may decide to connect with the master UAV (1702). Figure 17 shows the communication and signal flow (1706) between the assisting UAV, the master UAV, and an element management system (EMS) or network management system (NMS). The EMS (1706) can configure connection schedule data / flight schedules associated with the assisting UAV (1704) and the master UAV (1702) in steps (1708) and (1710). The assisting UAV (1704) and the master UAV (1702) may be flying in step (1712). If the assisting UAV (1704) recognizes that additional operational data is needed in step (1714), it learns the geographic location of the master UAV (1702) from the flight schedule / connection schedule data in step (1716) and turns on the RAN-to-RAN node interface to emit a radio beam (1222) toward the master UAV (1702) in step (1718). The assisting UAV (1704) broadcasts its IP address and a flag indicating the need for operational data in step (1720) and establishes a connection with the RAN-to-RAN node air interface in step (1726). In steps (1722) and (1724), the master UAV (1702) and the assisting UAV (1704) may exchange RAN-to-RAN node setup requests and responses, respectively. In one embodiment, the RAN-to-RAN node air interface may correspond to either an X2, Xn, or IAB interface. The assist UAV (1704) then receives the necessary operational data from the master UAV (1702) in step (1728), initiates the release of the RAN node-to-RAN node connection in step (1732), and turns off the RAN node-to-RAN node interface in step (1734) to resume service to users in its geographical location.

[0110] Figure 18 illustrates an exemplary representation of a proposed system 1800 for providing a 6G coreless architecture, according to one embodiment of the present disclosure. Those skilled in the art will appreciate that the system of Figure 18 may be similar in functionality to the NgNB 102 or master / assist UAV of Figures 2-15.

[0111] Referring to FIG. 18 , the system (1800) may include one or more processors (1802). The one or more processors (1802) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuits, and / or any device that processes data based on operational instructions. Among other capabilities, the one or more processors (1802) may be configured to fetch and execute computer-readable instructions stored in the memory (1804) of the system (1800). The memory (1804) may be configured to store one or more computer-readable instructions or routines on a non-transitory computer-readable storage medium, which may be retrieved and executed to generate or share data packets via a network service. The memory (1804) 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, etc.

[0112] In one embodiment, the system may include an interface (1806). The interface (1806) may include, for example, interfaces for data input / output devices, input / output (I / O) devices, storage devices, etc. The interface (1806) may facilitate communication through the system. The interface (1806) may provide a communication path for one or more components of the system. Examples of such components include, but are not limited to, a processing engine (1808) and a database (1810).

[0113] The processing engine (1808) may be implemented as a combination of hardware and programming (e.g., programmable instructions) to implement one or more functions of the processing engine (1808). In the examples described herein, such a combination of hardware and programming may be implemented in several different ways. For example, the programming of the processing engine (1808) may be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware of the processing engine (1808) may include processing resources (e.g., one or more processors) for executing such instructions. In this example, the machine-readable storage medium may store instructions that, when executed by the processing resources, implement the processing engine (1808). In such an example, a system may include a machine-readable storage medium that stores the instructions and the processing resources that execute the instructions, or the machine-readable storage medium may be accessible to but separate from the system and the processing resources. In other examples, the processing engine (1808) may be implemented by electronic circuitry.

[0114] One or more modules / units, such as but not limited to the management plane (602), L3 application (608), Uu stack (610), core network interface (I / F) stack (616), RAN inter-node interface (I / F) stack (618), and L2 application (Mac scheduler) (620), described with reference to Figure 6, may be implemented as a processing engine. For example, the processing engine (1808) may include a RAN inter-node communication engine (1812), an Xn / IAB link engine (1814), a query engine (1816), a data acquisition engine (1818), a user information management engine (1820), a downlink / uplink information management engine (1822), a data offload engine (1824), a fleet management engine (1826), a global positioning system (GPS) engine (1828), other engines (1830), etc. The functionality of these engines can be inferred in the context of a UAV / Mobile RAN node from the descriptions of Figures 1-17.

[0115] As shown in FIG. 19, the computer system (1900) may include an external storage device (1910), a bus (1920), a main memory (1930), a read-only memory (1940), a mass storage device (1950), a communication port (1960), and a processor (1970). Those skilled in the art will appreciate that the computer system (1900) may include two or more processors and communication ports. The communication port 1960 may be selected depending on the network to which the computer system 1900 is connected, such as a local area network (LAN), a wide area network (WAN), or any other network. The main memory (1930) may be random access memory (RAM) or any other dynamic storage device commonly known in the art. The read-only memory (1940) may be any static storage device, such as, but not limited to, a programmable read-only memory (PROM) chip for storing static information such as boot-up or basic input / output system (BIOS) instructions for the processor (1970). The mass storage device (1950) may be any current or future mass storage solution that can be used to store information and / or instructions.

[0116] The bus (1920) may communicatively couple the processor (1970) to other memory, storage, and communication blocks. Optionally, operator and management interfaces, such as a display, keyboard, and cursor control device, may be coupled to the bus (1920) to assist in direct operator interaction with the computer system (1900). Other operator and management interfaces may be provided via a network connection connected via the communication port (1960). It should be noted that the above-described exemplary computer system (1900) is not intended to limit the scope of this disclosure.

[0117] While considerable emphasis has been placed herein on preferred embodiments, it will be understood that many embodiments can be made and that many changes can be made to the preferred embodiments without departing from the principles of the present disclosure. While these and other changes in the preferred embodiments of the present disclosure will be apparent to those skilled in the art from the disclosure herein, it is hereby expressly understood that the foregoing illustrative matter is intended merely as an illustration of the present disclosure, and not as a limitation thereof.

[0118] Advantages of the present disclosure The present disclosure provides systems and methods for implementing coreless operation of RAN nodes.

[0119] This disclosure provides an approach to implementing mobile RAN nodes on UAVs and providing network coverage and network services using UAVs in a coreless mode.

[0120] The present disclosure provides a coreless 6G network architecture for providing network coverage to UEs.

[0121] The present disclosure provides an easy and efficient mechanism for offloading data from a mobile RAN / UAV when the core network is available to update UE context data changes.

Claims

1. 1. A system for broadcasting connectivity status between a radio access network (RAN) node and a core network (CN), comprising: one or more processors; a memory operatively coupled to the one or more processors and including one or more processor-executable instructions that, when executed, cause the one or more processors to: obtaining connection schedule data indicating a schedule for the system to connect to the CN; and periodically broadcasting said connection schedule data to one or more user equipments (UEs) (104) in a set of dedicated signals. A system comprising:

2. The set of dedicated signals is transmitted in either a system information block (SIB) format or a master information block (MIB) format. The system of claim 1 .

3. the set of dedicated signals is transmitted using a Radio Resource Control (RRC) protocol. The system of claim 1 .

4. the one or more processors are configured to transmit the set of dedicated signals in response to a set of request signals received from the one or more UEs (104). The system of claim 1 .

5. 1. A method for communication between one or more radio access network (RAN) nodes, comprising: a RAN node determining a first geographic location corresponding to a master RAN node; the RAN node transmitting a set of request signals to the master RAN node to obtain operational data necessary to provide service to one or more user equipments (UEs) (104); receiving, by the RAN node, a set of response signals from the master RAN node, the response signals including the operational data; the RAN node processing the operational data to provide services to the one or more UEs (104); A method comprising:

6. the RAN node establishing a communication channel with the master RAN node; indicating that the communication channel is a Radio Resource Control (RRC) connection; The method of claim 5.

7. and if a second geographic location is within a predetermined distance from the first geographic location and the operational data is unavailable at the RAN node, moving the RAN node from the second geographic location to the first geographic location corresponding to the master RAN node. The method of claim 5.

8. moving the RAN node from the first geographic location to the second geographic location after receiving the operational data requested in the set of request signals. The method of claim 7.

9. A method for exchanging operational data between a Core Network (CN) (1506) and a Radio Access Network (RAN) node, comprising: a RAN node determining whether the RAN node is connected to the CN; transmitting, by the RAN node, a set of update signals to the CN including operational data associated with one or more User Equipments (UEs) (104), the operational data including a UE context associated with each of the one or more UEs (104); receiving, by the RAN node, a set of validation signals from the CN having a set of validated UEs (104) of the one or more UEs (104) that have been successfully authenticated by the CN; the RAN node establishing a session with each UE in the set of verified UEs; the RAN node exchanging the operational data associated with the set of verified UEs (104) with the CN; A method comprising:

10. the RAN node registering, in a blacklist, UEs among the one or more UEs (104) that have been rejected by the CN, wherein the rejected UEs are removed from the UE context; 10. The method of claim 9.

11. the RAN node includes a LW-Access Management Function (AMF) and a LW-User Plane Function (UPF); The method includes: The LW-AMF sends a data transfer signal to the LW-UPF; The LW-UPF transmits the operational data cached in a local CN user plane cache (906) to the CN (1506); 10. The method of claim 9.

12. the RAN node causing the CN to forward the cached operational data to a data network; The method of claim 11.

13. A Radio Access Network (RAN) node for providing services to a User Equipment (UE) (104), comprising: a Uu stack (610) having a radio frequency (RF) unit (612) configured to exchange radio signals with one or more UEs (104) requesting service from said RAN node; a RAN node-to-node interface (624) configured to communicate with other RAN nodes; a local core network (CN) configured to process operational data associated with the one or more UEs (104) and to communicate with the one or more UEs (104) using the Uu stack (610) to provide services requested by the one or more UEs (104), the local CN being configured to communicate with the other RAN nodes using the RAN node-to-node interface (624) to exchange the operational data necessary to provide the services to the one or more UEs (104); A RAN node comprising:

14. The local CN: a local CN control plane (CP) (902) configured to process the operational data to provide services to the one or more UEs (104); a local CN user plane (UP) (904) configured to receive and transmit the operational data between the local CN CP (902) of the RAN node and the one or more UEs (104), other RAN nodes, or CNs; 14. The RAN node of claim 13.

15. a local CN user plane (UP) cache (906) configured to store the operational data for providing services to the one or more UEs (104); If the operational data required to provide service to the one or more UEs (104) is unavailable in the local CN UP cache (906), the RAN node is configured to obtain the unavailable operational data from a master RAN node having a fully updated database of operational data, and store the operational data in the local CN CP cache (906).

14. The RAN node of claim 13.

16. If the RAN node is a master RAN node, the RAN node has a fully updated database of operational data, and the RAN node: receiving an operational data request from one or more assisting RAN nodes to obtain the operational data associated with the one or more UEs (104); Retrieving the operational data requested by the one or more assisting RAN nodes from the fully updated database of operational data; and and transmitting the requested operational data in an operational data response to the one or more assisting RAN nodes.

14. The RAN node of claim 13.

17. the RAN node, if the operational data required to provide service to the one or more UEs (104) is unavailable at the RAN node, sends an operational data request to a master RAN node using a directional radio beam via the Uu stack (610); 14. The RAN node of claim 13.

18. the RAN-to-RAN node interface (624) of the RAN node and the RAN-to-RAN interface of the other RAN node exchange operational data requests and operational data responses via a Radio Resource Control (RRC) protocol; 14. The RAN node of claim 13.

19. a transport means configured to enable the RAN node to move from a first geographic location to a second geographic location; the local CN moves the RAN node from the first geographical location to the second geographical location when the RAN node is in the first geographical location and requires the operational data available at another RAN node in the second geographical location; 14. The RAN node of claim 13.

20. a management plane (602); The management plane (602) a local dynamic map (LDM) (604) configured to store any of terrain data, location data, and status data associated with a geographic region; a management interface (606) configured to transmit and receive data for the LDM, wherein the management plane (602) is configured to determine availability of other RAN nodes; 14. The RAN node of claim 13.

21. The management plane (602) is configured to use the data stored in the LDM (604) to determine whether a master RAN node is within a predetermined threshold distance from the RAN node.

21. The RAN node of claim 20.

22. a CN interface (I / F) (616) configured to be operatively connected to and communicate with the CN when the RAN node is connected to the CN; the RAN node is configured to receive and transmit the operational data from the CN; 14. The RAN node of claim 13.

23. The RAN node uses the CN interface (616) to transmitting to the CN a set of update signals including operational data associated with the one or more UEs (104), the operational data including a UE context associated with each of the one or more UEs (104); receiving a set of validation signals from the CN, the set of validation signals comprising a set of validated UEs (104) from one or more UEs (104) that have been successfully authenticated by the CN; establishing a session in each UE of the set of verified UEs (104); and exchanging the operational data associated with the set of verified UEs (104) with the CN.

23. The RAN node of claim 22.

24. The local CN CP (902) comprises a Security Edge Protection Proxy (SEPP), the SEPP comprising: authenticating the identity of other RAN nodes with which communication is sought; if authentication is successful, establishing a communication channel between the RAN node and the other RAN node; the communication channel is one of an Xn interface or an integrated access backhaul (IAB) interface; 15. The RAN node of claim 14.

25. A user equipment (UE) (104), one or more processors; a memory operatively coupled to the one or more processors and including one or more processor-executable instructions that, when executed, cause the one or more processors to: receiving a set of dedicated signals from a radio access network (RAN) node; establishing a communication channel with the RAN node based on connection schedule data provided in the set of dedicated signals; and A user equipment (UE) (104) comprising:

26. the one or more processors are configured to transmit a set of request signals to the RAN node, and the set of dedicated signals from the RAN node are received in response to the set of request signals.

26. The UE (104) of claim 25.

27. the one or more processors are configured to select a protocol for communicating with the RAN node based on the set of dedicated signals.

26. The UE (104) of claim 25.

28. 1. A security edge protection proxy (SEPP) system, comprising: Radio Access Network (RAN) nodes, each having one or more processors; a memory operatively coupled to the one or more processors and including one or more processor-executable instructions that, when executed, cause the one or more processors to: authenticating the identity of other RAN nodes with which communication is sought; if authentication is successful, establishing a communication channel between the RAN node and the other RAN node; and A security edge protection proxy (SEPP) system comprising:

29. the communication channel is one of an Xn interface or an integrated access backhaul (IAB) interface; 29. The SEPP system of claim 28.

30. determining a first geographic location corresponding to a master radio access network (RAN) node; transmitting a set of request signals to the master RAN node to obtain operational data necessary to provide service to one or more user equipments (UEs) (104); receiving a set of response signals from the master RAN node, the response signals including the operational data; and processing the operational data to provide services to the one or more UEs (104). Non-transitory computer-readable medium.

Images