Detecting presence of radio access network (RAN) sharing and determining RAN sharing type

Abstract

The application relates to detecting the presence of radio access network (RAN) sharing and determining a RAN sharing type. Techniques for determining a radio access network (RAN) sharing type used within a network are described. In one example, a computing system receives a message to implement a network slice of a RAN, the message including a configuration file including a first public land mobile network (PLMN) identifier and a first operating band value of the RAN. Based on a determination that another RAN slice sub-network having a second PLMN identifier and a first operating band value is provisioned within the RAN, the computing system determines that the RAN sharing type is a multi-operator core network (MOCN). Based on determining that the RAN slice subnet having the second PLMN identifier and the first operating band value is not provisioned within the RAN, the computing system determines that the RAN sharing type is a multi-operator RAN (MORAN). The computing system forwards network traffic for the subscriber device according to the determined RAN sharing type.

Description

[0001] Related Applications

[0002] This application claims the benefit of U.S. Application No. 18 / 829,146, filed on September 9, 2024, and U.S. Provisional Application No. 63 / 582,764, filed on September 14, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to computer networks, and more particularly, to wireless access networks. Background Art

[0004] Computer networks have become ubiquitous, and the number of network applications, networked devices, and types of networked devices is increasing rapidly. Such devices now include computers, smartphones, Internet of Things (IoT) devices, vehicles, medical devices, factory equipment, and more. 5G mobile network architecture enhances the ability to use cloud-based network function virtualization (NFV) to provide communication services. A mobile network operator's radio access network (RAN) combined with the functions of the 5G core can be used to create a dedicated network. For example, a network can be created for a specific service level agreement (SLA), special use cases, or other specific requirements. Examples of such networks include private mobile networks, industrial networks, and dedicated networks for connected vehicles. A network slice is a logical network (e.g., a portion of the RAN) that provides specific network capabilities and network characteristics, supporting various service attributes for network slice customers. The management and orchestration of network slices are performed by network operators to support their communication services.

[0005] The infrastructure of the RAN can be shared by different network operators. Several different schemes can be used to share the various infrastructures of the RAN; such infrastructure may include one or more of the core network, radio controller, backhaul network, base station, site, and spectrum bandwidth, and they can be shared among multiple network operators. For example, in a multi-operator radio access network (MORAN), the infrastructure of the RAN is shared, but different network operators are allocated different, non-overlapping spectrum bandwidths for exchanging network traffic. As another example, in a multi-operator core network (MOCN), the entire infrastructure of the RAN, including the spectrum bandwidth, is shared, so that different network operators can be allocated the same or overlapping spectrum bandwidths for exchanging network traffic. In addition, different operators may use various complex combinations of MORAN, MOCN, and other RAN sharing schemes within a single mobile network infrastructure. Summary of the invention

[0006] In general, the present disclosure describes techniques for automatically detecting the presence of radio access network (RAN) sharing within a network and determining the type of RAN sharing used within the network. In one example, a computing system receives a message for implementing network slicing of the RAN. The message includes a configuration file that includes a first public land mobile network (PLMN) identifier and a first operating frequency band value. The computing system can analyze one or more fields in one or more data structures of the message to infer that the RAN is being shared and / or the type of RAN sharing. For example, the computing system determines that another RAN slice subnet with a second PLMN identifier is provisioned within the RAN. Based on the presence of the first PLMN identifier and the second PLMN identifier within the common RAN, the computing system determines that RAN sharing is used within the network.

[0007] In the first scenario, the computing system may determine that another RAN slice subnet with a second PLMN identifier provisioned within the RAN is provisioned with the same first operating frequency band value. Since the first PLMN identifier and the second PLMN identifier are configured to use the same first operating frequency band, the computing system determines that the RAN sharing type is MOCN.

[0008] In the second scenario, the computing system may determine that another RAN slice subnet having a PLMN identifier different from the first PLMN identifier is not provisioned with the same first operating frequency band value within the RAN. Therefore, since the RAN slice subnets are provisioned with different PLMN identifiers, but these RAN slice subnets do not share the same first operating frequency band, the computing system determines that the RAN sharing type is MORAN.

[0009] The computing system may configure one or more network devices to forward network traffic of one or more subscriber devices according to the determined RAN sharing type. For example, the computing system may configure and / or provision a RAN slice subnet or a core network slice subnet according to a configuration file specified by the message and the determined RAN sharing type.

[0010] These techniques may provide one or more technical advantages for implementing at least one practical application. For example, the techniques of the present disclosure may enable a computing system to determine the type of RAN sharing used for a mobile network and use the determined type of RAN sharing to manage network slices in the RAN. In addition, the techniques of the present disclosure may enable a computing system to determine the type of RAN sharing used before, during, or after provisioning a network slice or a network slice subnet in a mobile network. In addition, the techniques of the present disclosure may enable a computing system to determine a change in the type of RAN sharing used in a mobile network, or to determine an arbitrarily complex RAN sharing configuration, for example, when two parties use a first type of RAN sharing, and thereafter one of the parties uses a second type of RAN sharing with a third party. Such a computing system described herein is capable of distinguishing different types of RAN sharing, applying different network slices and network service profiles based on the type of RAN sharing used, and applying different service level agreement (SLA) policies or network policies to network traffic based on the type of RAN sharing used. Therefore, the techniques in the present disclosure may provide the ability to change one or more operating characteristics of a shared RAN based on the type of RAN sharing to better support the provisioning, operation, management, and regulation of network slices.

[0011] In one example, the present disclosure describes a computing system comprising: a processing circuit in communication with a storage medium, the processing circuit being configured to: receive a message for implementing network slicing of a radio access network (RAN), the message comprising a configuration file, the configuration file comprising a first public land mobile network (PLMN) identifier and a first operating frequency band value for the RAN; determine that the RAN sharing type is a multi-operator core network (MOCN) based at least in part on determining that at least one RAN slice subnet having a second PLMN identifier and a first operating frequency band value is provisioned within the RAN; and determine that the RAN sharing type is a multi-operator RAN (MORAN) based at least in part on determining that no RAN slice subnet having a second PLMN identifier and a first operating frequency band value is provisioned within the RAN.

[0012] In another example, the present disclosure describes a method, including: receiving, by a computing system, a message for implementing network slicing of a radio access network (RAN), the message including a configuration file, the configuration file including a first public land mobile network (PLMN) identifier and a first operating frequency band value of the RAN; determining, by the computing system, that the RAN sharing type is a multi-operator core network (MOCN) based at least in part on determining that at least one RAN slice subnet having a second PLMN identifier and the first operating frequency band value is provisioned within the RAN; and determining, by the computing system, that the RAN sharing type is a multi-operator RAN (MORAN) based at least in part on determining that no RAN slice subnet having the second PLMN identifier and the first operating frequency band value is provisioned within the RAN.

[0013] In another example, the present disclosure describes a non-transitory computer-readable medium comprising instructions that, when executed, are configured to cause a processing circuit to: receive a message for implementing network slicing of a radio access network (RAN), the message comprising a configuration file, the configuration file comprising a first public land mobile network (PLMN) identifier and a first operating frequency band value of the RAN; determine that the RAN sharing type is a multi-operator core network (MOCN) based at least in part on determining that at least one RAN slice subnet having a second PLMN identifier and the first operating frequency band value is provisioned within the RAN; and determine that the RAN sharing type is a multi-operator RAN (MORAN) based at least in part on determining that no RAN slice subnet having the second PLMN identifier and the first operating frequency band value is provisioned within the RAN.

[0014] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1A is a block diagram illustrating an example network system configured to detect the presence of mobile network sharing in accordance with one or more techniques of this disclosure.

[0016] Figure 1B It is shown Figure 1A A block diagram of a non-real-time RAN intelligent controller (RT RIC) of a service management and orchestration system with further example details.

[0017] Figure 1C It is shown Figure 1A Block diagram of further example details of a near-RT RIC.

[0018] Figure 1D is another block diagram illustrating an example network system configured to detect the presence of mobile network sharing in accordance with one or more techniques of this disclosure.

[0019] Figure 1E It is shown Figure 1D A block diagram of a service management and orchestration system with further example details.

[0020] Figure 2 is a block diagram illustrating a set of examples of RAN sharing.

[0021] Figure 3 is a block diagram illustrating another set of examples of RAN sharing.

[0022] Figure 4 is a block diagram illustrating an example computing system in detail according to the techniques of this disclosure.

[0023] Figure 5 is a block diagram showing the definition of a slice profile data structure.

[0024] Figure 6 is a block diagram showing the definition of the RAN slice subnet profile data structure.

[0025] Figure 7 is a block diagram illustrating the definition of a Core Network (CN) slice subnet profile data structure.

[0026] Figure 8 is a block diagram illustrating the definition of a service profile data structure.

[0027] Fig. 9 is a block diagram illustrating the definition of a radio spectrum data structure.

[0028] Fig.10 is a flow chart illustrating example operations according to the techniques of this disclosure. DETAILED DESCRIPTION

[0029] While there are standards-based definitions for network slice management and RAN sharing, handling the intersection of these two computer network functions is problematic. There are no existing defined interfaces, scenarios, procedures, and / or solutions on how to handle the combination of RAN sharing and RAN slice management. For example, a network may use basic RAN sharing scenarios (e.g., MORAN, where the RAN is shared and each operator uses dedicated spectrum; and MOCN, where the RAN and spectrum are shared by operators). In addition, there are many complex use cases. For example, operator A and operator B may start a MORAN-based RAN sharing agreement on operator A's infrastructure, and later operator B enters into a MOCN RAN sharing agreement with operator C on operator A's infrastructure. Existing RAN slice management is not structured to be aware of and automatically discover the RAN sharing type because there is no clear information defined in the various 3rd Generation Partnership Project (3GPP) specifications to indicate RAN sharing when creating a network slice. In various scenarios, RAN sharing may exist before slicing is introduced, RAN sharing may be added after slicing is introduced and one or more slices are provisioned, and the RAN sharing type may be MORAN or MOCN (or CN sharing, which does not change the RAN behavior).

[0030] The technology of the present disclosure provides a method that automatically detects such a RAN sharing scenario and determines the RAN sharing type without any additional manual intervention / input from the operator, thereby allowing the operating characteristics of the RAN to be automatically changed to better support shared arrangements and / or network slicing. The computing system described herein may thereafter manage network slices in the RAN based on the determined RAN sharing type. For example, the computing system may configure one or more network devices to forward network traffic of one or more subscriber devices according to the determined RAN sharing type. In addition, the computing system may configure and / or provision a RAN slice subnet or a core network slice subnet according to a configuration file specified by a message and the determined RAN sharing type.

[0031] As used herein, a host operator is an operator that owns the infrastructure, manages the network and leases (part of it) to one or more operators. A tenant operator is an operator that uses / leases another operator's infrastructure to provide services. Core Network (CN) sharing means that servers and core network functions are shared.

[0032] The disclosed techniques provide support for a tenant operator network slice management function (NSMF) to drive the hosting (e.g., infrastructure leasing) of an operator's RAN network slice subnet management function (NSSMF) for RAN slicing and MORAN and MOCN RAN sharing scenarios. The disclosed techniques provide support for multi-tenant MORAN and MOCN RAN sharing scenarios, where the leasing operator further leases the "leased" resources to a third-party operator. The disclosed techniques provide support for (MORAN and MOCN) RAN sharing SLAs within the RAN NSSMF. The disclosed techniques also provide support for per-operator / public land mobile network (PLMN) slice subnet SLAs within a multi-tenant SLA-based RAN sharing scenario. These techniques may also be applied to the NSMF.

[0033] A network service such as a network slice may be formed of various elements and sub-elements such as clouds, cloud providers, data centers, resource groups, resources, clusters, manager nodes, and worker nodes. In some examples, a user such as a network operator may wish to deploy thousands of clouds and / or resources in inventory to support a network service.

[0034] The network service provider may configure a portal to the network configuration system that presents visual cues via a user interface that provides a visualization of the service provisioning process and receives user input, which in some cases may be selected from the visualization. In some aspects, the user may be a tenant (e.g., a customer) of the 5G mobile network operator. As an example, the tenant may be an enterprise customer of the mobile network operator. In some aspects, the user may be an administrator of the 5G network service provider.

[0035] Configuring services in a 5G network domain may involve multiple services and multiple service providers. For example, configuring an end-to-end 5G network slice may involve configuring network functions in multiple geographically distributed data centers ("multi-cloud") to support network slicing, and may also involve services provided and implemented via core interfaces (e.g., service gateway interface (SGi)) in multiple network domains ("multi-domains"), such as RAN, transport network, core network services. Different services and network domains may have different capabilities, functions, and service levels. A tenant may want to configure a complete communication service to a network infrastructure that it owns or leases, and in some cases provide related network slices.

[0036] A tenant (or a network service provider for a provider-owned slice, or another party) can initiate the configuration of a communication service (e.g., a network slice) with a predefined service level agreement (SLA) and a network slice template (NST) on demand, and the tenant can specify different attributes of the service, such as tracking areas, computing clouds / data centers, allowed subscribers, network slice selection policies, etc. The network configuration system can facilitate a service order creation process that an end user can use to request an on-demand configuration of an end-to-end network that can be created for specific SLAs, use cases, and user needs. In some aspects, the end user can be a tenant of a mobile network operator, which can configure the communication service on demand.

[0037] Network service providers, such as mobile network operators, can use the techniques described herein to provide Network as a Service (NaaS) to their customers and facilitate the management and regulation of network services. For example, these techniques can facilitate end-users and on-demand configuration of private mobile networks. Examples of such private mobile networks include private networks for connected vehicles, Internet of Things (IoT) networks, industrial networks, etc. In some aspects, network service providers can create network slices with QoS and other parameters on demand based on service orders generated by tenants or other end users.

[0038] The technology disclosed herein includes configuring a portal that provides a user interface, and the user interface promotes the creation of service orders by tenants and other customers of network operators. The user interface can guide users to complete a series of operations of a workflow, and these operations can lead to the creation of a service order, and the service order can instruct the configuration system to configure and deploy network services for users. As a practical application of the technology described in this disclosure, the end-user tenants of network operators can use the configuration portal to configure the communication services of the network operator for use by the tenants. The configuration portal can promote the end-user to order network services, and configure network services on demand without involving the personnel of the mobile network operator. As a result, compared with existing systems, tenants can accept the benefits of communication servers more quickly. In addition, for mobile network operators, the overhead can be less.

[0039] Figure 1A is a block diagram illustrating an example network system configured to detect the presence of mobile network sharing in accordance with one or more techniques of this disclosure. Figure 1AIn the example shown, the network system 100 includes a service management and orchestration (SMO) system 112, a non-RT RIC 122, a near-RT RIC 124, and a mobile network 120. The mobile network 120 includes one or more radio access networks (RANs) (e.g., RAN 109) and a mobile core network (or simply "core") 105, which provides user equipment 104A-104N (collectively referred to as "UE 104") with access to one or more applications or services provided by a data network 140. In some examples, the mobile network 120 includes a 5G or xG mobile network.

[0040] UE 104 may represent a smartphone, a desktop computer, a laptop computer, a tablet computer, a smart watch, and / or an “Internet of Things” (IoT) device such as a camera, a sensor, a television, an appliance, etc. Figure 1A As shown, the mobile network 120 includes a RAN 109 that provides network access, data transmission, and other services to the UE 104. In some examples, the RAN 109 can be an open radio access network (O-RAN), a 5G mobile network RAN, a 4G LTE mobile network RAN, another type of RAN, a 3GPP mobile network RAN, or a combination of the above. For example, in a 5G wireless access network, the RAN 109 includes multiple cell sites (or simply "cells"), each of which includes radio equipment, such as corresponding base stations 106A-106N (collectively referred to as "base stations 106"), also known as gNodeBs, to exchange packetized data within the data network, thereby ultimately accessing one or more applications or services provided by the data network 140. Each base station 106 is divided into three functional components: a radio unit (RU), a distributed unit (DU), and a central unit (CU), which can be deployed in various configurations. The RU manages the radio frequency layer and has antenna arrays of various sizes and shapes. The DU performs lower layer protocol processing. The CU performs upper layer protocol processing. Depending on the operator and service requirements, the base station 106 can be deployed as a whole, for example, the RU, DU, and CU reside in the cell site, or these functions can be distributed across multiple cell sites, and the CU resides in an edge cloud site that controls multiple distributed DUs. For example, O-RAN is a networking approach in which mobile fronthaul and midhaul networks can be deployed using decoupled functions. These decoupled functions can be cloud-based functions.

[0041] The RAN 109 of the mobile network 120 is connected to the core 105 to exchange data packets with the data network 140. The core 105 can be a 5G core network, and the data network 140 can represent, for example, one or more service provider networks and services, the Internet, third-party services, one or more IP-VPNs, IP multimedia subsystems, combinations thereof, or other networks or combinations of networks. In some examples, resources associated with services provided by the mobile network operator to tenants can be provided or managed by functions of components of the core 105 and / or RAN 109. In some examples, the core 105 implements various discrete control plane and user plane functions for the network system 100. Examples of 5G control plane functions that may be provided by the core 105 include an access mobility management function (AMF) that provides access mobility management services, a session management function (SMF) that provides session management services, a policy control function (PCF) that provides policy control services, a user data management (UDM) that provides management of network user data, a network repository function (NRF) that provides a repository that can be used to register and discover services in the network operator's network, an authentication server function (AUSF) that provides authentication services, a network slice selection function (NSSF), a NSMF that can be used to select an instance of an available network slice for use by any UE device 104, and a network slice subnet management function (NSSMF) that provides coordination, management, and orchestration of network slice subnet instances (NSSI). The core 105 may also include a user plane function (UPF) that provides packet routing, forwarding, and other network data processing functions (e.g., quality of service, packet inspection, traffic optimization, etc.).

[0042] Further details on the services and functionality provided by the 5G Core can be found in 3rd Generation Partnership Project 2021 Technical Specification Group Services and System Aspects; System Architecture for 5G System (5GS); Stage 2 (Release 17), TS 23.501 V17.0.0 (2021-03), which has been superseded by 2021 Technical Specification Group Services and System Aspects; System Architecture for 5G System (5GS); Stage 2 (Release 18), TS 23.501 V18.2.2 (2023-07), each of which is hereby incorporated by reference in its entirety. Further details on the services and functionality provided by the RAN 109 can be found in “5G, Management and Orchestration; 5G Network Resource Model (NRM)”, Stage 2 and Stage 3, 3GPP TS 28.541, Version 17.6.0, Release 17 (2022-05), which is hereby incorporated by reference in its entirety. More details on the O-RAN architecture can be found in the O-RAN ALLIANCE’s “O-RAN Architecture Description”, Version 7.00, October 2022, the entire contents of which are incorporated herein by reference.

[0043] A network system such as network system 100 may include a service management and orchestration (SMO) system that provides various framework functions and a non-RT RIC configured in accordance with the Open Radio Access Network (O-RAN) standard ("O-RAN architecture") to manage and / or monitor various aspects of the RAN and / or 5G core. The O-RAN architecture may include a non-RT RIC and a near-RT, each of which performs different functions and services for the RAN function. The non-RT RIC is an orchestration and automation function that is configured to provide radio resource management, higher layer process optimization, policy optimization, and provide guidance, parameters, policies, and artificial intelligence (AI) and machine learning (ML) models to support the operation of the near-RT RIC functions in the RAN. The non-RT RIC may load one or more applications (e.g., rApps) that provide non-real-time (e.g., greater than one second) control of the RAN elements and their resources, and the near-RT RIC may load one or more applications (e.g., xApps) that provide near-real-time control of the RAN elements and their resources.

[0044] The O-RAN architecture includes several interfaces, such as A1, O1, and O2 interfaces, each of which is used to provide functions and services through which the SMO and RIC can configure or direct other components of the RAN. For example, the functions and services of the non-RT RIC may include policy management services and / or rich information services for the near-RT RIC provided through the A1 interface (collectively referred to herein as "A1 services" because these services are provided through the A1 interface); operations, administration, and maintenance (OAM) services for O-RAN management elements provided through the O1 interface, such as performance management services and configuration management services (referred to herein as "O1 services" because these services are provided through the O1 interface); infrastructure management services and deployment management services for resources of the O-RAN cloud provided through the O2 interface (referred to herein as "O2 services" because these services are provided through the O2 interface) and / or other services, such as service management and exposure (SME) services (e.g., service registration, update of service registration), data management and exposure (DME) services, and / or AI / ML services.

[0045] like Figure 1AAs described in the example of , various aspects of the RAN 109 and / or the core 105 can be managed and / or monitored by the SMO 112, the non-RT RIC 122, and the near-RT RIC 124. In some examples, the SMO 112, the non-RT RIC 122, and the near-RT RIC 124 can be operated by a mobile network operator that provides 5G services to tenants. The SMO 112 can orchestrate and control the management and automation aspects of the RAN 109 (e.g., network slicing, management, and orchestration of O-Cloud, etc.). In addition, the SMO 112 can control various aspects of the non-RT RIC 122 and the near-RT RIC 124. The non-RT RIC 122 can provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources (e.g., RUs, DUs, and CUs), workflow management, and policy-based control of applications and features of the near-RT RIC 124. The near real-time RIC 124 may provide near real-time (eg, millisecond level) control and optimization of RAN elements and resources via fine-grained data collection and actions performed through the E2 interface 165. Figure 1B As further described in , non-RT RIC 122 and near-RT RIC 124 can be deployed as a highly scalable, microservices-based containerized architecture. In some examples, near-RT RIC 124 can be located in an edge cloud or a regional cloud.

[0046] The non-RT RIC 122 may host one or more applications, such as an application 123 that manages non-real-time events within the non-RT RIC 122 (eg, Figure 1B Application 123 may utilize functionality exposed via the non-RT RIC framework of non-RT RIC 122. Application 123 may be used to control and manage RAN elements and resources, such as resources in the near-RT RIC 124, RAN nodes, and / or O-RAN cloud. Application 123 may also utilize network data, performance metrics, and subscriber data to provide recommendations for network optimization and operational guidance (e.g., policies) to one or more applications of the near-RT RIC 124. Although illustrated as being within the non-RT RIC 122, any one or more of the applications 123 may be executed by a third party separate from the non-RT RIC 122.

[0047] As further described below, the non-RT RIC 122 can provide services using the A1, O1, and O2 interfaces. The A1 interface connects the non-RT RIC 122 and the near-RT RIC 124. The non-RT RIC 122 can perform services via the A1 interface, such as policy management services (e.g., creation and updating of policies), ML model management services, and / or rich information services. Services performed via the A1 interface are referred to herein as "A1 services." The O1 interface may include an interface connecting the SMO 112 to elements managed by the O-RAN, such as the near-RT RIC 124 and / or RAN nodes (e.g., O-RAN Central Unit (O-CU), O-RAN Distributed Unit (O-DU)). The non-RT RIC 122 can perform services via the O1 interface, such as configuration management services and performance management services (e.g., operations and maintenance (OAM) services), fault monitoring, file management, heartbeat, tracking, physical network function (PNF) discovery, software management, etc.) of elements managed by the O-RAN. Services performed via the O1 interface are referred to herein as "O1 services". The O2 interface may include an interface that connects the SMO 112 to the resources of the ORAN O-Cloud. The O-Cloud may include one or more physical infrastructure nodes that host O-RAN functions (e.g., virtual network functions), supporting software components, and appropriate management and orchestration functions. The non-RT RIC 122 may perform services via the O2 interface, such as services that provide infrastructure management and / or network function deployment of resources in the O-Cloud (e.g., discovery and management of O-Cloud resources; horizontal contraction and horizontal expansion of the cloud / deployment; fault, configuration, billing, performance, and security (FCAPS) of the cloud / deployment; software management of the cloud platform / deployment; creation / deletion of deployments and associated allocated O-Cloud resources). Services performed via the O2 interface are referred to herein as "O2 services". The non-RT RIC 122 may also perform other functions and services, such as service management and exposure (SME) services (e.g., service registration, updates to service registrations), data management and exposure (DME) services, AI / ML services, etc.

[0048] The techniques of the present disclosure provide automatic detection of RAN sharing and determination of the type of RAN sharing during slice management operations, as implemented in the RAN sharing detector 103 of the SMO 112. Traditional specifications for RAN sharing do not include automatic detection and may require manual input or intervention by an operator to configure RAN sharing or determine the existence of such RAN sharing.

[0049] According to the techniques of this disclosure, the RAN sharing detector 103 of the SMO 112 may automatically detect the presence of RAN sharing within the mobile network 120 and determine the type of RAN sharing used within the mobile network 120 .

[0050] For example, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109. In some examples, the RAN sharing detector 103 receives a message for the RAN 109 from the NSMF of the mobile core network 105. The message includes a configuration file, which includes a first PLMN identifier and a first operating frequency band value. In some examples, the configuration file includes a slice configuration file ("SliceProfile") data structure, which includes a PLMN identifier ("plmninfo" ID) and an operating frequency band ("nrOperatingBands") value. The RAN sharing detector 103 analyzes the current values ​​of various fields of the data structure of the 5G NRM to automatically detect the presence of RAN sharing and the RAN sharing type.

[0051] For example, the RAN sharing detector 103 analyzes one or more fields in one or more data structures of the message to infer that the RAN 109 is being shared. For example, the RAN sharing detector 103 determines that another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109. Based on the presence of the first PLMN identifier and the second PLMN identifier within the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is used within the mobile network 120. This is because the presence of a RAN subnet provisioned with two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are using resources of the RAN 109.

[0052] Thus, in an example where the SMO 112 does not provision any network slices associated with different PLMN identifiers within the RAN 109, receiving a message associated with a first PLMN identifier indicates that only a single mobile network operator (e.g., associated with the first PLMN identifier) ​​is using the resources of the RAN 109 and therefore the RAN 109 is not shared.

[0053] As another example of that the SMO 112 has provisioned a network slice associated with the second PLMN identifier within the RAN 109, receipt of the message associated with the first PLMN identifier indicates that at least the first mobile network operator and the second mobile network operator (e.g., associated with the first PLMN identifier and the second PLMN identifier, respectively) are using resources of the RAN 109, and therefore, the RAN 109 is shared.

[0054] In addition, in the case where the RAN 109 is shared, the RAN sharing detector 103 analyzes one or more fields in one or more data structures of the message to determine the RAN sharing type. In the first scenario, the RAN sharing detector 103 determines that the second RAN slice subnet with the second PLMN identifier provisioned within the RAN 109 has been provisioned with the same first operating frequency band value as specified in the configuration file of the message. Because the first PLMN identifier and the second PLMN identifier are configured to use the same first operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MOCN. This is because the presence of two different PLMN identifiers indicating the use of the same operating frequency band indicates that the two network operators corresponding to the two PLMN identifiers share the same operating frequency band within the RAN 109, thereby indicating that the RAN 109 uses MOCN.

[0055] In the second scenario, the RAN sharing detector 103 determines that there are no other RAN slice subnets that have been provisioned with the same first operating frequency band value and have a PLMN identifier different from the first PLMN identifier within the RAN 109. Therefore, since the RAN slice subnets are provisioned with different PLMN identifiers (RAN 109 is shared), but these RAN slice subnets do not share an operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MORAN. This is because the presence of two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are sharing the RAN 109, but since each network operator has non-overlapping operating frequency bands, there is no sharing of the operating frequency band, thereby indicating that the RAN 109 uses MORAN.

[0056] Thereafter, the RAN sharing detector 103 may manage network slices in the RAN based on the determined RAN sharing type. For example, the RAN sharing detector 103 may configure one or more network devices (e.g., RUs, DUs, and CUs of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type. For example, a profile may include a network slice profile that specifies one or more network slices provisioned within the RAN 109. As another example, a profile may include a service profile that specifies one or more network services provisioned within a network slice of the RAN 109.

[0057] The RAN sharing detector 103 selects a profile or template for provisioning a network slice or a network slice subnet based at least in part on the determined RAN sharing type and the profile. In addition, the RAN sharing detector 103 may apply one or more network policies or SLA policies to provision the network slice or the network slice subnet based at least in part on the determined RAN sharing type. In addition, the RAN sharing detector 103 may allocate resources to the network slice or the network slice subnet based at least in part on the determined RAN sharing type.

[0058] As an example, the configuration file may include a RAN slice subnet configuration file specifying a first working frequency band value. The RAN sharing detector 103 may select, configure and / or provision a RAN slice subnet within the RAN 109 according to the configuration file specified by the message and the determined RAN sharing type. The RAN sharing detector 103 may select a template for deploying a RAN slice subnet within the RAN 109, one or more network services to be deployed within the RAN slice subnet within the RAN 109, and configuration parameters to be used to configure the one or more network services based on the determined RAN sharing type. In addition, the RAN sharing detector 103 configures the resources allocated to the RAN slice subnet to forward traffic via the first working frequency band corresponding to the first working frequency band value.

[0059] As another example, the configuration file may include a core slice subnet configuration file that specifies a first operating frequency band value. The RAN sharing detector 103 may select, configure and / or provision a core network slice subnet within the core network 105 according to the configuration file specified by the message and the determined RAN sharing type. The RAN sharing detector 103 may select a template for deploying a core slice subnet within the core 105, one or more network services to be deployed within the core slice subnet within the core 105, and configuration parameters to be used to configure the one or more network services based on the determined RAN sharing type. In addition, the RAN sharing detector 103 configures the resources allocated to the core slice subnet to forward traffic via the first operating frequency band corresponding to the first operating frequency band value.

[0060] In a first example, the RAN sharing detector 103 configures one or more network devices (e.g., RU, DU, and CU of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MORAN. In this example, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with a first PLMN identifier. Specifically, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of the one or more first subscriber devices 104 via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In addition, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more second subscriber devices associated with a second PLMN identifier via a second operating frequency band different from the first operating frequency band. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the same base station and the same site.

[0061] In a second example, the RAN sharing detector 103 configures one or more network devices (e.g., RU, DU, and CU of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MOCN. In this example, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with the first PLMN identifier and network traffic of one or more second subscriber devices associated with the second PLMN identifier via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the first operating frequency band, the same base station, and the same site.

[0062] The techniques of the present disclosure may provision network slices for RAN sharing at any point in time before, during, or after configuring the RAN 109. For example, in some scenarios, the RAN 109 may be configured for RAN sharing before the RAN sharing detector 103 provisions a network slice or a network slice subnet. As another example, the RAN 109 may be configured for RAN sharing after the RAN sharing detector 103 provisions a network slice or a network slice subnet.

[0063] The above examples are mainly described for the deployment of RAN slice subnets within RAN 109 in the presence of RAN sharing. However, the technology of the present disclosure can also be applied to the deployment of core network slice subnets within the core network 105, or the deployment of end-to-end (E2E) network slices in the presence of RAN sharing.

[0064] The techniques described herein may be applied by any one or more of the NSMF, NSSMF, or a communication service management function (CSMF). Although in the foregoing examples, the RAN sharing detector 103 is implemented within the SMO 112, the functionality of the RAN sharing detector 103 may be implemented in any one of the NSMF, NSSMF, and CSMF, for example. In some examples, the RAN sharing detector 103 may implement one or more of the NSSMF, NSMF, and CSMF for the RAN 109.

[0065] Figure 1B It is shown Figure 1A A block diagram of further example details of the non-RT RIC 122 is provided. Figure 1B In the example shown, the SMO 112 may include a non-RT RIC 122, one or more AI / ML models 142, one or more functions 144 (e.g., NSSMF, NFMF, and other functions), and open interfaces such as an O1 termination interface 168 and an O2 termination interface 169. The SMO 112 may manage the non-RT RIC 122, the near-RT RIC 124, O-RAN managed elements (e.g., a central unit (O-CU) 146 of one or more base stations, an O-RAN distributed unit (O-DU) 148), and resources in the O-RAN cloud 150.

[0066] The non-RT RIC 122 can provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources (e.g., RUs, DUs, and CUs), workflow management, and policy-based control of applications and features of the near-RT RIC 124. The non-RT RIC 122 can be deployed as a highly scalable, microservices-based containerized architecture. In this example, the non-RT RIC 122 can load, deploy, and / or terminate one or more applications, such as rApp 123A to rApp 123N (collectively referred to as "applications 123"). Applications 123 can represent applications that utilize functions exposed via the framework of the non-RT RIC 122. Applications 123 can provide non-real-time (e.g., greater than one second) control of RAN elements and their resources to the non-RT RIC 122. Applications 123 can provide services for radio resource management, higher layer process optimization, policy optimization, and provide guidance, parameters, policies, and AI / ML models to support the operation of RAN functions.

[0067] For example, the application 123 may provide A1 services that provide and facilitate RAN operations and optimization of the near-RT RIC 124, such as providing operational guidance (e.g., policies), enriched information (e.g., predictions), and AI / ML services. The A1 services may include policy management services, such as creation, update, and / or deletion of A1 policies; receiving policy feedback; querying policy types, identifiers, and states; defining which policy types are supported by the near-RT RIC 124; and registering applications (xApps) of the near-RT RIC 124 to specific policy types. The A1 services may include enriched information services, such as providing data for model training of AI / ML models, such as predictions and / or data analysis.

[0068] The application 123 may provide O1 services that provide configuration management or performance management of entities managed by the O-RAN (e.g., near-RT RIC 124 and / or RAN nodes, such as O-CU 146, O-DU 148 (also referred to herein as "E2 nodes")). The O1 services may provide configuration management services to create, update, and / or delete configurations of entities managed by the O-RAN. For example, the configuration management services may include provisioning operations (e.g., for NSS and NF provisioning) to create a management object instance (MOI), obtain MOI attributes, modify MOI attributes, and / or delete MOI. The O1 services may also provide performance management services that monitor the status of elements or components in the entities managed by the O-RAN. For example, the non-RT RIC 122 may create, modify, or delete performance management jobs to receive performance metrics, or send heartbeat messages to monitor the status and / or availability of services of RAN nodes, or send trace messages to monitor link failures. The O1 service can also provide file management, for example, pushing files to RAN nodes (e.g., software updates, beamforming profiles, ML models, security certificates, etc.).

[0069] Application 123 may provide O2 services that provide infrastructure management and / or network function deployment of resources in O-RAN cloud 150 (also referred to herein as "O-Cloud 150"). O2 services may provide discovery and management of O-Cloud resources; horizontal contraction, horizontal expansion of clouds / deployments (e.g., deploying resources with more or fewer processors); FCAPS of clouds / deployments, software management of cloud platforms / deployments; and creation / deletion of deployments and associated allocated O-Cloud resources.

[0070] Application 123 may provide service management and exposure (SME) services, data management and exposure (DME) services, and / or other services. SME services may provide services that enable services provided through the internal interface (R1 interface 154) of the non-RT RIC 122 and their exposure and extensibility through services including bootstrapping, service registration / deregistration or updates to service registration, service discovery or notification, heartbeat, authentication, authorization, etc. Data management and exposure (DME) services may include services that manage data between applications 123 and their exposure. For example, application 123 may have different functions, such as application 123A configured to collect and analyze data, application 123B configured to generate an ML model based on the analysis results, and application 123N configured to use an ML model for prediction or inference and / or generate control of a RAN node based on the prediction or inference. DME services may manage data shared between applications 123, such as the collection of data, the processing of data, and / or the advertisement of data.

[0071] The non-RT RIC 122 may include one or more managers to handle A1, O1, O2, SME, DME services and other services. For example, the non-RT RIC 122 may include a policy manager 158, an O1 service manager 160, an O2 service manager 162, a service manager 163, and a data manager 155. The non-RT RIC 122 may include other managers configured to manage the installation and deployment of the application 123, such as an application manager and an application loader.

[0072] The policy manager 158 is configured to control the deployment of policies (e.g., A1 services). For example, in response to receiving a request for an A1 service from an application 123 via the R1 interface 154, the R1 interface 154 sends the request to the policy manager 158 via the message bus 151. The policy manager 158 may process the A1 service and may send the A1 service to the A1 termination point 156 via the message bus 151, which provides the A1 service to the near-RT RIC 124 via the A1 interface 164. In some examples, the A1 interface may implement the A1AP application protocol based on the O-RAN specification.

[0073] The O1 service manager 160 is configured to control the deployment of O1 services for monitoring the performance of the near-RT RIC 124 and / or RAN nodes (e.g., O-CU 146, O-DU 148). For example, in response to receiving a request for an O1 service to monitor the performance of the near-RT RIC 124 from the application 123 via the R1 interface 154, the R1 interface 154 sends the request to the O1 service manager 160 via the message bus 151. The O1 service manager 160 may process the O1 service and may send the O1 service to the O1 termination point 168, which provides the O1 service to the near-RT RIC 124 via the O1 interface 166. In some examples, the O1 interface may implement a REST / HTTPS API and / or NETCONF.

[0074] The O1 service manager 160 is additionally or alternatively configured to control the deployment of O1 services for configuration of the near-RT RIC 124 and / or the RAN node. For example, in response to receiving a request for O1 services for configuration of the near-RT RIC 124 from the application 123 via the R1 interface 154, the R1 interface 154 sends the request to the O1 service manager 160. The O1 service manager 160 may process the O1 services and may send the O1 services to the O1 termination point 168, which provides the O1 services to the near-RT RIC 124 via the O1 interface 166.

[0075] The O2 service manager 162 may be configured to control the deployment of O2 services to monitor the performance of resources of the O-Cloud 150. For example, in response to receiving a request for an O2 service to monitor the performance of resources within the O-Cloud 150 via the R1 interface 154, the R1 interface 154 sends the request to the O2 service manager 162. The O2 service manager 162 may process the O2 service and may send the O2 service to the O2 termination point 169, which provides the O2 service to the resources of the O-Cloud 150 via the O2 interface 167.

[0076] The O2 service manager 162 may additionally or alternatively be configured to control the deployment of O2 services for resource configuration of the O-Cloud 150. For example, in response to receiving a request for an O2 service for configuring resources within the O-Cloud 150 from the application 123 via the R1 interface 154, the R1 interface 154 sends the request to the O2 service manager 162. The O2 service manager 162 may process the O2 service and may send the O2 service to the O2 termination point 169, which provides the O2 service to the resources of the O-Cloud 150 via the O2 interface 167.

[0077] In some examples, the R1 interface 154 also exposes the application 123 to SME services, DME services, and / or other services. For example, in response to receiving a request for SME services from the application 123 via the R1 interface 154, the R1 interface 154 sends the request to the service manager 163. The service manager 163 can process the SME services (e.g., registration / update services) and can send the SME services to the R1 termination point 152, which provides the SME services to the application 123 via the R1 interface 154 (e.g., sends a response to the application regarding service registration, update, or discovery). Similarly, in response to receiving a request for DME services from the application 123 via the R1 interface 154, the R1 interface 154 sends the request to the data manager 155. The data manager 155 can process the DME services and can send the DME services to the R1 termination point 152, which provides the DME services to the application 123 via the R1 interface 154 (e.g., sends data from an application configured as a data producer to an application configured as a data consumer).

[0078] The R1 interface 154 may also expose the application 123 to slice subnet management services, e.g., the RAN NSSMF interface to retrieve slice service level agreements (SLAs) and slice topologies, and / or slice management, SLA and slice performance management notifications to the application 123.

[0079] According to the technology of the present disclosure, the RAN sharing detector 103 of the SMO 112 can automatically detect Figures 1A to 1C The RAN sharing detector 103 detects the presence of RAN sharing within the mobile network 120 and determines the type of RAN sharing used within the mobile network 120. In one example, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109. In some examples, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109 from the NSMF of the mobile core network 105. Figure 1A The message includes a configuration file, and the configuration file includes a first PLMN identifier and a first operating frequency band value.

[0080] The RAN sharing detector 103 analyzes one or more fields in one or more data structures of the message to infer that the RAN 109 is being shared and / or the type of RAN sharing. For example, the RAN sharing detector 103 determines that another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109. Based on the presence of the first PLMN identifier and the second PLMN identifier within the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is used within the mobile network 120. This is because the presence of a RAN subnet provisioned with two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are using resources of the RAN 109.

[0081] In the first scenario, the RAN sharing detector 103 determines that the second RAN slice subnet with the second PLMN identifier provisioned within the RAN 109 has been provisioned with the same first operating frequency band value as specified in the configuration file of the message. Because the first PLMN identifier and the second PLMN identifier are configured to use the same first operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MOCN. This is because the presence of two different PLMN identifiers indicating the use of the same operating frequency band indicates that the two network operators corresponding to the two PLMN identifiers share the same operating frequency band within the RAN 109, thereby indicating that the RAN 109 uses MOCN.

[0082] In the second scenario, the RAN sharing detector 103 determines that there are no other RAN slice subnets that have been provisioned with the same first operating frequency band value and have a PLMN identifier different from the first PLMN identifier within the RAN 109. Therefore, since the RAN slice subnets are provisioned with different PLMN identifiers (RAN 109 is shared), but these RAN slice subnets do not share an operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MORAN. This is because the presence of two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are sharing the RAN 109, but since each network operator has non-overlapping operating frequency bands, there is no sharing of the operating frequency band, thereby indicating that the RAN 109 uses MORAN.

[0083] The RAN sharing detector 103 may manage network slices in the RAN based on the determined RAN sharing type. For example, the RAN sharing detector 103 may configure one or more network devices (e.g., RUs, DUs, and CUs of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type. The RAN sharing detector 103 selects a profile or template for provisioning a network slice or slice subnet based at least in part on the determined RAN sharing type and the profile. In addition, the RAN sharing detector 103 may apply one or more network policies or SLA policies to provision a slice subnet based at least in part on the determined RAN sharing type. In addition, the RAN sharing detector 103 may allocate resources to the slice subnet based at least in part on the determined RAN sharing type.

[0084] In a first example, the RAN sharing detector 103 configures one or more network devices (e.g., RU, DU, and CU of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MORAN. In this example, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with a first PLMN identifier. Specifically, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of the one or more first subscriber devices 104 via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In addition, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more second subscriber devices associated with a second PLMN identifier via a second operating frequency band different from the first operating frequency band. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the same base station and the same site.

[0085] In a second example, the RAN sharing detector 103 configures one or more network devices (e.g., RU, DU, and CU of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MOCN. In this example, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with the first PLMN identifier and network traffic of one or more second subscriber devices associated with the second PLMN identifier via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the first operating frequency band, the same base station, and the same site.

[0086] Figure 1C It is shown Figure 1A A block diagram of a near-RT RIC is provided for further example details. Figure 1C In the example shown, the near-RT RIC 124 includes a shared data layer 188, a database 189, one or more AI / ML models 190, a manager 191, an xApp subscription manager 192, a messaging infrastructure 193, conflict mitigation 194, security 195, an xApp repository 196, a message bus 187, API enablement 197, and open interfaces, such as, O1 termination point 185, A1 termination point 186, Y1 termination point 198, and E2 termination point 199.

[0087] The near-RT RIC 124 may provide near real-time (e.g., millisecond-level) control and optimization of RAN elements and resources (e.g., O-CU 146 and / or O-DU 148) via fine-grained data collection and actions performed through the E2 interface 165. For example, the near-RT RIC 124 may host one or more applications 125 (e.g., Figure 1C xApps 125A-125N, collectively "xApp 125"), which provide near real-time control of RAN elements and their resources.

[0088] The near-RT RIC 124 can be deployed as a highly scalable, microservices-based containerized architecture. The near-RT RIC 124 can load one or more applications, such as an application 125 (e.g., xApp 125) that manages near real-time events within the near-RT RIC 124. The application 125 can utilize the functionality exposed via the near-RT RIC framework of the near-RT RIC 124. The near-RT RIC 124 can implement policies received from the application 123 of the non-RT RIC 122, and can provide policy feedback to the non-RT RIC 122. Although shown as being within the near-RT RIC 124, any one or more of the applications 125 can be executed by a third party independent of the near-RT RIC 124.

[0089] The shared data layer 188 and database 189 enable the near-RT RIC 124 to maintain and expose RAN / UE information and other information required to support specific use cases. In some examples, the database 189 maintains a list of UEs and associated data and performs tracking and association of UE identities associated with connected E2 nodes. In some examples, the database 189 maintains configuration and near real-time information related to connected E2 nodes and mappings between them. This information can be generated and accessed by the near-RT RIC 124 or authorized xApp 125. The shared data layer 188 provides SDL services for xApp 125, which can be used to subscribe to database notifications and read, write, and modify information stored on the database 189. The services provided by the shared data layer 188 can be used to expose use case specific information.

[0090] Manager 191 includes OAM management, which provides fault, configuration, billing, performance, file, security and other management plane services. Manager 191 of near-RT RIC 124 provides several capabilities to support OAM management services. For example, manager 191 provides fault management, including near-RT RIC fault monitoring MnS through the O1 interface. In addition, manager 191 provides configuration management, including near-RT RIC provisioning MnS through the O1 interface.

[0091] In some examples, manager 191 performs logging, tracing and metric collection functions. Logging is to capture information required for operating, troubleshooting and reporting the performance of near-RT RIC 124 and its components. Users and systems can directly view and use log records, index them and load them into data storage, and use them to calculate metrics and generate reports. Near-RT RIC components record events according to a common logging format. Different logs (e.g., audit logs, metric logs, error logs, and debug logs) can be generated. The tracking mechanism is used to monitor transactions or workflows. The example subscription workflow can be divided into two tracks, i.e., subscription request tracking, followed by response tracking. When the workflow traverses a specific near-RT RIC component, each track can be analyzed to understand the time delay. Collect and report metrics specific to the performance and fault management of each xApp logic, and collect and publish other internal functions for authorized consumers (e.g., SMO).

[0092] The near-RT RIC 124 includes an xApp subscription manager 192. The xApp subscription manager 192 enables the near-RT RIC 124 to process subscription requests from different xApps 125 for, for example, E2-related data, and to provide unified data distribution for these data to the xApps 125. In some examples, the xApp subscription manager 192 manages subscriptions from xApps to E2 nodes. The xApp subscription manager 192 can implement authorization of policies that control access messages to xApps 125. In addition, the xApp subscription manager 192 enables the same subscriptions from different xApps 125 to be merged into a single subscription toward the E2 node.

[0093] Conflict mitigation 194 enables near-RT RIC 124 to detect and resolve potentially overlapping or conflicting requests from multiple xApps 125. In the context of near-RT RIC 124, conflict mitigation 194 resolves conflicting interactions between different xApps 125. An application may change one or more parameters with the goal of optimizing a particular metric. Conflict mitigation 194 can reduce, mitigate, or avoid situations where xApps 125 select or configure goals that result in conflicting actions.

[0094] The messaging infrastructure 193 enables the near-RT RIC 124 to perform low-latency messaging between endpoints within the near-RT RIC. The messaging infrastructure 193 supports registration of endpoints, wherein an endpoint registers itself with the messaging infrastructure 193. The messaging infrastructure 193 also supports discovery of endpoints, wherein an endpoint is initially discovered by the messaging infrastructure 193 and registered with the messaging infrastructure 193. The messaging infrastructure 193 also supports deletion of endpoints, wherein an endpoint is deleted once it is no longer used. The messaging infrastructure 193 may provide an API for sending messages to the messaging infrastructure 193 and an API for receiving messages from the messaging infrastructure 193. The messaging infrastructure 193 supports a variety of messaging modes, such as a point-to-point mode (e.g., message exchange between endpoints), a publish / subscribe mode (e.g., real-time data dispatch from an E2 termination point 199 to a multi-subscriber xApp 125). The messaging infrastructure 193 provides message routing, i.e., messages can be dispatched to different endpoints based on message routing information. The messaging infrastructure 193 supports message robustness to avoid data loss during messaging infrastructure outages / restarts, or to release resources from the messaging infrastructure once messages become obsolete.

[0095] The near-RT RIC 124 includes security 195. Security 195 prevents malicious xApps 125 from abusing radio network information (eg, exporting to unauthorized external systems) and / or control capabilities over RAN functions.

[0096] The near-RT RIC 124 includes termination points for various interfaces, including an E2 termination point 199, an A1 termination point 186, an O1 termination point 185, and a Y1 termination point 198. The E2 termination point 199 is capable of terminating an E2 interface. The E2 termination point 199 can terminate the SCTP connection from each E2 node. The E2 termination point 199 can also route messages from the xApp 125 to the E2 node via the SCTP connection. The E2 termination point 199 can also perform sufficient decoding of the payload of the incoming ASN.1 message to determine the message type. In some examples, the E2 termination point 199 processes incoming E2 messages associated with the E2 connection and receives and responds to E2 establishment requests from the E2 node. In addition, the E2 termination point 199 can notify the xApp 125 of a list of RAN functions supported by the E2 node based on information derived from the E2 establishment and RIC service update process, and can notify the newly connected E2 node of a list of accepted functions.

[0097] The A1 termination point 186 can terminate the A1 interface. The A1 termination point 186 provides a common API through which the near-RT RIC 124 can receive and send messages via the A1 interface. These messages include, for example, A1 policies and enrichment information received from the non-RT RIC 122, or A1 policy feedback sent to the non-RT RIC 122. The A1 termination point 186 can also send the A1 policy set or updated by the non-RT RIC 122 to the appropriate xApp 125 based on the list of candidate xApps 125 provided by the xApp repository 196.

[0098] The O1 termination point 185 is capable of terminating the O1 interface. The near-RT RIC 124 communicates with the SMO 112 via the O1 interface 166 and exposes O1 related management services from the near-RT RIC 124. For O1 management services (MnS), the near-RT RIC 124 is the MnS producer and the SMO 112 is the MnS consumer. The near-RT RIC 124 exposes provisioning management services from the near-RT RIC 124 to the O1 provisioning management service consumer, converts the O1 management services into internal APIs of the near-RT RIC 124, exposes FM services to report faults and events from the near-RT RIC 124 to the O1 FM service consumer, exposes PM services to report batch and real-time PM data from the near-RT RIC 124 to the O1 PM service consumer, exposes file management services to download ML files, software files, etc. and upload log / trace files to / from the file MnS consumer, and exposes communication monitoring services to the O1 communication monitoring service consumer.

[0099] The Y1 termination point 198 is capable of terminating the Y1 interface. The Y1 termination point 198 provides support for exposing RAN analysis information from the near-RT RIC 124 to the Y1 consumer.

[0100] The near-RT RIC 124 may include one or more managers to handle O1, A1, Y1, and E2 services, among other services. The near-RT RIC 124 may include other managers configured to manage the installation and deployment of applications 125, such as an application manager and an application loader.

[0101] API enablement 197 provides an API for the Near RT RIC 124. The Near RT RIC API can be classified based on the interaction with the Near RT RIC 124, and can be related to E2-related services, A1-related services, management-related services, and SDL services. This function supports the registration, discovery, and consumption of Near RT RIC APIs within the Near RT RIC. Specifically, the services provided by API enablement 197 include a repository and registration service for the Near RT RIC API, a service that allows the discovery of registered Near RT RIC APIs, a service for authenticating xApp 125 to use the Near RT RIC API, a service for enabling general subscriptions and event notifications, and a function to avoid compatibility conflicts between xApp 125 and the services they access. In some examples, API enablement 197 provides API enablement services that are accessed by xApp 125 via one or more enabling APIs.

[0102] The AI / ML model 190 enables the near-RT RIC 124 to implement data pipelining, model management, training, and inference, which constitutes complete AI / ML workflow support for xApp 125 to implement AI / ML algorithms. Depending on its design, xApp 125 may not use, partially use, or use all of this functionality. In some examples, the AI / ML model 190 includes a data pipeline that performs data ingestion and preparation for xApp 125. The AI / ML model 190 can provide AI / ML-based xApp 125 with general and use case-independent capabilities, which may be useful for multiple use cases. The input data for training can come from a space specific to the xApp (e.g., a dedicated space in a database).

[0103] The xApp repository 196 maintains a list of candidate xApps to the A1 termination point 186 for sending A1 policies or policy updates to appropriate xApps 125 based on policy type and operator policy. In addition, the xApp repository 196 maintains the policy types supported in the near-RT RIC 124. The supported policy types are based on the registered xApps 125 and the policy types supported by the operator policy. In addition, the xApp repository 196 performs xApp access control on the requested A1-EI type based on the operator policy.

[0104] According to the technology of the present disclosure, the RAN sharing detector 103 of the SMO 112 can automatically detect Figures 1A to 1C The RAN sharing detector 103 detects the presence of RAN sharing within the mobile network 120 and determines the type of RAN sharing used within the mobile network 120. In one example, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109. In some examples, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109 from the NSMF of the mobile core network 105. Figure 1A The message includes a configuration file, and the configuration file includes a first PLMN identifier and a first operating frequency band value.

[0105] The RAN sharing detector 103 analyzes one or more fields in one or more data structures of the message to infer that the RAN 109 is being shared and / or the type of RAN sharing. For example, the RAN sharing detector 103 determines that another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109. Based on the presence of the first PLMN identifier and the second PLMN identifier within the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is used within the mobile network 120. This is because the presence of a RAN subnet provisioned with two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are using resources of the RAN 109.

[0106] In the first scenario, the RAN sharing detector 103 determines that the second RAN slice subnet with the second PLMN identifier provisioned within the RAN 109 has been provisioned with the same first operating frequency band value as specified in the configuration file of the message. Because the first PLMN identifier and the second PLMN identifier are configured to use the same first operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MOCN. This is because the presence of two different PLMN identifiers indicating the use of the same operating frequency band indicates that the two network operators corresponding to the two PLMN identifiers share the same operating frequency band within the RAN 109, thereby indicating that the RAN 109 uses MOCN.

[0107] In the second scenario, the RAN sharing detector 103 determines that there are no other RAN slice subnets that have been provisioned with the same first operating frequency band value and have a PLMN identifier different from the first PLMN identifier within the RAN 109. Therefore, since the RAN slice subnets are provisioned with different PLMN identifiers (RAN 109 is shared), but these RAN slice subnets do not share an operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MORAN. This is because the presence of two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are sharing the RAN 109, but since each network operator has non-overlapping operating frequency bands, there is no sharing of the operating frequency band, thereby indicating that the RAN 109 uses MORAN.

[0108] The RAN sharing detector 103 may manage network slices in the RAN based on the determined RAN sharing type. For example, the RAN sharing detector 103 may configure one or more network devices (e.g., RUs, DUs, and CUs of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type. The RAN sharing detector 103 selects a profile or template for provisioning a network slice or slice subnet based at least in part on the determined RAN sharing type and the profile. In addition, the RAN sharing detector 103 may apply one or more network policies or SLA policies to provision a slice subnet based at least in part on the determined RAN sharing type. In addition, the RAN sharing detector 103 may allocate resources to the slice subnet based at least in part on the determined RAN sharing type.

[0109] In a first example, the RAN sharing detector 103 configures one or more network devices (e.g., RU, DU, and CU of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MORAN. In this example, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with a first PLMN identifier. Specifically, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of the one or more first subscriber devices 104 via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In addition, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more second subscriber devices associated with a second PLMN identifier via a second operating frequency band different from the first operating frequency band. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the same base station and the same site.

[0110] In a second example, the RAN sharing detector 103 configures one or more network devices (e.g., RU, DU, and CU of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MOCN. In this example, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with the first PLMN identifier and network traffic of one or more second subscriber devices associated with the second PLMN identifier via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the first operating frequency band, the same base station, and the same site.

[0111] Figures 1A to 1C The foregoing examples depict example implementations of an O-RAN network system using the techniques disclosed herein. However, other network infrastructures (eg, 3GPP) may also be used to implement the techniques disclosed herein.

[0112] Figure 1D is another block diagram illustrating an example network system configured to detect the presence of mobile network sharing in accordance with one or more techniques of this disclosure. Figure 1E It is shown Figure 1D A block diagram of further example details of the service management and orchestration system 182 is provided. More specifically, according to one or more techniques of the present disclosure, Figure 1D to Figure 1E The example of FIG. 1 depicts an example mobile network system 180 that implements a 3GPP mobile network infrastructure to detect the presence of mobile network sharing. The SMO system 182 can provide service management and orchestration to manage and / or monitor various aspects of the RAN and / or 5G core. The SMO system 182 can be used with Figures 1A to 1C SMO 112 operates in a substantially similar manner, except that SMO 182 may operate in accordance with 3GPP rather than O-RAN.

[0113] For example, about Figure 1D to Figure 1E , the RAN sharing detector 103 of the SMO 112 receives a message for implementing network slicing of the RAN 109. In some examples, the RAN sharing detector 103 receives a message for the RAN 109 from the NSMF of the mobile core network 105. The message includes a configuration file, and the configuration file includes a first PLMN identifier and a first operating frequency band value.

[0114] The RAN sharing detector 103 determines whether another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109. For example, the RAN sharing detector 103 analyzes one or more fields in one or more data structures of the message to determine whether another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109. Based on the presence of only the first PLMN identifier and no second PLMN identifier in the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is not used in the mobile network 120. This is because there is no RAN subnet provisioned with two different PLMN identifiers within the RAN 109, which indicates that only a single network operator corresponding to the first PLMN identifier is using the resources of the RAN 109.

[0115] Based on the presence of the first PLMN identifier and the second PLMN identifier within the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is used within the mobile network 120. This is because the presence of a RAN subnet provisioned with two different PLMN identifiers within the RAN 109 indicates that both network operators corresponding to the two PLMN identifiers are using the resources of the RAN 109.

[0116] The RAN sharing detector 103 determines whether another RAN slice subnet is provisioned within the RAN 109, the other RAN slice subnet having a different PLMN identifier and having the same first operating frequency band value as specified in the configuration file of the message.

[0117] In response to determining that a second RAN slice subnet having a second PLMN identifier and having the same first operating frequency band value as specified in the configuration file of the message is provisioned within the RAN 109, the RAN sharing detector 103 determines that the RAN sharing type is MOCN. This is because the presence of two different PLMN identifiers indicating the use of the same operating frequency band indicates that the two network operators corresponding to the two PLMN identifiers share the same operating frequency band within the RAN 109, thereby indicating that the RAN 109 uses MOCN.

[0118] In response to determining that another RAN slice subnet having a different PLMN identifier and having the same first operating frequency band value as specified in the configuration file of the message is not provisioned within the RAN 109, the RAN sharing detector 103 determines whether there is no other RAN slice subnet within the RAN 109, which has a PLMN identifier different from the first PLMN identifier and is provisioned with the same first operating frequency band value.

[0119] In response to determining that there is no other RAN slice subnet within the RAN 109 that has a PLMN identifier different from the first PLMN identifier and is provisioned with the same first operating frequency band value within the RAN 109, the RAN sharing detector 103 determines that the RAN sharing type is MORAN. This is because the presence of two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are sharing the RAN 109, but because each network operator has non-overlapping operating frequency bands, there is no sharing of the operating frequency bands, indicating that the RAN 109 uses MORAN. Otherwise, the RAN sharing detector 103 determines that the RAN 109 is using some other type of RAN sharing.

[0120] The RAN sharing detector 103 manages network slices in the RAN 109 based on the determined RAN sharing type. For example, the RAN sharing detector 103 may configure one or more network devices of the RAN 109 to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type. In some examples, the RAN sharing detector 103 provisions at least one of a RAN slice subnet within the RAN 109 and a core network slice subnet within the core network 105 according to a profile of the message and the determined RAN sharing type.

[0121] Figure 2 is a block diagram illustrating a set of examples of RAN sharing. As described herein, RAN sharing refers to the sharing of infrastructure ("key assets") of the RAN, such as the core network, radio controllers, backhaul networks, base stations, sites, and / or spectrum between two or more network operators of the RAN. (Such sharing can be for many instances of each type of infrastructure described above.) Methods of RAN sharing can be divided into two categories, namely passive and active. Passive RAN sharing techniques include site sharing and shared backhaul networks. Active RAN sharing techniques include MORAN, MOCN, and core network (CN) sharing. In the case of active RAN sharing, the technology of the present disclosure automatically detects slices for RAN sharing scenarios shared by MORAN, MOCN, and CN.

[0122] In MORAN, the two network operations use different core networks and different spectrum, but share radio controllers, backhaul networks, base stations, and sites. In MOCN, the two network operations use different core networks, but share radio controllers, backhaul networks, base stations, sites, and spectrum. The main difference between MORAN and MOCN is that in MORAN, the network operators use different spectrum, while in MOCN, the network operators share a common spectrum. In CN sharing, the network operations share all the infrastructure of RAN, including the core network and spectrum.

[0123] Figure 3 is a block diagram showing another set of examples of RAN sharing. In MORAN, operator A and operator B have different core networks A and B, respectively. Operator A and operator B share gNBs but use separate baseband spectrum. In MOCN, operator A and operator B have different core networks A and B, respectively. Operator A and operator B share gNBs and shared spectrum.

[0124] Figure 4 is a diagram illustrating an example computing system 400 in detail according to the techniques of this disclosure. Figure 2 In this example, computing system 400 may implement, for example, SMO 112 and / or non-RT RIC, e.g., Figures 1A to 1C Non-RT RIC 122.

[0125] The computing system 400 includes the processing circuit 220, one or more input devices 422, one or more output devices 423, one or more communication units 419, and one or more storage devices 421. In some examples, the computing system 400 is a cloud computing system, a server farm, and / or a server cluster (or a portion thereof) that provides services to client devices and other devices or systems. In other examples, the computing system 400 can be implemented by one or more virtualized computing instances (e.g., virtual machines, containers) of a data center, a cloud computing system, a server farm, and / or a server cluster.

[0126] One or more devices, modules, storage areas, or other components of computing system 400 may be interconnected to enable communication between the components (physically, communicatively, and / or operationally). In some examples, such connection may be by a communication channel, a system bus (e.g., Figure 1B message bus 151), network connection, inter-process communication data structure or any other method for transferring data.

[0127] The processing circuit 220 of the computing system 400 may implement functions and / or execute instructions associated with the SMO and / or non-RT RIC or associated with one or more modules shown and / or described herein, including the application 488, the policy manager 158, the O1 service manager 160, the O2 service manager 162, the service manager 163, and the data manager 155. The processing circuit 220 may be a processing circuit that performs operations according to one or more aspects of the present disclosure, may be a part of a processing circuit, and / or may include a processing circuit. Examples of the processing circuit 220 include a microprocessor, an application processor, a display controller, an auxiliary processor, one or more sensor hubs, and any other hardware configured to function as a processor, a processing unit, or a processing device. The computing system 400 may use the processing circuit 220 to perform operations according to one or more aspects of the present disclosure using software, hardware, firmware, or a mixture of hardware, software, and firmware resident in and / or executed at the computing system 400. Any one or more of the application 488, policy manager 158, O1 service manager 160, O2 service manager 162, service manager 163, and data manager 155 may be hosted by a cloud provider or other third party.

[0128] One or more communication units 419 of the computing system 400 can communicate with devices outside the computing system 400 by sending and / or receiving data, and can operate as both an input device and an output device in some aspects. In some examples, the communication unit 419 can communicate with other devices through a network. In other examples, the communication unit 419 can send and / or receive radio signals on a radio network (e.g., a cellular radio network). In other examples, the communication unit 419 of the computing system 400 can send and / or receive satellite signals on a satellite network (e.g., a global positioning system (GPS) network). Examples of the communication unit 419 include a network interface card (e.g., an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device capable of sending and / or receiving information. Other examples of the communication unit 419 can include devices capable of communicating via Bluetooth®, GPS, NFC, ZigBee, and cellular networks (e.g., 3G, 4G, 5G), as well as Wi-Fi® radios in mobile devices and universal serial bus (USB) controllers, etc. Such communications may adhere to, implement or comply with appropriate protocols, including Transmission Control Protocol / Internet Protocol (TCP / IP), Ethernet, Bluetooth, NFC or other technologies or protocols.

[0129] The one or more input devices 422 may represent any input device of the computing system 400 not described separately herein. The one or more input devices 422 may generate, receive, and / or process input from any type of device capable of detecting input from a person or a machine. For example, the one or more input devices 422 may generate, receive, and / or process input in the form of electrical, physical, audio, image, and / or visual input (e.g., peripherals, keyboards, microphones, cameras).

[0130] One or more output devices 423 may represent any output device of computing system 400 not described separately herein. One or more output devices 423 may generate, receive, and / or process input from any type of device capable of detecting input from a person or machine. For example, one or more output devices 423 may generate, receive, and / or process output in the form of electrical and / or physical output (e.g., peripheral devices, actuators). In some examples, output device 423 provides a UI 486 that an administrator may utilize to interact with computing system 400.

[0131] One or more storage devices 421 within the computing system 400 may store information for processing during operation of the computing system 400. The storage device 421 may store program instructions and / or data associated with one or more modules described according to one or more aspects of the present disclosure. The processing circuit 220 and the one or more storage devices 421 may provide an operating environment or platform for these modules, which may be implemented as software, but may include any combination of hardware, firmware, and software in some examples. The processing circuit 220 may execute instructions, and the one or more storage devices 421 may store instructions and / or data of one or more modules. The combination of the processing circuit 220 and the storage device 421 may retrieve, store, and / or execute instructions and / or data of one or more applications, modules, or software. The processing circuit 220 and / or the storage device 421 may also be operably coupled to one or more other software and / or hardware components, including but not limited to one or more components of the computing system 400 and / or one or more devices or systems shown as being connected to the computing system 400.

[0132] In some examples, one or more storage devices 421 are temporary memories, indicating that the primary purpose of one or more storage devices is not long-term storage. Storage devices 421 of computing system 400 may be configured as volatile memory for short-term storage of information, so that if deactivated, the stored content is not retained. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage device 421 also includes one or more computer-readable storage media. Storage device 421 may be configured to store a larger amount of information than volatile memory. Storage device 421 may also be configured as non-volatile storage space for long-term storage of information and retaining information after activation / deactivation cycles. Examples of non-volatile memory include magnetic hard disks, optical disks, flash memory, or various forms of electrically programmable memory (EPROM) or electrically erasable programmable (EEPROM) memory.

[0133] Applications 488 may include SMO 112 and rApp 123A. SMO 112 provides orchestration, control management, and automation aspects of RAN 109 (e.g., network slicing, management, and orchestration of O-Cloud). In addition, SMO 112 may control Figures 1A to 1C Non-RT RIC 122 and Figures 1A to 1C Aspects of the near RT RIC 124.

[0134] As described above, rApp 123 can manage non-real-time events within non-RT RIC 122, such as applications that do not require a response time of less than one second. rApp 123 can utilize functionality exposed via the non-RT RIC framework of computing device 700. rApp 123 can be used to control and manage RAN elements and resources, such as resources in a near-RT RIC, RAN node, and / or O-RAN cloud. rApp 123 can provide one or more services that are performed using interfaces (e.g., A1 interface, O1 interface, O2 interface, etc.) of computing system 400. Examples of rApp 123 can include, for example, services such as policy 1 for near-RT RIC, configuration instructions 434 for elements managed by O-RAN, performance jobs 436 for elements managed by O-RAN, services 438 for managing services and / or data, and the like.

[0135] Computing system 400 may include one or more modules or units configured to execute one or more services or functions of application 488, such as policy manager 158, O1 service manager 160, O2 service manager 162, service manager 163, and data manager 155 as described above.

[0136] For example, the policy manager 158 is configured to control the deployment of policies (eg, the A1 service). For example, the policy manager 158 may receive a request for the A1 service from the application 123 (eg, via Figure 1B R1 interface 154), handles A1 services from application 123, and uses A1 interface (e.g., Figure 1B The A1 interface 164) performs the A1 service of the near RT RIC. In some examples, the A1 interface can implement the A1AP application protocol based on the 3GPP framework.

[0137] The O1 service manager 160 is configured to control the deployment of O1 services to monitor elements managed by O-RAN (e.g. Figure 1B For example, the O1 service manager 160 may receive a request for an O1 service for monitoring the performance of the near-RT RIC from the application 123 (eg, via Figure 1B R1 interface 154), handles O1 services, and uses O1 interfaces (e.g., Figure 1B The O1 interface 166 of the O-RAN performs O1 services for elements managed by the O-RAN. In some examples, the O1 interface can implement a REST / HTTPS API and / or NETCONF.

[0138] The O1 service manager 160 is additionally or alternatively configured to control the deployment of O1 services for configuration of the near RT RIC 124 and / or RAN nodes. For example, the O1 service manager 160 may be configured from the application 123 (e.g., via Figure 1B The R1 interface 154) receives requests for O1 services for configuration of elements managed by the O-RAN, processes the O1 services, and may use the O1 interface (e.g., Figure 1B The O1 interface 166) performs O1 services for elements managed by the O-RAN.

[0139] The O2 service manager 162 may be configured to control the deployment of O2 services for monitoring the performance of resources of the O-RAN cloud. For example, the O2 service manager 162 may receive a request for an O2 service for monitoring the performance of resources in the O-RAN cloud (e.g., via Figure 1B R1 interface 154), handles O2 services, and can use O2 interfaces (e.g., Figure 1B The O2 interface 167) performs O2 services for resources of the O-RAN cloud.

[0140] The O2 service manager 162 may additionally or alternatively be configured to control the deployment of O2 services for configuring resources of the O-RAN cloud. For example, the O2 service manager 162 may be configured to control the deployment of O2 services from the application 123 (e.g., via Figure 1B The R1 interface 154) receives a request for an O2 service for configuring resources in the O-RAN cloud, processes the O2 service, and may use the O2 interface (e.g., Figure 1B The O2 interface 167) performs O2 services for resources of the O-RAN cloud.

[0141] The service manager 163 is configured to manage services, such as service registration, update of service registration, service discovery, etc. For example, the service manager 163 may receive a request for an SME service from the application 123 (eg, via Figure 1B R1 interface 154), performs SME services (e.g., registration / update services) for one or more applications 123, and uses the R1 interface (e.g., Figure 1B The R1 interface 154 of the embodiment sends a response to one or more applications 123.

[0142] The data manager 155 is configured to manage the data of the application 123. For example, the data manager 155 may receive a request for a DME service from the application 123 (eg, via Figure 1B R1 interface 154), performs DME services for one or more applications 123 (e.g., sends data from an application configured as a data producer to an application configured as a data consumer), and uses the R1 interface (e.g., Figure 1B The R1 interface 154 of the embodiment sends a response to one or more applications 123.

[0143] According to the technology of the present disclosure, the RAN sharing detector 103 of the SMO 112 can automatically detect Figures 1A to 1C The RAN sharing detector 103 detects the presence of RAN sharing within the mobile network 120 and determines the type of RAN sharing used within the mobile network 120. In one example, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109. In some examples, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109 from the NSMF of the mobile core network 105. Figure 1A The message includes a configuration file, and the configuration file includes a first PLMN identifier and a first operating frequency band value.

[0144] The RAN sharing detector 103 analyzes one or more fields in one or more data structures of the message to infer that the RAN 109 is being shared and / or the type of RAN sharing. For example, the RAN sharing detector 103 determines that another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109. Based on the presence of the first PLMN identifier and the second PLMN identifier within the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is used within the mobile network 120. This is because the presence of a RAN subnet provisioned with two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are using resources of the RAN 109.

[0145] In the first scenario, the RAN sharing detector 103 determines that the second RAN slice subnet with the second PLMN identifier provisioned within the RAN has been provisioned with the same first operating frequency band value as specified in the configuration file of the message. Because the first PLMN identifier and the second PLMN identifier are configured to use the same first operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MOCN. This is because the presence of two different PLMN identifiers indicating the use of the same operating frequency band indicates that the two network operators corresponding to the two PLMN identifiers share the same operating frequency band within the RAN 109, thereby indicating that the RAN 109 uses MOCN.

[0146] In the second scenario, the RAN sharing detector 103 determines that other RAN slice subnets having PLMN identifiers different from the first PLMN identifier within the RAN 109 are not provisioned with the same first operating frequency band value. Therefore, since the RAN slice subnets are provisioned with different PLMN identifiers (RAN 109 is shared), but such RAN slice subnets do not share an operating frequency band, the RAN sharing detector 103 determines that the RAN sharing type is MORAN. This is because the presence of two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are sharing the RAN 109, but since each network operator has non-overlapping operating frequency bands, there is no sharing of the operating frequency band, thereby indicating that the RAN 109 uses MORAN.

[0147] The RAN sharing detector 103 may manage network slices in the RAN based on the determined RAN sharing type. The RAN sharing detector 103 may configure one or more network devices (e.g., RUs, DUs, and CUs of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type. The RAN sharing detector 103 selects a profile or template for provisioning a network slice or slice subnet based at least in part on the determined RAN sharing type and the profile. In addition, the RAN sharing detector 103 may apply one or more network policies or SLA policies to provision a slice subnet based at least in part on the determined RAN sharing type. In addition, the RAN sharing detector 103 may allocate resources to the slice subnet based at least in part on the determined RAN sharing type.

[0148] In a first example, the RAN sharing detector 103 configures one or more network devices (e.g., RUs, DUs, and CUs of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MORAN. In this example, the RAN sharing detector 103 configures the RUs, DUs, and CUs of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with a first PLMN identifier. Specifically, the RAN sharing detector 103 configures the RUs, DUs, and CUs of the RAN 109 to forward network traffic of the one or more first subscriber devices 104 via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In addition, the RAN sharing detector 103 configures the RUs, DUs, and CUs of the RAN 109 to forward network traffic of one or more second subscriber devices associated with a second PLMN identifier via a second operating frequency band different from the first operating frequency band. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the same base station and the same site.

[0149] In a second example, the RAN sharing detector 103 configures one or more network devices (e.g., RU, DU, and CU of the RAN 109) to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type MOCN. In this example, the RAN sharing detector 103 configures the RU, DU, and CU of the RAN 109 to forward network traffic of one or more first subscriber devices 104 associated with the first PLMN identifier and network traffic of one or more second subscriber devices associated with the second PLMN identifier via a first operating frequency band corresponding to a first operating frequency band value specified by a configuration file of the received message. In this example, the network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share the first operating frequency band, the same base station, and the same site.

[0150] In the first example of the technology of the present disclosure, Figure 4 The RAN sharing detector 103 implements Figure 1A or Figure 1D The RAN network slice subnet management function (NSSMF) of the mobile network 120 of the RAN is triggered. In this example, the NSMF triggers the RAN NSSMF to create (or modify) a network slice. There may be no field for RAN sharing in the message. However, according to the technology of the present disclosure, the RAN NSSMF can apply the following logic to automatically determine the existence of RAN sharing and the type of RAN sharing used.

[0151] The RAN NSSMF receives the 3GPP TS 28.541 "SliceProfile" structure from the NSMF. The RAN NSSMF checks the "plmnInfoList" field which is a list of "plmnInfo" and checks the "pLMNId" field of each "plmnInfo" structure for the presence of a new PLMN identifier. The PLMN identifier is used to identify the mobile network operator. If there is a new PLMN identifier that was not provisioned before, this may indicate that RAN sharing is used.

[0152] If a new PLMN is present, the RAN NSSMF checks the presence of the 3GPP TS 28.541 "RANSliceSubnetProfile" structure. The RAN NSSMF checks the "nrOperatingBands" structure, which indicates the carrier / frequency used for the slice. If there is no existing RAN slice subnet with another PLMN identifier and the same "nrOperatingBands", this may indicate that the same frequencies are not shared by two (or more) mobile network operators, indicating that MORAN is used. If there is an existing RAN slice subnet with another PLMN and the same "nrOperatingBands", this may indicate that the same frequencies are being shared by two (or more) mobile network operators, indicating that MOCN is used.

[0153] In a second example of the technology of the present disclosure, Figure 4 The RAN sharing detector 103 implements Figure 1A or Figure 1D The core network (CN) NSSMF of the mobile network 120. In this example, the NSMF triggers the CN NSSMF to create (or modify) a network slice. There may be no field for RAN sharing in this message. However, according to the technology of the present disclosure, the CN NSSMF can apply the following logic to automatically determine the existence of RAN sharing and the type of RAN sharing used.

[0154] The CN NSSMF receives the 3GPP TS 28.541 "SliceProfile" structure from the NSMF. The CN NSSMF checks the "plmnInfoList" field, which is a list of "plmnInfo", and checks the "pLMNId" field of each "plmnInfo" structure for the presence of a new PLMN identifier. The PLMN identifier is used to identify the mobile network operator. If there is a new PLMN identifier that was not provisioned before, this may indicate that RAN sharing is used.

[0155] If there is a new PLMN, the CN NSSMF checks the presence of the 3GPP TS 28.541 "CNSliceSubnetProfile" structure. The CN NSSMF checks the "nrOperatingBands" structure, which indicates the carrier / frequency used for the slice. If there is no existing RAN slice subnet with another PLMN identifier and the same "nrOperatingBands", this may indicate that the same frequencies are not shared by two (or more) mobile network operators, indicating that MORAN is used. If there is an existing RAN slice subnet with another PLMN and the same "nrOperatingBands", this may indicate that the same frequencies are being shared by two (or more) mobile network operators, indicating that MOCN is used.

[0156] In a second example of the technology of the present disclosure, Figure 4 The RAN sharing detector 103 implements Figure 1A or Figure 1D 120 of the mobile network 120. In this example, the CSMF triggers the NSMF to create (or modify) a network slice. There may be no field for RAN sharing in the message. However, according to the technology of the present disclosure, the NSMF can apply the following logic to automatically determine the existence of RAN sharing and the type of RAN sharing used.

[0157] The NSMF receives the 3GPP TS 28.541 "Service Profile" structure from the CSMF. The NSMF checks the "plmnInfoList" field, which is a list of "plmnInfos", and checks the "pLMNId" field of each "plmnInfo" structure for the presence of a new PLMN identifier. The PLMN identifier is used to identify the mobile network operator. If there is a new PLMN identifier that was not previously provisioned, this may indicate that RAN sharing is used.

[0158] If a new PLMN is present, the NSMF checks for the presence of a 3GPP TS 28.541 “ServiceProfile” structure. The NSMF checks for a “RadioSpectrum” structure containing an “nrOperatingBands” field, which indicates the carrier / frequency to be used for the slice. If there is no existing RAN slice subnet with another PLMN identifier and the same “nrOperatingBands”, this may indicate that the same frequencies are not shared by two (or more) mobile network operators, indicating that MORAN is used. If there is an existing RAN slice subnet with another PLMN and the same “nrOperatingBands”, this may indicate that the same frequencies are being shared by two (or more) mobile network operators, indicating that MOCN is used.

[0159] Figure 5 is a block diagram illustrating the definition of a slice profile data structure. In one aspect, a slice profile 500 ("SliceProfile") may be defined as shown in Section 6.3.4 of the 5G NRM, although other formats may also be used. The slice profile 500 represents attributes of network slice subnet related requirements that a network slice subnet instance in a 5G network should support. The slice profile 500 may include fields for a slice profile ID 502 ("sliceProfileID"), a public land mobile network (PLMN) information list 504 ("pLMNIinfoList"), a CN slice subnet profile 506 ("CNSliceSubnetProfile"), a RAN slice subnet profile 508 ("RANSliceSubnetProfile"), and a top slice subnet profile 510 ("TopSliceSubnetProfile"). The PLMN information list 504 may include one or more PLMN identifiers (IDs) that may be used to identify an operator.

[0160] Figure 6 is a block diagram illustrating the definition of a RAN slice subnet profile data structure. In one aspect, a RAN slice subnet profile 600 ("RANSliceSubnetProfile") may be defined as shown in Section 6.3.24 of the 5G NRM, although other formats may be used. The RAN slice subnet profile 600 represents the RAN slice profile requirements for network slices in a 5G network. The RAN slice subnet profile 600 may include NR operating bands 602 ("nROperatingBands") (indicating the carrier / frequency used to carry the network slice) and other fields (not shown).

[0161] Figure 7 is a block diagram illustrating the definition of a core network (CN) slice subnet profile data structure. In one aspect, a CN slice subnet profile 700 ("CNSliceSubnetProfile") may be defined as shown in section 6.3.23 of the 5G NRM, although other formats may be used. The CN slice subnet profile 700 represents the requirements for the CN slice profile for network slices in a 5G network. The CN slice subnet profile 700 may include NR operating bands 702 ("nROperatingBands") (indicating the carrier / frequency used to carry the network slice) and other fields (not shown).

[0162] Figure 8 is a block diagram illustrating the definition of a service profile data structure. In one aspect, a service profile 800 ("ServiceProfile") may be defined as shown in Section 6.3.3 of the 5G NRM, although other formats may be used. The service profile 800 represents attributes of network slice-related requirements that a network slice instance in a 5G network should support. The service profile 800 may include a service profile ID 802 ("serviceProfileID"), a PLMN information list 804 ("pLMNInfoList"), and a radio spectrum 806 ("radioSpectrum"), as well as other fields (not shown). The PLMN information list 804 may include one or more PLMN identifiers (IDs) that may be used to identify an operator.

[0163] Fig. 9 is a block diagram illustrating the definition of a radio spectrum data structure. In one aspect, a radio spectrum 900 ("RadioSpectrum") may be defined as shown in Section 6.3.31 of the 5G NRM, although other formats may be used. Radio spectrum 900 represents the radio spectrum in a 5G network that should support network slicing. Radio spectrum 900 may include "Service Attributes Common (SERV ATTR COM)" 902 and NR operating bands 904 ("nROperatingBands") (which indicate the carriers / frequencies used to carry network slices).

[0164] refer to Figures 5 to 9 As mentioned above, Figures 1A to 1CThe RAN sharing detector 103 can use the information provided in the slice profile 500 to analyze the new slice subnet requirement and whether this case is MORAN or MOCN. The RAN sharing detector 103 uses the PLMN information list 504 field in the slice profile 500 data structure and checks for the new PLMN ID (hence the new operator, indicating that RAN sharing is enabled). The RAN sharing detector 103 can use the NR operating band 604 field of the RAN slice subnet profile 600 to detect the frequency to be used in the slice. For the case of NSMF, the NR operating band 904 field of the radio spectrum 900 data structure can be used instead of the NR operating band 604 field. If the frequency (or frequencies) is not used by another PLMN, the RAN sharing type is MORAN; if the frequency is in use, the RAN sharing type is MOCN. This process can be repeated for complex multi-tenant scenarios, for example, operator A and operator B start a RAN sharing agreement based on MORAN on operator A's infrastructure, and later, operator B enters into a MOCN RAN sharing agreement with operator C on top of operator A's infrastructure.

[0165] In one aspect, the RAN sharing detector 103 supports including a RAN sharing SLA in addition to the slice SLA for slice management. The RAN NSSMF (or NSMF) may use the RAN sharing SLA as part of its slice resource allocation processing whenever a new slice creation / modification is requested. This may affect processes such as slice feasibility check, slice creation, slice modification, and slice deletion. The RAN sharing detector 103 provides support for the tenant operator NSMF to drive the hosting (e.g., infrastructure leasing) of the operator's RAN NSSMF for RAN slice MORAN and MOCN RAN sharing scenarios. The RAN sharing detector 103 provides support for multi-tenant MORAN and MOCN RAN sharing scenarios, where the leasing operator further leases resources to third-party operators. In addition, for slice management operations in a RAN shared network, the RAN NSSMF (or NSMF) can support multiple northbound consumers, whether NSMF or RAN NSSMF.

[0166] The RAN sharing detector 103 can handle various scenarios, including for RAN NSSMF, CNNSSF and NSMF. When the RANNSSMF is triggered by the NSMF (in a message) to create (or modify) a network slice, although there is no field indicating RAN sharing in the message, the RAN sharing detector 103 automatically detects the presence of RAN sharing and the type of RAN sharing as follows. The detector 103 checks the PLMN information list 504 field of the slice profile 500 (a data structure sent from the NSMF to the RAN NSSMF). The PLMN information list 504 is a list of PLMN IDs. The RAN sharing detector 103 checks each PLMN ID field for the presence of a new PLMN ID (used to identify the operator). If there is a new PLMN ID that was not previously provisioned, this indicates that there is RAN sharing. If there is a new PLMN ID, the RAN sharing detector 103 checks the NR operating band 604 field of the RAN slice subnet profile 600 data structure.

[0167] If there is no existing RAN slice subnet with another PLMN ID and with the same NR operating frequency band value as the new PLMN ID, this means that the same frequency is not shared by two (or more) operators. This is the MORAN RAN sharing type.

[0168] If there is an existing RAN slice subnet with another PLMN ID and with the same NR operating band value, this means that the same frequencies are shared by two (or more) operators. This is the MOCN RAN sharing type.

[0169] For the CN NSSMF, the detector 103 performs similar processing, except that the RAN sharing detector 103 checks the CN slice subnet profile 700 instead of checking the RAN slice subnet profile 600.

[0170] For NSMF, when NSMF is triggered by Communication Service Management Function (CSMF) (through a message) to create (or modify) a network slice, although there is no field indicating RAN sharing in the message, the RAN sharing detector 103 automatically detects the presence of RAN sharing and the type of RAN sharing as follows. The detector 103 checks the PLMN information list 804 field of the service profile 800 (a data structure sent from the CSMF to the NSMF). The PLMN information list 804 is a list of PLMN IDs. The RAN sharing detector 103 checks each PLMN ID field for the presence of a new PLMN ID (for identifying an operator). If there is a new PLMN ID that has not been previously provisioned, this indicates that there is RAN sharing. If there is a new PLMN ID, the detector 103 checks the NR operating band 904 field of the radio spectrum 900 data structure.

[0171] If there is no existing RAN slice subnet with another PLMN ID and with the same NR operating frequency band value, this means that the same frequency is not shared by two (or more) operators. This is the MORAN RAN sharing type.

[0172] If there is an existing RAN slice subnet with another PLMN ID and with the same NR operating band value, this means that the same frequencies are shared by two (or more) operators. This is the MOCN RAN sharing type.

[0173] Fig.10 is a flow chart illustrating example operations 1000 according to the techniques of this disclosure. More specifically, Fig.10 Depicted is operation 1000 for automatically detecting Figures 1A to 1C The presence of RAN sharing within the mobile network 120 and the type of RAN sharing used within the mobile network 120 are determined. For convenience, reference is made to Figures 1A to 1C To describe Fig.10 However, the techniques of the present disclosure embodied by operation 1000 may be performed by other components or systems described throughout this disclosure.

[0174] The RAN sharing detector 103 of the SMO 112 receives a message for implementing network slicing of the RAN 109 (1002). In some examples, the RAN sharing detector 103 receives a message for implementing network slicing of the RAN 109 from the NSMF of the mobile core network 105. Figure 1A The message includes a configuration file, and the configuration file includes a first PLMN identifier and a first operating frequency band value.

[0175] The RAN sharing detector 103 determines whether another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109 (1004). For example, the RAN sharing detector 103 analyzes one or more fields in one or more data structures of the message to determine whether another RAN slice subnet with a second PLMN identifier is provisioned within the RAN 109. Based on the presence of only the first PLMN identifier and no second PLMN identifier in the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is not used in the mobile network 120 (the "No" branch of 1004: 1006). This is because there is no RAN subnet provisioned with two different PLMN identifiers within the RAN 109, which indicates that only a single network operator corresponding to the first PLMN identifier is using the resources of the RAN 109.

[0176] Based on the presence of the first PLMN identifier and the second PLMN identifier within the common RAN 109, the RAN sharing detector 103 determines that RAN sharing is used within the mobile network 120 (the "yes" branch of 1004: 1008). This is because the presence of a RAN subnet provisioned with two different PLMN identifiers within the RAN 109 indicates that the two network operators corresponding to the two PLMN identifiers are using the resources of the RAN 109.

[0177] The RAN sharing detector 103 determines whether another RAN slice subnet is provisioned within the RAN 109, the other RAN slice subnet having a different PLMN identifier and having the same first operating frequency band value as specified in the configuration file of the message (1010).

[0178] In response to determining that a second RAN slice subnet having a second PLMN identifier and having the same first operating frequency band value as specified in the configuration file of the message is provisioned within the RAN 109 (e.g., the "yes" branch of 1010), the RAN sharing detector 103 determines that the RAN sharing type is MOCN (1012). This is because the presence of two different PLMN identifiers indicating the use of the same operating frequency band indicates that the two network operators corresponding to the two PLMN identifiers share the same operating frequency band within the RAN 109, thereby indicating that the RAN 109 uses MOCN.

[0179] In response to determining that another RAN slice subnet having a different PLMN identifier and having the same first operating frequency band value as specified in the configuration file of the message is not provisioned within the RAN 109 (e.g., the "No" branch of 1010), the RAN sharing detector 103 determines whether other RAN slice subnets having a PLMN identifier different from the first PLMN identifier within the RAN 109 are not provisioned with the same first operating frequency band value (1014).

[0180] In response to determining that there are no other RAN slice subnets having a PLMN identifier different from the first PLMN identifier within the RAN 109 that are provisioned with the same first operating frequency band value within the RAN 109 (e.g., the "yes" branch of 1014), the RAN sharing detector 103 determines that the RAN sharing type is MORAN (1016). This is because the presence of two different PLMN identifiers within the RAN 109 indicates that two network operators corresponding to the two PLMN identifiers are sharing the RAN 109, but because each network operator has non-overlapping operating frequency bands, there is no sharing of the operating frequency bands, thereby indicating that the RAN 109 uses MORAN. Otherwise (e.g., the "no" branch of 1014), the RAN sharing detector 103 determines that the RAN 109 is using some other type of RAN sharing (1018).

[0181] The RAN sharing detector 103 manages network slices in the RAN 109 based on the determined RAN sharing type (1020). For example, the RAN sharing detector 103 may configure one or more network devices of the RAN 109 to forward network traffic of one or more subscriber devices 104 according to the determined RAN sharing type. In some examples, the RAN sharing detector 103 provisions at least one of a RAN slice subnet within the RAN 109 and a core network slice subnet within the core network 105 according to a profile of the message and the determined RAN sharing type.

[0182] The techniques described in the present disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, the corresponding aspects of the described techniques may be implemented in one or more programmable processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuits and any combination of these components. The term "processor" or "processing circuit" may generally refer to any of the aforementioned logic circuits (alone or in combination with other logic circuits) or any other equivalent circuits. A control unit including hardware may also perform one or more techniques of the present disclosure.

[0183] Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any described units, modules, or components may be implemented together or separately as discrete but interoperable logic devices. Describing different features as modules or units is intended to highlight different functional aspects and does not necessarily mean that these modules or units must be implemented by separate hardware or software components. On the contrary, the functions associated with one or more modules or units may be performed by separate hardware or software components, or integrated in common or separate hardware or software components.

[0184] The techniques described in the present disclosure may also be embodied or encoded in a computer-readable medium containing instructions, such as a computer-readable storage medium. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Tangible and non-transitory computer-readable storage media may include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk, CD-ROM, floppy disk, cassette, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage medium" refers to a physical storage medium, not a signal / carrier wave or other transient medium.

Claims

1. A computing system for a mobile network, comprising: A processing circuit in communication with the storage medium, the processing circuit being configured to: receiving a message for implementing network slicing of a radio access network RAN, the message comprising a configuration file, the configuration file comprising a first public land mobile network PLMN identifier and a first operating frequency band value of the RAN; Determining that the RAN sharing type is a multi-operator core network, MOCN, based at least in part on determining that at least one RAN slice subnet having a second PLMN identifier and the first operating frequency band value is provisioned within the RAN; Determining that the RAN sharing type is a multi-operator RAN (MORAN) based at least in part on determining that a RAN slice subnet having the second PLMN identifier and the first operating frequency band value is not provisioned within the RAN; as well as Based on the determined RAN sharing type, manage the network slice in the RAN.

2. The computing system of claim 1, wherein: To configure one or more network devices to forward network traffic of one or more subscriber devices according to the determined RAN sharing type, the processing circuit is configured to: At least one of a RAN slice subnet and a core network slice subnet is provisioned based on the profile of the message and the determined RAN sharing type.

3. The computing system of claim 1, wherein: The processing circuit is also configured to provision a RAN slice subnet within the RAN based on the configuration file.

4. The computing system of claim 1, wherein: The configuration file includes a service configuration file for a network slice management function NSMF received from a communication service management function CSMF, and the service configuration file specifies the first PLMN identifier and the first operating frequency band value of the RAN.

5. The computing system of claim 1, wherein: The configuration file includes: a slice profile for a RAN Network Slice Subnet Management Function NSSMF received from a Network Slice Management Function NSMF, the slice profile specifying the first PLMN identifier of the RAN; and A RAN slice subnet configuration file that specifies the first working frequency band value.

6. The computing system of claim 1, wherein: The configuration file includes: a slice profile for a core network network slice subnet management function NSSMF received from a network slice management function NSMF, the slice profile specifying the first PLMN identifier of the RAN; and A core slice subnet configuration file that specifies the first working frequency band value.

7. The computing system of claim 1, wherein: The RAN is configured to perform RAN sharing before provisioning the network slice.

8. The computing system of claim 1, wherein: The RAN is configured to perform RAN sharing after provisioning the network slice.

9. The computing system of claim 1, wherein: The message is initiated by the network slice management function NSMF of the RAN.

10. The computing system according to claim 1, in, The mobile network includes the RAN and the core network, and The message is initiated by the communication service management function CSMF of the core network.

11. The computing system of claim 1, wherein: The RAN includes an open radio access network O-RAN of the mobile network.

12. The computing system of claim 1, wherein: The RAN comprises a fifth generation (5G) 3rd Generation Partnership Project (3GPP) RAN of the mobile network.

13. The computing system according to any one of claims 1 to 12, wherein: In order to manage the network slice in the RAN, the processing circuit is configured to configure one or more network devices of the RAN to forward network traffic of one or more subscriber devices according to the determined RAN sharing type.

14. The computing system of claim 13, in, The determined RAN sharing type is MORAN, and Wherein, in order to configure the one or more network devices to forward network traffic of the one or more subscriber devices according to the determined RAN sharing type, the processing circuit is configured to: configuring the one or more network devices to forward network traffic of one or more first subscriber devices associated with the first PLMN identifier via a first operating frequency band corresponding to the first operating frequency band value; and configuring the one or more network devices to forward network traffic of one or more second subscriber devices associated with the second PLMN identifier via a second operating frequency band different from the first operating frequency band, The network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share a base station and a site.

15. The computing system of claim 13, in, The determined RAN sharing type is MOCN, and Wherein, in order to configure the one or more network devices to forward network traffic of the one or more subscriber devices according to the determined RAN sharing type, the processing circuit is configured to: configuring the one or more network devices to forward network traffic of one or more first subscriber devices associated with the first PLMN identifier and network traffic of one or more second subscriber devices associated with the second PLMN identifier via a first operating frequency band corresponding to the first operating frequency band value, The network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share a base station and a site.

16. A mobile network method, comprising: A message for implementing network slicing of a radio access network RAN ​​is received by a computing system, the message comprising a configuration file, the configuration file comprising a first public land mobile network PLMN identifier and a first operating frequency band value of the RAN; Determining, by the computing system, that the RAN sharing type is a multi-operator core network (MOCN) based at least in part on determining that at least one RAN slice subnet having a second PLMN identifier and the first operating frequency band value is provisioned within the RAN; Determining, by the computing system, that the RAN sharing type is a multi-operator RAN (MORAN) based at least in part on determining that a RAN slice subnet having the second PLMN identifier and the first operating frequency band value is not provisioned within the RAN; as well as The computing system manages the network slice in the RAN based on the determined RAN sharing type.

17. The mobile network method according to claim 16, wherein: Managing the network slice in the RAN includes configuring one or more network devices of the RAN to forward network traffic of one or more subscriber devices based on the determined RAN sharing type.

18. The mobile network method according to claim 17, in, The determined RAN sharing type is MORAN, and The configuring the one or more network devices to forward network traffic of the one or more subscriber devices according to the determined RAN sharing type comprises: configuring the one or more network devices to forward network traffic of one or more first subscriber devices associated with the first PLMN identifier via a first operating frequency band corresponding to the first operating frequency band value; and configuring the one or more network devices to forward network traffic of one or more second subscriber devices associated with the second PLMN identifier via a second operating frequency band different from the first operating frequency band, The network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share a base station and a site.

19. The mobile network method according to claim 17, in, The determined RAN sharing type is MOCN, and The configuring the one or more network devices to forward network traffic of the one or more subscriber devices according to the determined RAN sharing type comprises: configuring the one or more network devices to forward network traffic of one or more first subscriber devices associated with the first PLMN identifier and network traffic of one or more second subscriber devices associated with the second PLMN identifier via a first operating frequency band corresponding to the first operating frequency band value, The network traffic of the one or more first subscriber devices and the network traffic of the one or more second subscriber devices share a base station and a site.

20. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to be configured as a computing system according to any one of claims 1 to 15, or to be configured to perform a method according to any one of claims 16 to 19.

Images