Patent ID: 12245043

DETAILED DESCRIPTION

A client may want to use a cellular network to obtain or provide a particular one or more services. The type of services desired by different clients can vary significantly. For example, a first client may desire to operate a network of unmanned aerial vehicles (UAVs), while a second client may desire to provide access to a group of user equipment (UE), such as smartphones, operated by the second client's employees; a third client may desire to provide wireless gaming services to its customers; and a fourth client may desire to operate a network of Internet of Things (IoT) sensor devices.

In order to satisfy each client's needs, each client may be granted access to a cellular network slice. A “cellular network slice” or simply “slice” is a virtual cellular network that operates on an underlying physical cellular network. Each slice is mapped to a set of operating parameters that control the level of service that devices connected with the slice receive. These parameters can be tailored to the particular uses or services desired by the client. For example, in the example discussed above, latency may be of little importance to the fourth client's IoT sensor network, but may be of critical importance to the first client operating the UAVs. While the third client may need a high amount of downlink bandwidth (to the UE from the cellular network) for gaming per gaming device, the first client may require relatively little downlink bandwidth per UAV. Slicing allows for an SLA and the accompanying performance of the cellular network to be tailored to each client.

While a client may be desirous of having access to a slice tailored to their needs, the client may not have the information or sophistication necessary to be able to define the parameters of the slice needed to realize the client's goals. Without such information, the client and the cellular network operator (which can also be referred to as a mobile network operator, MNO) may need to perform a significant number of iterations of the parameters of the cellular network slice in order to arrive at a set of parameters that sufficiently meet the client's needs, while not being overly inefficient (and overly costly) due to devoting too great of an amount of cellular network resources to the slice.

Embodiments detailed herein are focused on an MNO creating a set of slice templates based on feedback from clients. The slice templates can be used for future clients to use a starting point for creating a slice. Each slice template can be mapped to one or more particular use cases. Additional feedback from the MNO can be incorporated. A library of many slices can be used to create a smaller library of slice templates. Based on the type of service that a client desires to offer, a slice template corresponding to the type of service can be used to define a slice as a starting point for the client. The client can then use the slice, test the slice, and/or modify particular parameters. Such an arrangement can greatly reduce the number of iterations that the client and MNO need to perform in order to arrive at a defined slice that adequately meets the client's needs.

Slicing can be performed on cellular networks that operate according to various standards. In some embodiments, the cellular network can be a 5G New Radio (NR) cellular network. Future generations of cellular networks may also use slicing, such as 6G and 7G cellular networks.FIG.1illustrates a block diagram of a cellular network system (“system100”) on which slicing may be performed. System100can include a 5G New Radio (NR) cellular network; as noted, other types of cellular networks, such as 6G, 7G, etc., may also be possible. System100can include: UE110(UE110-1, UE110-2, UE110-3); structure115; cellular network120; radio units125(“RUs125”); distributed units127(“DUs127”); centralized unit129(“CU129”); 5G core139; Slice Template Creation and Implementation System300(“STCIS300”); and orchestrator138.FIG.1represents a component-level view. In an open radio access network (O-RAN), because components can be implemented as specialized software executed on general-purpose hardware, except for components that need to receive and transmit RF, the functionality of the various components can be shifted among different servers. For at least some components, the hardware may be maintained by a separate cloud-service provider, to accommodate where the functionality of such components is needed, or a hybrid arrangement which can use an on-premises data center and cloud computing functionality. Detail regarding STCIS300is provided in relation toFIG.3.

UE110can represent various types of end-user devices, such as cellular phones, smartphones, cellular modems, cellular-enabled computerized devices, sensor devices, robotic equipment, IoT devices, gaming devices, access points (APs), or any computerized device capable of communicating via a cellular network. More generally, UE can represent any type of device that has an incorporated 5G interface, such as a 5G modem. Examples can include sensor devices, Internet of Things (IoT) devices, manufacturing robots, unmanned aerial (or land-based) vehicles, network-connected vehicles, etc. Depending on the location of individual UEs, UE110may use RF to communicate with various BSs of cellular network120. As illustrated, two BSs are illustrated: BS121-1can include: structure115-1, RU125-1, and DU127-1. Structure115-1may be any structure to which one or more antennas (not illustrated) of the BS are mounted. Structure115-1may be a dedicated cellular tower, a building, a water tower, or any other man-made or natural structure to which one or more antennas can reasonably be mounted to provide cellular coverage to a geographic area. Similarly, BS121-2can include: structure115-2, RU125-2, and DU127-2.

Real-world implementations of system100can include many (e.g., thousands) of BSs and many CUs and 5G core139. BS121-1can include one or more antennas that allow RUs125to communicate wirelessly with UEs110. RUs125can represent an edge of cellular network120where data is transitioned to RF for wireless communication. The radio access technology (RAT) used by RU125may be 5G NR, or some other RAT. The remainder of cellular network120may be based on an exclusive 5G architecture, a hybrid 4G/5G architecture, or some other cellular network architecture that supports cellular network slices. BS121may include an RU (e.g., RU125-1) and a DU (e.g., DU127-1).

One or more RUs, such as RU125-1, may communicate with DU127-1. As an example, at a possible cell site, three RUs may be present, each connected with the same DU. Different RUs may be present for different portions of the spectrum. For instance, a first RU may operate on the spectrum in the citizens broadcast radio service (CBRS) band while a second RU may operate on a separate portion of the spectrum, such as, for example, band71. In some embodiments, an RU can also operate on three bands. One or more DUs, such as DU127-1, may communicate with CU129. Collectively, an RU, DU, and CU create a gNodeB, which serves as the radio access network (RAN) of cellular network120. DUs127and CU129can communicate with 5G core139. The specific architecture of cellular network120can vary by embodiment. Edge cloud server systems (not illustrated) outside of cellular network120may communicate, either directly, via the Internet, or via some other network, with components of cellular network120. For example, DU127-1may be able to communicate with an edge cloud server system without routing data through CU129or 5G core139. Other DUs may or may not have this capability.

WhileFIG.1illustrates various components of cellular network120, other embodiments of cellular network120can vary the arrangement, communication paths, and specific components of cellular network120. While RU125may include specialized radio access componentry to enable wireless communication with UE110, other components of cellular network120may be implemented using either specialized hardware, specialized firmware, and/or specialized software executed on a general-purpose server system. In an O-RAN arrangement, specialized software on general-purpose hardware may be used to perform the functions of components such as DU127, CU129, and 5G core139. Functionality of such components can be co-located or located at disparate physical server systems. For example, certain components of 5G core139may be co-located with components of CU129.

In a possible O-RAN implementation, DUs127, CU129, 5G core139, and/or orchestrator138can be implemented virtually as software being executed by general-purpose computing equipment, such as in a data center, as detailed herein. Therefore, depending on needs, the functionality of a DU, CU, and/or 5G core may be implemented locally to each other and/or specific functions of any given component can be performed by physically separated server systems (e.g., at different server farms). For example, some functions of a CU may be located at a same server facility as where 5G core139is executed, while other functions are executed at a separate server system or on a separate cloud computing system. In the illustrated embodiment of system100, cloud-based cellular network components128include CU129, 5G core139, and orchestrator138. Such cloud-based cellular network components128may be executed as specialized software executed by underlying general-purpose computer servers. Cloud-based cellular network components128may be executed on a third-party cloud-based computing platform or a cloud-based computing platform operated by the same entity that operates the RAN. A cloud-based computing platform may have the ability to devote additional hardware resources to cloud-based cellular network components128or implement additional instances of such components when requested.

Kubernetes, Docker®, or some other container orchestration platform, can be used to create and destroy the logical CU or 5G core units and subunits as needed for the cellular network120to function properly. Kubernetes allows for container deployment, scaling, and management. As an example, if cellular traffic increases substantially in a region, an additional logical CU or components of a CU may be deployed in a data center near where the traffic is occurring without any new hardware being deployed. (Rather, processing and storage capabilities of the data center would be devoted to the needed functions.) When the need for the logical CU or subcomponents of the CU no longer exists, Kubernetes can allow for removal of the logical CU. Kubernetes can also be used to control the flow of data (e.g., messages) and inject a flow of data to various components. This arrangement can allow for the modification of nominal behavior of various layers.

The deployment, scaling, and management of such virtualized components can be managed by orchestrator138. Orchestrator138can represent various software processes executed by underlying computer hardware. Orchestrator138can monitor cellular network120and determine the amount and location at which cellular network functions should be deployed to meet or attempt to meet service level agreements (SLAs) across slices of the cellular network.

Orchestrator138can allow for the instantiation of new cloud-based components of cellular network120. As an example, to instantiate a new core function, orchestrator138can perform a pipeline of calling the core function code from a software repository incorporated as part of, or separate from, cellular network120; pulling corresponding configuration files (e.g., helm charts); creating Kubernetes nodes/pods; loading the related core function containers; configuring the core function; and activating other support functions (e.g., Prometheus, instances/connections to test tools).

As previously noted, a cellular network slice functions as a virtual network operating on an underlying physical cellular network. Operating on cellular network120is some number of cellular network slices, such as hundreds or thousands of network slices. Communication bandwidth and computing resources of the underlying physical network can be reserved for individual network slices, thus allowing the individual network slices to reliably meet defined SLA requirements. By controlling the location and amount of computing and communication resources allocated to a network slice, the QoS and QoE for UE can be varied on different slices. A network slice can be configured to provide sufficient resources for a particular application to be properly executed and delivered (e.g., gaming services, video services, voice services, location services, sensor reporting services, data services, etc.). However, resources are not infinite, so allocation of an excess of resources to a particular UE group and/or application may be desired to be avoided. Further, a cost may be attached to cellular slices: the greater the amount of resources dedicated, the greater the cost to the user; thus optimization between performance and cost is desirable.

Particular parameters that can be set for a cellular network slice can include: uplink bandwidth per UE; downlink bandwidth per UE; aggregate uplink bandwidth for a client; aggregate downlink bandwidth for the client; latency; access to particular services; and maximum permissible jitter; area of service; delay tolerance; energy efficiency; isolation level and security parameters; positioning support, methods, and/or accuracy; user data access; tunneling; supported data networks; available services (e.g., IMS support, mission critical services, push to talk, etc.); customer provided network functions (e.g., AAA, customer-owned UPF); particular RF bands supported; duration of need for slice (open date/time and close date/time); and level of exclusivity needed (e.g., 100% exclusive, or open to sharing).

Particular network slices may only be reserved in particular geographic regions. For instance, a first set of network slices may be present at RU125-1and DU127-1, a second set of network slices, which may only partially overlap or may be wholly different from the first set, may be reserved at RU125-2and DU127-2.

Further, particular cellular network slices may include multiple defined layers. Each layer within a network slice may be used to define parameters and other network configurations for particular types of data. For instance, high-priority data sent by a UE may be mapped to a layer having relatively higher QoS parameters and network configurations than lower-priority data sent by the UE that is mapped to a second layer having relatively less stringent QoS parameters and different network configurations.

Components such as DUs127, CU129, orchestrator138, and 5G core139may include various software components that are required to communicate with each other, handle large volumes of data traffic, and are able to properly respond to changes in the network. In order to ensure not only the functionality and interoperability of such components, but also the ability to respond to changing network conditions and the ability to meet or perform above vendor specifications, significant testing must be performed.

FIG.2illustrates a block diagram of a cellular network core, which can represent 5G core139. 5G core139, which can be physically distributed across data centers or located at a central national data center (NDC), can perform various core functions of the cellular network. 5G core139can include: network resource management components150; policy management components160; subscriber management components170; and packet control components180. Individual components may communicate on a bus, thus allowing various components of 5G core139to communicate with each other directly. 5G core139is simplified to show some key components. Implementations can involve additional other components.

Network resource management components150can include: Network Repository Function (NRF)152and Network Slice Selection Function (NSSF)154. NRF152can allow 5G network functions (NFs) to register and discover each other via a standards-based application programming interface (API). NSSF154can be used by AMF182to assist with the selection of a network slice that will serve a particular UE.

Policy management components160can include: Charging Function (CHF)162and Policy Control Function (PCF)164. CHF162allows charging services to be offered to authorized network functions. Converged online and offline charging can be supported. PCF164allows for policy control functions and the related 5G signaling interfaces to be supported.

Subscriber management components170can include: Unified Data Management (UDM)172and Authentication Server Function (AUSF)174. UDM172can allow for generation of authentication vectors, user identification handling, NF registration management, and retrieval of UE individual subscription data for slice selection. AUSF174performs authentication with UE.

Packet control components180can include: Access and Mobility Management Function (AMF)182and Session Management Function (SMF)184. AMF182can receive connection- and session-related information from UE and is responsible for handling connection and mobility management tasks. SMF184is responsible for interacting with the decoupled data plane, creating updating and removing Protocol Data Unit (PDU) sessions, and managing session context with the User Plane Function (UPF).

User plane function (UPF)190can be responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting with a Data Network (DN)195(e.g., the Internet) or various access networks197. Access networks197can include the RAN of cellular network120ofFIG.1A.

The functions illustrated inFIG.2as part of 5G core139are merely exemplary. Many more or different functions may be implemented in the cellular network core and may vary by slice. The amount of computing resources devoted to a particular function can vary by slice.

FIG.3illustrates a block diagram of an embodiment of a slice template creation and implementation system300(“system300”). System300can include: internal framework orchestrator320; client portal330; network test engine340; feedback engine350; and network feedback portal360. To perform the functions of these components, one or more special-purpose or general-purpose processors may be used. Such special-purpose processors may include processors that are specifically designed to perform the functions of the components detailed herein. Such special-purpose processors may be ASICs or FPGAs which are general-purpose components that are physically and electrically configured to perform the functions detailed herein. Such general-purpose processors may execute special-purpose software that is stored using one or more non-transitory processor-readable mediums, such as random access memory (RAM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD). The functions of these components can be implemented using a cloud-computing platform, which can be operated by a separate cloud-service provider that executes code and provides storage.

System300can further include various data storage arrangements, including: template library322; network map324; test results database342; and slice library356. Such data storage arrangements are implemented using non-transitory processor-readable mediums, such as HDDs or SSDs. On a cloud-computing platform, storage may be located at one data center or distributed across multiple data centers.

Client portal330can represent an interface through which a client makes an initial request for a slice via client input301. The client may provide basic information to system300such as: the desired use of the slice; the number of devices to connect with the slice; the geographic region in which the slice is to be operated. If the client is aware of one or more parameters that the slice is required to have or exceed, the client can specify via client portal330. In some embodiments, such information may be provided via another method, such as via telephone to a representative of the MNO.

Template library322can store various templates that can be used to define the parameters for a network slice. Internal framework orchestrator320may use the information obtained from client portal330and template library322to initially configure a cellular network slice for the client. Based on the desired use of the slice, a correct template may be identified within template library322as a starting point. If the client requested that one or more particular parameters be met or exceeded, such parameters may be incorporated as part of the cellular network slice created by internal framework orchestrator320.

Internal framework orchestrator320may then create and configure the cellular network slice on the cellular network, such as cellular network120. Creation of the cellular network slice can include creating network functions as part of 5G core139to service the slice. The slice, as created for the client, may be stored to slice library356.

The created cellular network slice may be made available to the client for all or a subset of the client's UE for testing or use. After a time, via client portal330, the client may be requested to provide feedback about the slice. The feedback requested can include a score (e.g., a numeric or letter grade) for one or more aspects of the slice. In some embodiments, the feedback can be a single all-encompassing score. In other embodiments, the feedback can constitute multiple scores given on different aspects of the slice. This feedback can be used by feedback monitor352of feedback engine350to store in slide library356along with a definition of the slice and serve as a basis to modify one or more parameters of the slice. The client may be permitted to request changes to slice parameters as much as necessary to optimize the performance and cost of the slice for the client. The feedback provided by the client may in some embodiments only be collected once the client has arrived at a set of finalized slice parameters.

In addition to obtaining feedback from the client, feedback can be obtained from an administrator of the MNO. The administrator may provide network feedback portal360with various forms of feedback that is indicative of an administrator score (e.g., a numeric or letter grade) of the slice from the MNO's perspective. For example, a slice that results in a significant profit margin may be given a high score. Network feedback portal360may also receive various feedback, either from an administrator or from another system, that is indicative of characteristics that can be incorporated as part of the network feedback. For example, a slice that includes relatively high utilization of network resources may be provided with a higher score. (That is, a slice that averages 75% processing resource utilization may be more efficient and useful both for the MNO and the client than a slice that averages 55% processing resource utilization.) Feedback received by network feedback portal360can be stored by feedback monitor352in association with the definition of the slice in slice library356.

Network test engine340can periodically or occasionally run tests on slices of the cellular network. This testing can be used to determine how well a slice can function if the cellular network is not performing optimally. Such testing can involve chaos testing, in which a failure is simulated on the network and the performance of a slice during the failure is evaluated. Such testing may be performed in a development environment as opposed to the production environment. As an example, the more resilient the slice is when chaos is applied to the slice, the higher the score that may be awarded. To create the slice in the development environment, network map324may be accessed. Network map324can indicate a logical and physical map of how all components of the cellular network are connected, the processing resources present on the network, the utilization of processing resources and bandwidth, network traffic, etc. Results of network testing may be stored to test results database342. A separate test score may be mapped to a slice in slice library356or may be accessible from test results database342. In some embodiments, the testing score is incorporated as part of the network operator feedback.

Periodically or occasionally, template creator345of feedback engine350can access slice library352, such as once per day. Template creator345may analyze each slice that is currently active on the cellular network and, possibly, slices that are inactive. In some embodiments, inactive slices, if used, have their score negatively adjusted based on being inactive. Template creator345may analyze the scores available for each slice. Template creator354can select a particular “best-in-class” slice based on the scores for inclusion in template library322. That is, the highest scoring slice for a particular slice category can be included in template library. In some embodiments, a predefined number of slices for each category can be included in template library322. The category for each slice may have been received either via client portal330or from the network administrator via network feedback portal360.

The scores may be averaged together or may otherwise be combined to create a ranking of slices within a particular category. For example, a weighting could be used. If three scores are present, an example of a weighting could be 60% for the customer's score, 30% for the network administrator score, and 10% based on the network test results.
Weighted Score=W1CS+W2AS+W3NSEq. 1

As a more generic example, in equation 1, weights W1, W2, and W3can be set in order to relatively weigh the customer score (CS), administrator score (AS), and network test result score (NS).

In other embodiments, multiple slice definitions within a category having a score above a defined threshold may be combined in order to create a template for the category. For example, if a customer provides a score over a particular defined value, the definition of the slice may be used in creating the template for the category. If a customer provides a score below a threshold value, the parameters of the slice may not be used for creating the template or may be actively avoided, since such parameters resulted in a low customer score. If multiple slices within a category qualify for inclusion, when the same parameter is used across the multiple qualifying slices, the value of the parameter may be averaged or otherwise combined. Such an arrangement may be beneficial if not all of the same parameters are defined across slices within a category. The template may then be able to contain a compilation of the values of parameters of slices within the category that clients have been satisfied with (and, possibly, which meet threshold scores for the network test and/or the network administrator).

In some embodiments, each slice created for the network may not be categorized. An unsupervised clustering algorithm may be used to cluster slice definitions that are determined to be adequately similar. Each parameter of the network slices may be treated as a dimension. Once clustered, the parameters of clustered network slice definitions may be averaged or otherwise combined together to create a template. An administrator may then tag the template with a particular category definition. For example, the administrator may review which slices have been clustered together and to which clients such slices are mapped. The template created from the cluster may then have one or more tags applied such that in the future the template can be applied to clients that have similar needs as the clients corresponding to the clustered slices.

In other embodiments, a machine learning (ML) model may be used to create the templates. A ML model may be trained using a training set of data. In this example, the training set of data may be slice definitions (with each definition including some number of slice parameters) that are mapped to one or more scores and to the category of the slice. Alternatively, ML models may be trained and applied separately for each category or subcategory. Scores can be used by the ML model to weigh slice parameters that tend to result in high scores or low scores. Parameters that result in low scores may tend to be avoided by the ML model, while parameters that result in high scores may tend to be targeted. The trained ML model may be a multi-layer neural network or some other form of ML model.

In other embodiments, for an ML model to create a new template, a client may provide some baseline inputs to the machine learning model such as the purpose or intent of the slice or service (e.g., general data, voice, drone, etc.), expected outcomes, or QoS/QoE parameters which could be experiential or technical in nature depending on the client type (e.g., throughput, latency, jitter, etc., or service types, such as 4K streaming video, conversational video, etc.), and some general information around expected number of devices, location, if the devices will be stationary or moving, etc. Some inputs may lead the ML model to request additional input. In the end, the ML model translates the requirements received as input into a common language (e.g., if the requirements are more experiential than technical, the ML model could first do some translation and/or abstraction, which might involve additional ML algorithms or data sets) and would run it against all of the trained/validated data to identify a set of suggested parameters and, possibly, a confidence score. The confidence score could be used by the client to decide if they want to accept the configuration or go back and answer some additional questions in order to try and get a higher confidence level before deploying the solution.

To create an initial training data set, direct client feedback may be used in which a client answers a series of questions around how well a given slice or template is meeting their specified needs and requirements. This arrangement can help determine which parameters are impacting client experience. Additional feedback loops can be used to infer the success of a given ML model such as how often clients are making changes, how often clients are reaching out to care for performance issues, etc. The algorithm or ML model used can weigh data points differently based on like versus non-like use cases, explicit feedback versus inferred feedback, etc.

Ultimately the goal of the algorithm or ML model can be to allow clients to provide requirements in the language that is known and comfortable to them and receive back a customized or suggested configuration that can be applied to meet those needs. Further, an ML model could be used to apply new learnings (from any/all existing slices) to other existing slices in order to further optimize them over time. (For example, if more information around the impacts of arboreal interference on latency becomes known based on one slice's performance, an ML model can identify similar existing slices and then apply the same learnings such that the interference is reduced there as well.)

In addition to slice categorization, one or more subcategorizations may be used. For example, while the over-arching category may be “UAV control”, a sub-categorization may be “small operator” indicating that the client operates less than 100 UAVs. Another sub-categorization may be “large operator” indicating that the client operates more than 100 UAVs, by way of example only.

The created templates can be stored to template library322. Previously stored templates can be replaced or modified based on the templates created by template creator354. When a client accesses client portal330(or otherwise communicates with the MNO), the templates present in template library322are available as a starting point for defining a slice for the client.

FIG.4illustrates database entries of a slice library400that can be used to create a slice template library. In slice library400, each row corresponds to a slice that is either active or inactive on the cellular network. Slice category405can be assigned by the client or the network administrator, or based on a clustering algorithm with a tag applied by a network administrator. Slice sub-category410may be present and may provide an additional level of categorization. For example, within slice category405, a template may be created for each available slice sub-category. Zero, one, or more than one sub-categories may be present within any given slice category.

In slice library400, only two scores are present: client score415and administrator score420. In other embodiments, fewer scores (e.g., only a client score) or more scores (e.g., addition of a network test score) may be present. Further, each score may be broken down into multiple sub-scores. For example, client score415may be broken down into a client performance score and a client cost score.

For each slice in slice library400, the slice's parameters425may be stored. In some embodiments, while a slice may have geography-specific parameters (e.g., the slice is only available in a particular region), such geography-specific parameters may be stripped out if used to create a template.

As detailed in relation to template creator354, using the one or more assigned scores, a slice definition may be imported into template library322or may be used to create a template. Each template can be mapped to a particular slice category and, possibly, at least one slice sub-category within the slice category.

A template library may contain entries similar to slice library400, but as selected or created by template creator354. An administrator of the MNO can be permitted to edit the templates, create additional templates, or delete templates as desired.

Various methods may be performed using the networks, systems, and arrangements detailed inFIGS.1-4.FIG.5illustrates an embodiment of a method for creating and implementing a cellular network slice using a template. Method500can be performed using system300ofFIG.3, which can be implemented within cellular network100ofFIG.1.

At block510, one or more general slice characteristics may be received from a client. The one or more general slice characteristics received from the client at block510can include a category and, possibly, a subcategory indicative of a type of service that the client desires to use a slice for. The category and sub-category may be selected from a predefined list for which the MNO has templates available. Additional characteristics may also be provided by the client, such as one or more slice parameters that the client desires to be included in the slice. The client may also indicate a geographic region in which the slice is to be active.

At block515, based on the general client characteristics received at block510, such as the category and subcategory, the characteristics are used to select a predefined template from the slice template library. These templates may have been created based on previous iterations of method500having been performed.

At block520, a cellular network slice may be defined at least partially based on the selected predefined template from block515if, at block510, the client defined any particular slice parameters that were required to be included in the slice; the selected predefined template may be modified to include the required parameter. In some embodiments, if method500is being performed but no relevant template corresponding to the clients category or subcategory has been created yet, the cellular network slice of block520may be defined by an administrator of the MNO. At block525, cellular network access may be provided to the client via the defined cellular network slice of block520. Through this access, the client may be able to determine if the defined cellular network slice is sufficient for the client's needs.

At block530, feedback may be provided by the client via one or more values (e.g., scores, letter grades) corresponding to one or more categories, such as overall satisfaction, cost satisfaction, performance satisfaction, etc. The feedback of block530may only be requested after the client has had ample time to test the slice, such as one week or a month. At block535, the slice parameters and associated category and, possibly, subcategory may be stored to a slice database.

If the client desires the slice to be modified, block540may be performed with either the client or an administrator of the MNO identifying one or more parameters of the slice that are to be modified to better realize the client's goal (which could be optimization between performance and cost). Blocks525-540may be repeated as many times as is necessary to obtain the client's desired slice characteristics.

At block545, feedback may be received from an administrator of the MNO and/or a score may be received based on network testing. These scores can be stored in the slice library in association with the parameters of the slice, categories of the slice, and/or client feedback of the slice. In some embodiments, a slice is only used for template creation if the slice has been active for a predefined amount of time and the client has ceased modifying the slice for a predefined period of time (e.g., 2 months).

At block550, occasionally or periodically, a template creation or modification process can be performed, as detailed in relation to template creator354. Based upon the feedback obtained from one or more sources, one or more templates for each category or sub-category may be updated, modified, or created. Before a template is added or modified in a template library, an administrator of the MNO may have the option to approve, edit, or delete the modifications or new template.

Going forward, the feedback on the slice created at block520and the slice parameters the client was ultimately happy with are used to create or modify a slice template for the future such that a future client desirous of operating in the same category or sub-category of service as the client can leverage the created or modified template.

The methods, systems, and devices discussed above are examples. Various configurations may omit, substitute, or add various procedures or components as appropriate. For instance, in alternative configurations, the methods may be performed in an order different from that described, and/or various stages may be added, omitted, and/or combined. Also, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of the configurations may be combined in a similar manner. Also, technology evolves and, thus, many of the elements are examples and do not limit the scope of the disclosure or claims.

Specific details are given in the description to provide a thorough understanding of example configurations (including implementations). However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the configurations. This description provides example configurations only, and does not limit the scope, applicability, or configurations of the claims. Rather, the preceding description of the configurations will provide those skilled in the art with an enabling description for implementing described techniques. Various changes may be made in the function and arrangement of elements without departing from the spirit or scope of the disclosure.

Also, configurations may be described as a process which is depicted as a flow diagram or block diagram. Although each may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may have additional steps not included in the figure. Furthermore, examples of the methods may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a non-transitory computer-readable medium such as a storage medium. Processors may perform the described tasks.

Having described several example configurations, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may be components of a larger system, wherein other rules may take precedence over or otherwise modify the application of the invention. Also, a number of steps may be undertaken before, during, or after the above elements are considered.