Feasibility assessment of network slicing for latency-based Service Level Agreement (SLA)

Abstract

This disclosure provides systems, methods, apparatus, and devices for evaluating the feasibility of network slicing based on latency-based Service Level Agreements (SLAs), including computer programs encoded on a computer storage medium. Some aspects involve providing on-demand approval or rejection of network slice requests at the device based on a latency threshold associated with the SLA of the requested network slice. In some embodiments, the device may receive load information associated with the requested network slice. The device may select resource allocation for the network slice based on the latency threshold and the load information. In some embodiments, the device may output an indication to accept or reject the network request based on resource allocation. In some embodiments, the device may use one or more machine learning (ML) models to select to accept or reject the network slice request, select resource allocation, or both.

Description

[0001] Priority information

[0002] This patent application claims priority to U.S. Patent Application No. 18 / 425,987, filed January 29, 2024, entitled “NETWORK SLICEFEASIBILITY ASSESSMENT FOR A LATENCY-BASED SERVICE LEVEL AGREEMENT (SLA),” which is assigned to the assignee of this application and is expressly incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure relates to wireless communications, and more specifically to a network slicing feasibility assessment for a latency-based Service Level Agreement (SLA). Background Technology

[0004] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, message sending and receiving, and broadcasting. These systems can support communication with multiple users by sharing available system resources, such as time, frequency, and power. Examples of such multiple access systems include fourth-generation (4G) systems (such as Long Term Evolution (LTE) systems, LTE-A Advanced (LTE-A) systems, or LTE-A Pro systems) and fifth-generation (5G) systems (which may be referred to as New Radio (NR) systems). These systems can employ technologies such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), or Discrete Fourier Transform Extended Orthogonal Frequency Division Multiplexing (DFT-s-OFDM). A wireless multiple access communication system may include one or more base stations (BSs) or one or more network access nodes, each of which simultaneously supports communication for multiple communication devices, which may also be referred to as User Equipment (UEs). Summary of the Invention

[0005] The systems, methods, and apparatus disclosed herein each have some innovative aspects, and no single aspect is solely responsible for the desired properties disclosed herein.

[0006] One innovative aspect of the subject matter described in this disclosure can be implemented in an apparatus associated with service management of a wireless network. The apparatus may include a processing system comprising processor circuitry and memory circuitry storing code. The processing system may be configured to cause the apparatus to: obtain a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with a Service Level Agreement (SLA) for the network slice; and obtain load information associated with the network slice of the wireless network. The processing system may be further configured to cause the apparatus to: select a Physical Resource Block (PRB) allocation for the network slice based on the latency threshold and the load information; and output an indication to a Network Slice Management Function (NSMF) and, based on the PRB allocation for the network slice, to accept or reject the request associated with the network slice.

[0007] Another innovative aspect of the subject matter described in this disclosure can be implemented in a method for network slice management of a wireless network. The method may include: receiving a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with the SLA of the network slice; and receiving load information associated with the network slice of the wireless network. The method may further include: selecting a PRB allocation for the network slice based on the latency threshold and the load information; and sending an indication to the NSMF and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

[0008] Another innovative aspect of the subject matter described in this disclosure can be implemented in a device associated with service management of a wireless network. The device may include: one or more memories storing processor-executable code; and one or more processors coupled to the memories. The one or more processors may operate individually or jointly to execute the code to cause the device to: obtain a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with the SLA of the network slice; and obtain load information associated with the network slice of the wireless network. The one or more processors may further operate individually or jointly to execute the code to cause the device to: select a PRB allocation for the network slice based on the latency threshold and the load information; and output an indication to the NSMF and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented in an apparatus associated with service management of a wireless network. The apparatus may include: components for receiving a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with the SLA of the network slice; and components for receiving load information associated with the network slice of the wireless network. The apparatus may further include: components for selecting a PRB allocation for the network slice based on the latency threshold and the load information; and components for sending an indication to the NSMF and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented in a non-transitory computer-readable medium storing code for network slice management in a wireless network. The code may include instructions executable by a processing system to: obtain a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with the SLA of the network slice; and obtain load information associated with the network slice of the wireless network. The code may also include instructions executable by the processing system to: select a PRB allocation for the network slice based on the latency threshold and the load information; and output an indication to the NSMF and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

[0011] In some specific implementations, the request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice, and the PRB allocation of the network slice is further selected based on the throughput threshold.

[0012] In some implementations, the device, method, and non-transitory computer-readable medium may include operations, features, components, or instructions for performing the following actions: selecting a corresponding PRB allocation for each cell in a set of cells of the wireless network associated with the network slice, based on the PRB allocation of the network slice, wherein the indication for accepting or rejecting the request associated with the network slice can be based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation for the network slice of each cell in the set of cells.

[0013] Details of one or more specific embodiments of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. It should be noted that the relative dimensions in the following drawings may not be drawn to scale. Attached Figure Description

[0014] Figure 1An example wireless communication system supporting network slicing feasibility assessment for latency-based Service Level Agreements (SLAs) is shown.

[0015] Figure 2 and Figure 3 An example network architecture supporting network slicing feasibility evaluation for latency-based SLAs is shown.

[0016] Figure 4 An example network framework supporting network slicing feasibility evaluation for latency-based SLAs is shown.

[0017] Figure 5 An example network architecture supporting network slicing feasibility evaluation for latency-based SLAs is shown.

[0018] Figure 6 An example slice coverage area supporting network slice feasibility evaluation for latency-based SLAs is shown.

[0019] Figure 7 A block diagram of an example machine learning (ML) model represented by an artificial neural network (ANN) that supports network slice feasibility evaluation for latency-based SLAs is shown.

[0020] Figure 8 A block diagram of an example ML architecture supporting network slicing feasibility evaluation for latency-based SLAs is shown.

[0021] Figure 9 A block diagram of an example device supporting network slicing feasibility evaluation for latency-based SLAs is shown.

[0022] Figure 10 A flowchart illustrating a method for evaluating the feasibility of network slicing for latency-based SLAs is shown.

[0023] Similar reference numerals and names in the various figures indicate similar elements. Detailed Implementation

[0024] For the purpose of describing the innovative aspects of this disclosure, the following description relates to some specific implementations. However, those skilled in the art will readily recognize that the teachings herein can be applied in a variety of different ways. The specific implementations described can be implemented in any device, system, or network capable of transmitting and receiving radio frequency (RF) signals according to any one of the following IEEE 16.11 standards: IEEE 802.11, Bluetooth, etc. ®Standard, Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Global System for Mobile Communications (GSM), GSM or General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunking Radio (TETRA), Wideband-CDMA (W-CDMA), Evolved Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High-Speed ​​Packet Access (HSPA), High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), Evolved High-Speed ​​Packet Access (HSPA+), Long Term Evolution (LTE), AMPS, or other known signals used for communication in wireless, cellular, or Internet of Things (IoT) networks, such as systems utilizing third-generation (3G), fourth-generation (4G), fifth-generation (5G), or sixth-generation (6G) technologies or other specific implementations thereof.

[0025] The various aspects collectively involve providing the approval or rejection of network slice requests associated with latency-sensitive service level agreements (SLAs). Some aspects more specifically involve a device for receiving requests for network slices (such as new or updated network slices), where the request indicates a latency threshold for the SLA of the requested network slice. In some aspects, the device may additionally receive load information associated with the requested network slice, where the load information may include the number of simulated or observed users (such as user equipment (UE), IoT devices, vehicle-to-everything (V2X) entities, augmented reality / virtual reality / extended reality (AR / VR / XR) devices, sensors, or any combination of these or other network consumers) served by the cells of the requested network slice. In some specific implementations, the device may select (such as predicting, calculating, estimating, identifying, or otherwise determining) a Physical Resource Block (PRB) allocation for the requested network slice based on (e.g., to satisfy) the latency threshold associated with the SLA and the load information. For example, the device may select a suitable PRB allocation for each cell of the requested network slice. The device may perform a feasibility assessment for the network slice request based on the PRB allocation. In some aspects, feasibility assessment may involve evaluating whether the coverage area of ​​the requested network slice can support (e.g., meet) the latency threshold associated with the SLA of the requested network slice. In some implementations, feasibility assessment may involve the device selecting (e.g., predicting, calculating, identifying, or otherwise determining) to approve or reject the network slice request based on the PRB allocation. The device may output an indication to the Network Slice Management Function (NSMF) to accept or reject the network slice request. In some aspects, the device may be associated with the NSMF, Multi-Domain Orchestrator (MDO), MDO and Inventory (MDOI), Network Slice Subnet Management Function (NSSMF), Radio Access Network (RAN) Domain Orchestrator (DO), Service Management and Orchestration (SMO), or some combination thereof (e.g., may be a component of them or otherwise perform functionality associated with them). In some implementations, the NSMF may accept or reject the network slice request based on the indication output by the device. In some implementations, the SLA of the requested network slice may additionally indicate the throughput parameters (such as throughput thresholds) of the requested network slice. In some respects, an SLA may specify uplink latency thresholds, downlink latency thresholds, end-to-end latency thresholds (such as those including core transmission and RAN latency components), uplink throughput thresholds, downlink throughput thresholds, or any combination of these or other SLA characteristics for the requested network slice.

[0026] In some implementations, the device may use one or more machine learning (ML) models to select the PRB allocation for a requested network slice, to choose whether to accept or reject the network slice request, or both. In some aspects, the device may use a first ML model to select the PRB allocation for the network slice, a second ML model to choose whether to accept or reject the network slice request, or both. In some implementations, the ML model may be an example of an artificial intelligence (AI) model, an artificial neural network (ANN), or any other program, engine, algorithm, or system that uses ML or AI technologies. In some aspects, the device may train (e.g., configure) the ML model to output the PRB allocation for the network slice. In some implementations, the device may use a collection of multiple network snapshots to train the ML model. A network snapshot may be an example of a specific set of network parameters, such as load information, radio frequency (RF) conditions, traffic patterns, network infrastructure (such as the physical location of cells and cell coverage areas), or any combination of these or other parameters, and the resulting network latency. In some aspects, latency may be an example of air interface latency (such as air latency) used for wireless communication. The device can train an ML model to receive a set of network parameters for a network slice (such as corresponding to a network snapshot) and a latency threshold as input, and output a corresponding number of PRBs (such as PRB allocation for one or more cells) to support the network slice. In some implementations, the device can train an ML model or another ML model to receive the set of network parameters for a network slice, a latency threshold, the number of PRBs, or any combination thereof as input, and output an indication of accepting or rejecting a network slice request associated with the network slice and the latency threshold. In some aspects, the device can accept or reject a network slice request based on whether the NSSMF or RAN-DO can allocate a number of PRBs to the cells of the network slice to meet the latency threshold (such as in the case of simulated or observed network parameters for a given network slice).

[0027] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some specific implementations, by selecting the PRB allocation for a requested network slice, the device can determine (or otherwise evaluate, select, or predict) the number of PRBs to be added to the network slice to support the latency components (such as latency thresholds) of the SLA. Therefore, the device can provide accurate empirical resource allocation predictions, which can allow, enable, or otherwise facilitate more efficient spectrum use in network slice configurations. Additionally or alternatively, by using one or more techniques (such as feasibility assessment or ML models), the device can accurately evaluate spectrum components (such as the number of PRBs) to support latency thresholds associated with the SLA. In some aspects, mobile network operators (MNOs) can use such evaluations to perform network design, thereby supporting accurate cost analysis (such as from a spectrum perspective) associated with providing different network slice implementations (such as different types of network slices, different network slice parameters, different SLAs, different MNO slicing strategies, or any combination thereof) to different users, customers, enterprises, or other entities. Additionally or alternatively, if the spectrum can support the PRB allocation determined for the slice request, the MNO can use such evaluation to ensure the approval of the slice request. In some implementations, after the network slice is activated, the MNO can mitigate or otherwise avoid network slice violations (such as latency violations defined by the latency threshold of the SLA) by accurately determining the PRB allocation to support the network slice based on a latency threshold without violations. In some implementations, the device can evaluate the profitability of the network slice request based on the PRB allocation of the selected network slice. In some implementations, the device can consider the number of users (such as simulated users or observed users) served by the network slice by using load information. In some aspects, the device can support the automatic configuration of one or more parameters of the network slice configuration. For example, the device can support automatic approval or rejection of network slice requests, automatic configuration of the PRB of the requested network slice, or both. In some specific implementations, based on the approval or rejection of requested network slices as described herein, the device can allow a user or MNO to adjust one or more evaluation thresholds to network-specific performance. This provides greater flexibility and finer-grained control over whether and how a requested network slice is admitted. Based on such timely prediction, more efficient spectrum use (which can be understood as higher spectral efficiency), greater flexibility, and finer-grained control, the described techniques can be further implemented to achieve, reach, or support higher data rates, greater system capacity, improved latency, higher reliability, and other benefits.

[0028] Figure 1An example wireless communication system 100 supporting network slicing feasibility assessment for latency-based SLAs is illustrated. Wireless communication system 100 may include one or more network entities 105, one or more UEs 115, and a core network 130. In some implementations, wireless communication system 100 may be a Long Term Evolution (LTE) network, an Advanced LTE (LTE-A) network, an LTE-A Pro network, a New Radio (NR) network, or a network operating under other systems and radio technologies, including future systems and radio technologies not explicitly mentioned herein.

[0029] Network entity 105 may be distributed across a geographical area to form wireless communication system 100, and may include devices employing different forms or having different capabilities. In various examples, network entity 105 may be referred to as a network element, mobility element, RAN node, or network equipment, among other designations. In some specific implementations, network entity 105 and UE 115 may wirelessly communicate via one or more communication links 125 (such as radio frequency (RF) access links). For example, network entity 105 may support a coverage area 110 (such as a geographical coverage area) over which UE 115 and network entity 105 may establish one or more communication links 125. Coverage area 110 may be an example of a geographical area in which network entity 105 and UE 115 may support the transmission of signals according to one or more radio access technologies (RATs).

[0030] UE 115 can be distributed throughout the coverage area 110 of the wireless communication system 100, and each UE 115 can be stationary or mobile, or stationary and mobile at different times. UE 115 can be a device in different forms or with different capabilities. Figure 1 Some example UE 115s are illustrated herein. The UE 115 described herein can be able to support various types of devices (such as...) Figure 1 It communicates with other UEs (115 or network entity 105) as shown.

[0031] As described herein, a node of the wireless communication system 100 (which may be referred to as a network node or wireless node) may be a network entity 105 (such as any network entity described herein), a UE 115 (such as any UE described herein), a network controller, apparatus, device, computing system, one or more components, or another suitable processing entity configured to perform any of the techniques described herein. For example, a node may be UE 115. As another example, a node may be network entity 105. As another example, a first node may be configured to communicate with a second node or a third node. In one aspect of this example, the first node may be UE 115, the second node may be network entity 105, and the third node may be UE 115. In another aspect of this example, the first node may be UE 115, the second node may be network entity 105, and the third node may be network entity 105. In other aspects of this example, the first node, the second node, and the third node may be different from these examples. Similarly, references to UE 115, network entity 105, device, equipment, computing system, etc., may include disclosures of UE 115, network entity 105, device, equipment, computing system, etc., as nodes. For example, a disclosure that UE 115 is configured to receive information from network entity 105 also discloses that a first node is configured to receive information from a second node.

[0032] In some implementations, network entity 105 may communicate with core network 130, communicate with each other, or both. For example, network entity 105 may communicate with core network 130 via one or more backhaul communication links 120 (such as according to S1, N2, N3, or other interface protocols). In some implementations, network entities 105 may communicate with each other directly (such as directly between network entities 105) or indirectly (such as via core network 130) via backhaul communication links 120 (such as according to X2, Xn, or other interface protocols). In some implementations, network entities 105 may communicate with each other via midhaul communication link 162 (such as according to midhaul interface protocol) or fronthaul communication link 168 (such as according to fronthaul interface protocol) or any combination thereof. Backhaul communication link 120, midhaul communication link 162, or fronthaul communication link 168 may be or include one or more wired links (such as electrical links, fiber optic links), one or more wireless links (such as radio links, wireless optical links), etc., or various combinations thereof. UE 115 can communicate with core network 130 via communication link 155.

[0033] One or more network entities in the network entity 105 described herein may include or be referred to as base station (BS) 140 (such as transceiver base station, radio BS, NR BS, access point, radio transceiver, node B, evolved Node B (eNB), next-generation Node B or gigabit Node B (any of which may be referred to as gNB), 5G NB, next-generation eNB (ng-eNB), home node B, home evolved Node B or other suitable terms). In some specific implementations, network entity 105 (such as BS 140) may be implemented in a converged (such as monolithic, standalone) BS architecture that may be configured to utilize a protocol stack physically or logically integrated within a single network entity 105 (such as a single RAN node, such as BS 140).

[0034] In some specific implementations, network entity 105 may be implemented in a decomposed architecture (such as a decomposed BS architecture or a decomposed RAN architecture), which may be configured to utilize a protocol stack physically or logically distributed between two or more network entities 105 (such as an Integrated Access Backhaul (IAB) network, an Open RAN (O-RAN) (such as a network configuration sponsored by the O-RAN Alliance), or a Virtualized RAN (vRAN) (such as a Cloud RAN (C-RAN)). For example, network entity 105 may include one or more of the following: a Central Unit (CU) 160, a Distributed Unit (DU) 165, a Radio Unit (RU) 170, a RAN Intelligent Controller (RIC) 175 (such as a near real-time RIC (near RT RIC), a non-real-time RIC (non-RT RIC)), a Service Management and Orchestration (SMO) 180 system, or any combination thereof. RU 170 may also be referred to as a radio headend, an intelligent radio headend, a remote radio headend (RRH), a remote radio unit (RRU), or a transmit-receive point (TRP). One or more components of network entity 105 in a decomposed RAN architecture may be co-located, or one or more components of network entity 105 may be located in distributed locations (such as separate physical locations). In some implementations, one or more network entities 105 in a decomposed RAN architecture may be implemented as virtual units (such as virtual CU (VCU), virtual DU (VDU), virtual RU (VRU)).

[0035] The functional splitting among CU 160, DU 165, and RU 170 is flexible and can support different functionalities depending on which functions (such as network layer functions, protocol layer functions, baseband functions, RF functions, and any combination thereof) are performed at CU 160, DU 165, and RU 170. For example, a protocol stack functional splitting can be used between CU 160 and DU 165, allowing CU 160 to support one or more layers of the protocol stack, and DU 165 to support one or more different layers of the protocol stack. In some implementations, CU 160 can host higher protocol layer (such as Layer 3 (L3), Layer 2 (L2)) functionalities and signaling (such as Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP)). The CU160 can be connected to one or more DU 165s or RU 170s, and these DU 165s or RU 170s can host lower protocol layers, such as Layer 1 (L1) (e.g., the Physical (PHY) layer) or L2 (e.g., the Radio Link Control (RLC) layer, Medium Access Control (MAC) layer) functionalities and signaling, and each can be at least partially controlled by the CU 160. Additionally or alternatively, a functional split of the protocol stack can be employed between the DU 165 and RU 170, such that the DU 165 can support one or more layers of the protocol stack, and the RU 170 can support one or more different layers of the protocol stack. The DU 165 can support one or more different cells (e.g., via one or more RU 170s). In some specific implementations, functional decomposition between CU 160 and DU 165, or between DU 165 and RU 170, can be within the protocol layer (e.g., some functions of the protocol layer can be performed by one of CU 160, DU 165, or RU 170, while other functions of the protocol layer can be performed by a different one of CU 160, DU 165, or RU 170). CU 160 can be further functionally decomposed into CU control plane (CU-CP) functions and CU user plane (CU-UP) functions. CU 160 can be connected to one or more DU 165 via midhaul communication link 162 (such as F1, F1-c, F1-u), and DU 165 can be connected to one or more RU 170 via fronthaul communication link 168 (such as an open fronthaul (FH) interface). In some specific implementations, the midhaul communication link 162 or the fronthaul communication link 168 can be implemented based on the interfaces (such as channels) between the layers of the protocol stack, each layer of which is supported by the corresponding network entity 105 communicating via such communication links.

[0036] In some wireless communication systems (such as wireless communication system 100), the infrastructure and spectrum resources for radio access can support wireless backhaul link capabilities to supplement wired backhaul connections, thereby providing an IAB network architecture (such as to core network 130). In some specific implementations, in an IAB network, one or more network entities 105 (such as IAB node 104) may be partially controlled by each other. One or more IAB nodes 104 may be referred to as donor entities or IAB donors. One or more DU 165s or one or more RU 170s may be partially controlled by one or more CU 160s associated with donor network entities 105 (such as donor BS 140). One or more donor network entities 105 (such as IAB donors) may communicate with one or more additional network entities 105 (such as IAB node 104) via supported access and backhaul links (such as backhaul communication link 120). IAB node 104 may include an IAB mobile termination (IAB-MT) controlled (e.g., scheduled) by a DU 165 of a coupled IAB donor. The IAB-MT may include a separate set of antennas for relaying communication with UE 115, or may share the same antennas (e.g., RU170) of IAB node 104 for access via the DU 165 (e.g., referred to as a virtual IAB-MT (vIAB-MT)). In some implementations, IAB node 104 may include a DU 165 that supports communication links with additional entities (e.g., IAB node 104, UE 115) within a relay chain or configuration (e.g., downstream) of the access network. In such implementations, one or more components of the decomposed RAN architecture (e.g., one or more IAB nodes 104 or components of IAB node 104) may be configured to operate according to the techniques described herein.

[0037] In a specific implementation of the techniques described herein within the context of a decomposed RAN architecture, one or more components of the decomposed RAN architecture can be configured to support network slicing feasibility assessments for latency-based SLAs as described herein. For example, some operations described as being performed by UE 115 or network entity 105 (such as BS 140) may additionally or alternatively be performed by one or more components of the decomposed RAN architecture (such as IAB node 104, DU 165, CU 160, RU 170, RIC 175, SMO 180).

[0038] UE 115 may include or be referred to as a mobile device, wireless device, remote device, handheld device, or user equipment, or some other suitable term, wherein "device" may also be referred to as a cell, station, terminal, or client, etc. UE 115 may also include or be referred to as a personal electronic device, such as a cellular phone, personal digital assistant (PDA), tablet computer, laptop computer, or personal computer. In some implementations, UE 115 may include or be referred to as a wireless local loop (WLL) station, Internet of Things (IoT) device, Internet of Everything (IoE) device, or machine-type communication (MTC) device, etc., which may be implemented in various objects such as electrical appliances or vehicles, instruments, etc.

[0039] like Figure 1 As shown, the UE 115 described herein can communicate with various types of devices, such as other UE 115s that may sometimes act as repeaters, as well as network entities 105 and network equipment, including macro eNBs or gNBs, small cell eNBs or gNBs, or relay BSs, etc.

[0040] UE 115 and network entity 105 can wirelessly communicate with each other via one or more communication links 125 (such as access links) using resources associated with one or more carriers. The term "carrier" can refer to a set of RF spectrum resources having a defined physical layer structure for supporting communication link 125. For example, a carrier for communication link 125 may include a portion of an RF spectrum band (such as a bandwidth portion (BWP)) that operates according to one or more physical layer channels for a given radio access technology (such as LTE, LTE-A, LTE-A Pro, NR). Each physical layer channel may carry acquisition signaling (such as synchronization signals, system information), control signaling coordinating carrier operation, user data, or other signaling. Wireless communication system 100 can support communication with UE 115 using carrier aggregation or multi-carrier operation. Depending on the carrier aggregation configuration, UE 115 may be configured with multiple downlink component carriers and one or more uplink component carriers. Carrier aggregation can be used in conjunction with both frequency division duplex (FDD) component carriers and time division duplex (TDD) component carriers. Communication between network entity 105 and other devices can refer to communication between these devices and any part of network entity 105 (such as entity, sub-entity). For example, the terms “send,” “receive,” or “communicate” when referring to network entity 105 can refer to any part of the RAN network entity 105 (such as BS140, CU 160, DU 165, RU 170) communicating with another device (such as directly or via one or more other network entities 105).

[0041] The signal waveform transmitted via a carrier can consist of multiple subcarriers (e.g., using multi-carrier modulation (MCM) techniques, such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform extended OFDM (DFT-S-OFDM)). In systems employing MCM, a resource element can refer to a symbol period (e.g., the duration of a modulation symbol) and a subcarrier resource, where the symbol period and subcarrier spacing can be inversely related. The number of bits carried by each resource element can depend on the modulation scheme (e.g., the order of the modulation scheme, the decoding rate of the modulation scheme, or both), such that a relatively higher number of resource elements (e.g., in the transmission duration) and a relatively higher order modulation scheme can correspond to a relatively higher communication rate. Wireless communication resources can refer to a combination of RF spectrum resources, temporal resources, and spatial resources (e.g., spatial layers or beams), and the use of multiple spatial resources can improve the data rate or data integrity of communication with UE 115.

[0042] The time interval for network entity 105 or UE 115 can be expressed as a multiple of the basic time unit. In some specific implementations, the basic time unit may refer to the sampling period. seconds, of which This can represent the supported subcarrier spacing, while The supported Discrete Fourier Transform (DFT) size can be represented. The time interval of the communication resources can be organized according to radio frames, each with a specific duration (such as 10 milliseconds (ms)). Each radio frame can be identified by a System Frame Number (SFN) (such as ranging from 0 to 1023).

[0043] Each frame may include multiple consecutively numbered subframes or time slots, and each subframe or time slot may have the same duration. In some implementations, a frame may be divided into subframes (e.g., in the time domain), and each subframe may be further divided into a number of time slots. Alternatively, each frame may include a variable number of time slots, and the number of time slots may depend on the subcarrier spacing. Each time slot may include a number of symbol periods (e.g., this depends on the length of the cyclic prefix added before each symbol period). In some wireless communication systems 100, time slots may be further divided into multiple micro-time slots associated with one or more symbols. Excluding the cyclic prefix, each symbol period may be associated with one or more (such as...) The duration of a symbol period is associated with a (number) sampling period. The duration of a symbol period can depend on the subcarrier spacing or the operating frequency band.

[0044] A subframe, time slot, micro-time slot, or symbol may be the smallest scheduling unit of the wireless communication system 100 (e.g., in the time domain) and may be referred to as a transmission time interval (TTI). In some specific implementations, the duration of the TTI (e.g., the number of symbol periods in the TTI) may be variable. Additionally or alternatively, the smallest scheduling unit of the wireless communication system 100 may be dynamically selected (e.g., in bursts of shortened TTIs (sTTIs)).

[0045] Depending on the technology, carriers can be used to multiplex physical channels for communication. For example, one or more of Time Division Multiplexing (TDM), Frequency Division Multiplexing (FDM), or hybrid TDM-FDM techniques can be used to multiplex physical control channels and physical data channels for signaling via a downlink carrier. Control regions (such as control resource sets (CORESET)) used for physical control channels can be defined by a set of symbol periods and can extend across the system bandwidth or a subset of the system bandwidth of the carrier. One or more control regions (such as CORESET) can be configured for a set in UE 115. For example, one or more UEs in UE 115 can monitor or search control regions to obtain control information based on one or more search space sets, and each search space set can include one or more control channel candidates in one or more aggregation levels arranged in a concatenated manner. The aggregation level of control channel candidates can refer to the number of control channel resources (such as control channel elements (CCE)) associated with coded information for a control information format having a given payload size. The search space set may include: a common search space set configured to transmit control information to multiple UEs 115, and a UE-specific search space set used to transmit control information to a specific UE 115.

[0046] In some implementations, network entity 105 (such as BS 140, RU 170) may be mobile, and thus provide communication coverage to mobile coverage areas 110. In some implementations, while different coverage areas 110 associated with different technologies may overlap, different coverage areas 110 may be supported by the same network entity 105. In some other implementations, overlapping coverage areas 110 associated with different technologies may be supported by different network entities 105. The wireless communication system 100 may include, for example, a heterogeneous network in which different types of network entities 105 use the same or different radio access technologies to provide coverage for various coverage areas 110.

[0047] Wireless communication system 100 may be configured to support ultra-reliable communication or low-latency communication, or various combinations thereof. For example, wireless communication system 100 may be configured to support ultra-reliable low-latency communication (URLLC). UE 115 may be designed to support ultra-reliable, low-latency, or critical functions. Ultra-reliable communication may include private or group communication and may be supported by one or more services, such as push-to-talk, video, or data. Support for ultra-reliable, low-latency functions may include prioritizing services, and such services may be used for public safety or general business applications. The terms “ultra-reliable,” “low-latency,” and “ultra-reliable low-latency” are used interchangeably herein.

[0048] In some implementations, UE 115 may be configured to support direct communication with other UE 115s via device-to-device (D2D) communication links 135, such as according to peer-to-peer (P2P), D2D, or sidelink protocols. In some implementations, one or more UE 115s performing D2D communication in a group may be within the coverage area 110 of a network entity 105 (such as BS 140, RU 170) that supports various aspects of such D2D communication configured (e.g., scheduled) by the network entity 105. In some implementations, one or more UE 115s in such a group may be outside the coverage area 110 of the network entity 105, or otherwise may be unable or not configured to receive transmissions from the network entity 105. In some implementations, a group of UE 115s communicating via D2D communication may support a one-to-many (1:M) system, where each UE 115 transmits to every other UE 115 in the group. In some implementations, network entity 105 may facilitate the scheduling of resources for D2D communication. In other implementations, D2D communication may be performed between UEs 115 without involving network entity 105.

[0049] Core network 130 provides user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. Core network 130 can be an evolved packet core (EPC) or a 5G core (5GC), which may include at least one control plane entity (such as a Mobility Management Entity (MME), Access and Mobility Management Function (AMF)) managing access and mobility, and at least one user plane entity (such as a Serving Gateway (S-GW), Packet Data Network (PDN) Gateway (P-GW), or User Plane Function (UPF)) routing packets or interconnecting to external networks. The control plane entity manages non-access stratum (NAS) functions, such as mobility, authentication, and bearer management of UE 115 served by network entity 105 (such as BS 140) associated with core network 130. User IP packets can be delivered through user plane entities, which provide IP address allocation and other functions. User plane entities can connect to one or more network operator IP services 150. IP services 150 may include access to the Internet, intranets, IP Multimedia Subsystem (IMS), or packet-switched streaming services.

[0050] Wireless communication system 100 can operate using one or more frequency bands in the range of 300 MHz to 300 GHz. Generally, the area from 300 MHz to 3 GHz is referred to as the Ultra High Frequency (UHF) band or decimeter band because the wavelength range is approximately one decimeter to one meter in length. UHF waves may be blocked or redirected by buildings and environmental features (which may be referred to as clusters), but these waves are sufficient to penetrate structures so that macrocells can provide service to UE 115 located indoors. Compared to communication using smaller frequencies and longer waves in the lower frequencies (HF) or very high frequencies (VHF) portions of the spectrum below 300 MHz, communication using UHF waves can be associated with smaller antennas and shorter ranges (such as less than 100 kilometers).

[0051] Wireless communication system 100 can utilize both licensed and unlicensed RF spectrum bands. For example, wireless communication system 100 can use unlicensed frequency bands (such as the 5 GHz Industrial, Scientific, and Medical (ISM) band) to employ Licensed Assisted Access (LAA), LTE Unlicensed (LTE-U) radio access technology, or NR technology. When operating with unlicensed RF spectrum, devices such as network entity 105 and UE 115 can employ carrier sensing for collision detection and avoidance. In some implementations, operation using unlicensed frequency bands can be coordinated with component carriers operating with licensed frequency bands (such as LAA) to conform to carrier aggregation configurations. Operation using unlicensed spectrum can include downlink transmission, uplink transmission, P2P transmission, or D2D transmission, etc.

[0052] Network entity 105 (such as BS 140, RU 170) or UE 115 may be equipped with multiple antennas that can be used to employ techniques such as transmit diversity, receive diversity, multiple-input multiple-output (MIMO) communication, or beamforming. The antennas of network entity 105 or UE 115 may be located within one or more antenna arrays or antenna panels, which can support MIMO operation or transmit or receive beamforming. For example, one or more BS antennas or antenna arrays may be co-located at an antenna assembly (such as an antenna tower). In some implementations, the antennas or antenna arrays associated with network entity 105 may be located at different geographical locations. Network entity 105 may include an antenna array having a collection of multiple rows and columns of antenna ports that network entity 105 can use to support beamforming for communication with UE 115. Similarly, UE 115 may include one or more antenna arrays that can support various MIMO or beamforming operations. Additionally or alternatively, the antenna panel may support RF beamforming for signals transmitted via the antenna ports.

[0053] Beamforming (also known as spatial filtering, directional transmission, or directional reception) is a signal processing technique that can be used at a transmitting or receiving device (such as network entity 105, UE 115) to shape or guide an antenna beam (such as a transmit beam, receive beam) along a spatial path between the transmitting and receiving devices. Beamforming can be achieved by combining signals transmitted via antenna elements of an antenna array such that some signals propagating along a specific orientation relative to the antenna array experience constructive interference, while other signals experience destructive interference. Adjustments to the signals transmitted via the antenna elements may include applying amplitude shifts, phase shifts, or both to the signals carried via the antenna elements associated with the device by the transmitting or receiving device. The adjustments associated with each antenna element can be defined by a set of beamforming weights associated with a specific orientation (such as the antenna array relative to the transmitting or receiving device, or relative to some other orientation).

[0054] The wireless communication system 100 can be a packet-based network operating according to a layered protocol stack. In the user plane, communication at the bearer or PDCP layer can be IP-based. The RLC layer can perform packet segmentation and reassembly for transmission via logical channels. The MAC layer can perform priority handling and multiplexing of logical channels to transport channels. The MAC layer can also use error detection, error correction, or both to support retransmission to improve link efficiency. In the control plane, the RRC layer can provide the establishment, configuration, and maintenance of RRC connections between the UE 115 and network entity 105 or core network 130 that support user plane data radio bearers. The PHY layer can map transport channels to physical channels.

[0055] UE 115 and network entity 105 can support data retransmission to increase the likelihood of successful data reception. Hybrid Automatic Repeat Request (HARQ) feedback is a technique used to increase the likelihood of correctly receiving data via communication links such as communication link 125 and D2D communication link 135. HARQ may include a combination of error detection (e.g., using Cyclic Redundancy Check (CRC)), forward error correction (FEC), and retransmission (e.g., Automatic Repeat Request (ARQ)). HARQ can improve MAC layer throughput in adverse radio conditions such as low signal-to-noise ratio conditions. In some implementations, the device may support same-slot HARQ feedback, where the device can provide HARQ feedback in a specific time slot for data received via previous symbols in that time slot. In some other implementations, the device may provide HARQ feedback in subsequent time slots or according to a different time interval.

[0056] In some aspects, the wireless communication system 100 may support one or more signaling-based or configuration-based mechanisms associated with network slice management. For example, the wireless communication system 100 may support one or more network slices and may dynamically (e.g., on demand) add new network slices based on resource availability within the wireless communication system 100. In some implementations, one or more devices, components, entities, or functionalities of the wireless communication system 100 (such as network entity 105 or any one or more components, entities, or functionalities of network entity 105) may support an automated slice feasibility assessment as part of RAN orchestration, based on which a requested network slice may be approved (e.g., admitted and implemented) or rejected.

[0057] In some implementations, one or more devices, components, entities, or functionalities associated with the network platform (such as a part thereof) can perform automated slice feasibility assessments. Additionally or alternatively, automated slice configuration capabilities may be included in the network platform. In some implementations, network automation may support slice configuration capabilities, feasibility checks and resource allocation processes associated with the NSSMF Representative State Transmission (REST) ​​application programming interface (API), programmable policies associated with MNO design, or any combination thereof.

[0058] In some aspects, NSSMF REST API support may include or be associated with Lifecycle Management (LCM) supported actions from "assignment / activation" to "deactivation / deletion," as well as status updates associated with different operations. Feasibility checks and resource allocation processes may include or be associated with vendor-agnostic computational processes and feasibility assessments based on a comparison of measured resource (such as PRB) utilization with projected resource (such as PRB) utilization. Programmable policies associated with MNO design may include or be associated with a programmable engine for provisioning, which can translate MNO policies into RAN parameters. Therefore, according to the example implementations described herein, one or more devices, components, entities, or functionalities of the wireless communication system 100 can implement automated slicing feasibility assessments in a dynamic and on-demand manner, which can meet one or more latency targets, throughput targets, or some combination thereof associated with the SLA of a network slicing request, promoting greater data rates and higher reliability, and supporting higher spectral efficiency and other benefits.

[0059] Figure 2 An example network architecture 200 supporting network slicing feasibility assessment for latency-based SLAs is shown. Network architecture 200 can be an example of a decomposed BS architecture or a decomposed RAN architecture. Network architecture 200 can exemplify one or more aspects for implementing wireless communication system 100. Network architecture 200 may include one or more CUs 160-a that can communicate directly with core network 130-a via backhaul communication link 120-a, or indirectly with core network 130-a via one or more decomposed network entities 105 (such as near-RT RIC 175-b via an E2 link, or non-RT RIC 175-a associated with SMO 180-a (such as an SMO framework), or both). CUs 160-a can communicate with one or more DUs 165-a via corresponding midhaul communication links 162-a (such as F1 interfaces). DUs 165-a can communicate with one or more RUs 170-a via corresponding fronthaul communication links 168-a. RU 170-a may be associated with a corresponding coverage area 110-a and may communicate with UE 115-a via one or more communication links 125-a. In some implementations, UE 115-a may be served by multiple RU 170-a simultaneously.

[0060] Each network entity in network entity 105 of network architecture 200 (such as CU 160-a, DU 165-a, RU170-a, non-RT RIC 175-a, near-RT RIC 175-b, SMO 180-a, Open Cloud (O-Cloud) 205, Open eNB (O-eNB) 210) may include one or more interfaces or may be coupled to one or more interfaces configured to receive or transmit signals (such as data, information) via wired or wireless transmission media. Each network entity 105 or an associated processor (such as a controller) that provides instructions to the interfaces of network entity 105 may be configured to communicate with one or more network entities in other network entities 105 via transmission media. For example, these network entities 105 may include wired interfaces configured to receive signals or transmit signals to one or more network entities in other network entities 105 via wired transmission media. Additionally or alternatively, network entity 105 may include a wireless interface that may include a receiver, transmitter, or transceiver (such as an RF transceiver) configured to receive signals on a wireless transmission medium or to transmit signals on a wireless transmission medium to one or more other network entities 105, or both.

[0061] In some implementations, the CU 160-a can host one or more higher-level control functions. These control functions may include RRC, PDCP, SDAP, etc. Each control function can be implemented using an interface configured to communicate signaling with other control functions hosted by the CU 160-a. The CU 160-a can be configured to handle user plane functions (such as CU-UP), control plane functions (such as CU-CP), or combinations thereof. In some implementations, the CU 160-a can be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units can communicate bidirectionally with the CU-CP units via an interface (such as an E1 interface). The CU 160-a can be implemented to communicate with the DU 165-a for network control and signaling purposes, as needed.

[0062] DU 165-a may correspond to a logic unit that includes one or more functions (such as BS functions, RAN functions) for controlling the operation of one or more RU 170-a. In some implementations, DU 165-a may at least partially host one or more aspects of the RLC layer, MAC layer, and PHY layer (such as high PHY layers, such as modules for FEC encoding and decoding, scrambling, modulation and demodulation, etc.), depending at least in part on the functional partitioning, such as those defined by the 3rd Generation Partnership Project (3GPP). In some implementations, DU 165-a may further host one or more low PHY layers. Each layer may be implemented using an interface configured to communicate with other layers hosted by DU 165-a or with control functions hosted by CU 160-a.

[0063] In some implementations, lower-layer functionality can be implemented by one or more RU 170-a units. For example, an RU 170-a controlled by a DU165-a may correspond to a logical node that hosts RF processing functions or low-PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, etc.) or both, based on functional decomposition such as lower-layer functional decomposition. In such an architecture, the RU 170-a may be implemented to handle over-the-air (OTA) communications with one or more UE 115-a units. In some implementations, the real-time and non-real-time aspects of control plane and user plane communications with the RU 170-a may be controlled by the corresponding DU 165-a unit. In some implementations, such a configuration allows the DU 165-a and CU 160-a to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0064] The SMO 180-a can be configured to support RAN deployment and provisioning of both non-virtualized and virtualized network entities 105. For non-virtualized network entities 105, the SMO 180-a can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via operation and maintenance interfaces such as the O1 interface. For virtualized network entities 105, the SMO 180-a can be configured to interact with cloud computing platforms (such as O-Cloud 205) via cloud computing platform interfaces (such as the O2 interface) to perform network entity lifecycle management (such as instantiating virtualized network entities 105). Such virtualized network entities 105 may include, but are not limited to, CU 160-a, DU 165-a, RU 170-a, and near-RT RIC 175-b. In some specific implementations, the SMO 180-a can communicate (e.g., via the O1 interface) with components configured according to the 4G RAN. Additionally or alternatively, in some implementations, the SMO 180-a may communicate directly with one or more RU 170-a via the O1 interface. The SMO 180-a may also include a non-RT RIC 175-a configured to support the functionality of the SMO 180-a.

[0065] The non-RT RIC 175-a can be configured to include logical functions that enable non-real-time control and optimization of RAN elements and resources, AI or ML workflows (including model training and updates), or policy-based guidance of applications / features in the near-RT RIC 175-b. The non-RT RIC 175-a can be coupled to or communicate with the near-RT RIC 175-b (e.g., via the A1 interface). The near-RT RIC 175-b can be configured to include logical functions that enable near real-time control and optimization of RAN elements and resources via data collection and actions through interfaces (e.g., via the E2 interface) connected to the near-RT RIC 175-b by one or more CU 160-a, one or more DU 165-a, or both, and the O-eNB 210.

[0066] In some implementations, to generate AI / ML models to be deployed in the near-RT RIC 175-b, the non-RT RIC 175-a may receive parameters or external enrichment information from an external server. This information can be utilized by the near-RT RIC 175-b and can be received from non-network data sources or network functions at the SMO 180-a or non-RT RIC 175-a. In some implementations, the non-RT RIC 175-a or near-RT RIC 175-b can be configured to tune RAN behavior or performance. For example, the non-RT RIC 175-a can monitor long-term trends and patterns of performance and employ AI or ML models to perform corrective actions via the SMO 180-a (such as reconfiguration via O1) or via the generation of RAN management policies (such as A1 policies).

[0067] According to the example implementations disclosed herein, one or more devices, components, entities, or functionalities of network architecture 200 can support resource prediction (such as per-cell resource prediction) for a requested network slice based on latency thresholds of the SLA associated with the requested network slice and, in some implementations, observed network conditions at each cell in a set of cells within the coverage area of ​​the requested slice, or across various groups of cells in that set. Based on the obtained resource prediction (such as PRB allocation), the resource prediction can be stored and added to the current (actual) resource utilization at each cell in the envisioned slice coverage area. A scan operation can indicate, in addition to the corresponding current cell load, which cells or groups of cells in the envisioned slice coverage area can accommodate the corresponding predicted resource allocation. Based on (such as a reference) slice admission policy, the requested network slice can be approved or denied based on how many (such as what percentage) cells can accommodate the requested network slice, how many (such as what percentage) of users are expected to be served on the requested network slice, or both.

[0068] Figure 3 An example network architecture 300 supporting network slicing feasibility evaluation for latency-based SLAs is illustrated. The network architecture 300, which can exemplify RAN NSSMF architectures, can be associated with end-to-end (E2E) management and orchestration of network slices. For example, network architecture 300 can be associated with 5G standalone (SA) slice E2E management and orchestration, and can support network slices in different types of RAN deployments, including O-RAN and non-O-RAN deployments.

[0069] Network architecture 300 may include or be supported by various devices, components, entities, or functionalities, including NSMF 302 and SMO 304 (which may interface with one or more open APIs). SMO 304 may include one or more NSSMF functions 306. NSSMF (which can be understood as RAN NSSMF or R-NSSMF) may include or be associated with vendor-agnostic automated slice design, creation, monitoring, and optimization. NSSMF may have a "northbound" interface toward NSMF 302. NSSMF function 306 may include slice configuration functions, slice monitoring and visualization functions (in... Figure 3 (abbreviated as Mon. & Vis. in the example illustrations) and slice optimization and arrangement functions (in Figure 3 In the example, it is abbreviated as Opt. & Orch.

[0070] NSSMF function 306 can also be associated with a slice manager, which can perform operations associated with the integrity and monitoring services. For example, the slice manager can propagate slice status to NSMF 302, expose slice APIs (such as creation, modification, or deactivation), and instantiate the integrity service during slice configuration. The integrity service can support short-cycle integrity checks (based on enhanced cell data), live network trackers (based on whether cells within the observed slice have been altered), and long-cycle integrity checks (based on daily slice policy enforcement). The monitoring service can track active slice SLAs and trigger events (such as activations) to be handled by appropriate applications in cases where SLAs are not met.

[0071] Slice configuration capabilities may include or be associated with the automated configuration of new slices and reconfiguration of existing slices for gNBs from multiple virtualized RAN (vRAN) vendors via a traditional or vRAN Element Management System (EMS) or, in the example, the O1 interface deployed via O-RAN. Slice monitoring and visualization capabilities may include or be associated with monitoring slice SLA key performance indicators (KPIs) based on slice profile attributes at the cell or cluster level, such as latency, throughput, delay, reliability, availability, mobility, activity, or traffic. In scenarios where violations are predicted, slice monitoring and visualization capabilities can trigger slice optimization. Slice optimization and orchestration capabilities may include or be associated with closed-loop optimization based on event-triggered contexts for relevant cells or clusters, as well as resolving SLA violations generated by the SLA monitoring service.

[0072] SMO 304 may also include or be associated with Automation Service 308, RAN Application (rApp) 310 (which may include Slicing Feasibility rApp, Configuration rApp, or General...) nThe SMO 304 includes rApp, Operations Service 312, Non-Real-Time (RT) RAN Intelligent Controller (RIC) 314, Data Service 316, and Operations, Administration and Maintenance (OA&M) Service 318. The SMO 304 may also be associated with one or more Operations Policy, Recipe Service, and Context Service. Data Service 316 and OA&M Service 318 may collectively include or be associated with (e.g., via API exposure) RAN Data Exposure, RAN Data Abstraction, Provisioning Gateway, Inventory, Network Manager, Network Functions Orchestrator (NFO) Interoperability (which may be associated with NFO components that the SMO 304 may expose via API), Performance Management (PM), Configuration Management (CM), Fault Management (FM), and Tracking Management. The SMO 304 may include an API gateway or message bus through which one or more rApp 310 and other services of the SMO 304 (such as NSSMF function 306 and non-RT RIC 314) may communicate.

[0073] SMO 304 can communicate with EMS 320, which can be associated with two different branches: a first branch associated with a custom RAN and a second branch associated with a vRAN. The first branch can be associated with a baseband unit (BBU) 322 and potential additional hardware coupled to a remote radio unit (RRU) 328. RRU 328 can provide access to the custom RAN, which can be associated with 3G to 5G deployments and above. The second branch can be associated with virtualized CU (vCU) 324 and virtualized DU (vDU) 326, and potential additional hardware coupled to RU 330. RU 330 can provide access to the vRAN, which can be associated with 4G, 5G, and 6G deployments.

[0074] SMO 304 can also communicate with one or more O-RAN network functions, including near-RT RIC 332, O-RANCU control plane (O-CU-CP) 334, O-RAN CU user plane (O-CU-UP) 336, and O-RAN DU (O-DU) 338. The O-RAN network functions can communicate with O-RAN RU (O-RU) 340, which can provide access to the O-RAN, which may alternatively be referred to as or understood as an open cloud (O-Cloud) and may be associated with 4G, 5G, and 6G deployments. In some respects, SMO 304 can interface with near-RT RIC 332, O-CU-CP 334, and O-DU via the O1 interface. Additionally or alternatively, SMO 304 can interface with near-RT RIC 332 via the A1 interface. The near-RT RIC 332 can interface with each of the O-CU-CP 334 and O-CU-UP 336 via the E2 interface, and the O-CU-CP 334 can interface with the O-CU-UP 336 via the E1 interface. The O-CU-CP 334 can interface with the O-DU 338 via either or both of the E2 or F1-C interfaces, and the O-CU-UP can interface with the O-DU 338 via the F1-U interface. The O-DU 338 can interface with the O-RU 340 via an open fronthaul connection.

[0075] Network architecture 300 can also be associated with transport network (TN) NSSMF 342 and core network (CN) NSSMF 344, which interfaces with or is otherwise associated with TN 348 (for fronthaul, midhaul, and backhaul communications), and the core network (CN) NSSMF interfaces with or is otherwise associated with CN 350 (for user plane function (UPF) and session management function (SMF) communications). Network architecture 300 can also be associated with Virtualized Network Function Orchestration (VNFO) Management and Orchestration (MANO) 346. In some aspects, network architecture 300 can support one or more types of network slices, including massive machine-type communications (mMTC) slices 352, enhanced mobile broadband (eMBB) slices 354, and URLLC or V2X slices 356, each of which can be associated with packet data network 358.

[0076] In some deployment scenarios, several challenges may arise associated with RAN slicing performed by the MNO. For example, RAN slicing, and the various slice types configured across multiple RAN vendors and frameworks (such as traditional RAN frameworks, vRAN frameworks, and O-RAN frameworks), can introduce high complexity. Furthermore, slice configuration processes using different slice parameters and supporting highly customized slices in various geographic regions, across various multi-band or multi-frequency deployments, can increase this complexity and may also meaningfully contribute to latency in determining slice feasibility. Additionally, monitoring, managing, or supporting slice SLA compliance in a multi-slice environment can introduce further complexity when the network is planned to support a relatively large number of slices.

[0077] Furthermore, challenges may arise in association with the expectation of approving slice requests transmitted via NSMF 302 (E2E orchestrator). Slice requests can be of different types, including eMBB, URLLC, or mMTC, and each can have different SLA constraints. For example, a slice request may be associated with a network slice configured to support gaming operations. Such a network slice may include SLA characteristics supporting gaming, such as downlink throughput threshold latency, uplink throughput threshold latency, or both, to meet the game's latency thresholds. In some implementations, the network slice may be an example of a URLLC (such as latency-sensitive) network slice corresponding to a specific Service Slice Type (SST). For example, a URLLC network slice may have an SST value of 2. To handle network slice requests associated with URLLC network slices, NSSMF may consider the latency domain of the slice SLA to determine whether to accept or reject the requested network slice. In some aspects, the latency associated with communication with a network slice may involve air interface latency, return latency, or both. Air interface latency can vary based on the number of users communicating within a network slice, the amount of resources allocated for communication (such as PRBs), or both. Therefore, the NSSMF can satisfy latency thresholds for network slice requests by modifying the amount of resources allocated to a network slice (e.g., for a given number of users operating within the slice). In some implementations, the NSSMF may affect air interface latency (e.g., by changing the amount of resources allocated to a network slice) but may not affect return latency.

[0078] Once a request is made, the RAN NSSMF (which may be a RAN domain orchestrator) can determine, measure, identify, or ascertain whether sufficient capacity, coverage, and resources exist in the proposed slice coverage area. For example, the RAN NSSMF can perform a slice feasibility assessment for specific network parameters of the proposed slice coverage area. Network parameters may include load information, RF conditions, service patterns, network infrastructure (such as the physical location of cells and cell coverage areas), or any combination of these or other parameters. Load information may refer to the number of users supported by the network slice, the corresponding number of users per cell associated with the network slice, or the “load” of communication occurring within the network slice based on the number of users. In some aspects, load information may be simulated values ​​(such as a predicted number of users, a threshold number of users) or observed values ​​(such as the number of users operating within the proposed slice coverage area during a previous time period). The slice feasibility assessment can evaluate whether the proposed slice coverage area can meet slice SLA latency thresholds (such as uplink latency thresholds, downlink latency thresholds, or both), slice SLA throughput thresholds (such as uplink throughput thresholds, downlink throughput thresholds, or both), or a combination of these or other SLA characteristics associated with the requested network slice. In some specific implementations, the latency threshold can be determined based on the amount of data transmitted or received (such as data of a specific size). Defined in milliseconds (ms). The RAN NSSMF performing a slice feasibility assessment can select (e.g., determine, predict, or otherwise identify) the number of PRBs required to meet a latency threshold for a requested network slice. In some respects, the RAN NSSMF can determine the relationship between resource allocation and latency for different frequency ranges, user service patterns, RF conditions, number of users (such as load information), or any combination thereof. The RAN NSSMF can use this relationship to select the number of PRBs to meet a specific latency threshold.

[0079] In some implementations, one or more devices, components, entities, or functions associated with network architecture 300 can support an automated slice configuration process that utilizes ML / AI models to assist in slice feasibility assessment. As part of this automated slice configuration process, NSMF 302 can make a new slice allocation request to NSMF, which can determine whether there are sufficient resources to accommodate the new slice allocation request (URLLC slice allocation request). For example, SMO 304 or a device performing operations associated with SMO 304 or NSMF can receive requests for network slices from NSMF 302 and can trigger a series of applications (such as a series of rApps 310) to determine whether the requested network slice is feasible and can output recommendations associated with the requested network slice (such as instructions to approve or reject the requested network slice). In some aspects, this series of applications can include resource estimation applications and feasibility applications, and the feasibility applications can consider various inputs, including the output of ML / AI models (which can provide insights or information to otherwise assist in determining whether a requested network slice will be approved or rejected). Based on whether the requested network slice will be approved or rejected, SMO 304 can output an indication of approval or rejection to NSMF 302 (such as via NSMF).

[0080] Figure 4 An example network framework 400 supporting network slicing feasibility assessment for latency-based SLAs is illustrated. Network framework 400 exemplifies a slicing application above the Data Mediation Layer (DML) for executing NSMF slicing instructions. Network framework 400 may include an NSMF E2E orchestrator 402 communicating with a slice manager 404, which may include, be included in, or otherwise associated with an NSMF 406. Network framework 400 may also include a collection of automation applications 408 (such as one or more automation applications 408) and a collection of ecosystem tools 410 (such as one or more ecosystem tools 410).

[0081] The slice manager 404 (or NSSMF 406) can communicate with DML 418 via API gateway 412. Similarly, the automation application 408 can communicate with DML 418 via API gateway 412. The ecosystem tool 410 can communicate with the stateless intermediary 416 via message bus 414. The stateless intermediary 416 and DML 418 can communicate depending on the network deployment, and DML 418 can communicate with one or more data producers 420. Data producers 420 can supply data to one or more different types of networks, including a single RAN (S-RAN) 422, vRAN 424, or O-RAN 426.

[0082] In some implementations, network framework 400 or devices or components associated with network framework 400 may be pluggable, extensible, abstractible, programmable, and compatible, which may facilitate the implementation of exemplary embodiments of this disclosure. For example, various devices, components, entities, functionalities, or applications associated with network framework 400 may support an automated slice configuration process, according to which devices associated with the SMO can obtain or receive requests for network slices and output or send recommendations associated with the requested network slice based on ML / AI-assisted resource allocation predictions for the requested network slice. In some implementations, the automated slice configuration process may, for example, perform a slice feasibility assessment before deploying the network slice. A slice feasibility assessment can determine whether a requested network slice is feasible (e.g., supported by the cell's network architecture) before configuring or activating the network slice. In some implementations, devices may perform ML / AI-assisted resource allocation predictions based on latency thresholds associated with the SLA of the requested network slice, throughput thresholds associated with the SLA of the requested network slice, user information (such as one or more UEs serving in one or more cells corresponding to the requested network slice), or any combination thereof. In some respects, user information can be referred to as network slice load information. Devices associated with an SMO can also acquire or receive this network slice load information and can perform ML / AI-assisted resource allocation prediction based on the load information.

[0083] Figure 5An example network architecture 500 supporting network slicing feasibility assessment for latency-based SLAs is illustrated. Network architecture 500 includes an NSMF 502, an NSSMF 504 (which can be understood as a RAN NSSMF or R-NSSMF), and an SMO 506 (which can be understood as a RAN SMO). The NSMF 502 can interface with the NSSMF 504, which in turn can interface with the SMO 506. In some implementations, network architecture 500 may exemplify a functional diagram through which devices associated with service management can perform the example implementations disclosed herein.

[0084] SMO 506 may include or be associated with a collection of rApps 508, such as one or more. rApp 508 may include a resource allocation application 520 (which may be understood as or otherwise referred to as a resource estimation application), a slice feasibility application 522, a slice configuration application 524, or any combination thereof. SMO 506 may also include or be associated with various other services, functions, or entities, and such various other services, functions, or entities may include a slice policy 512, a slice inventory 514, an ML / AI model 516, and a packet gateway (PGW) 518. In some aspects, SMO 506 may also include or be associated with PGW-A1 526 (the PGW associated with the A1 interface) and PGW-O1 528 (the PGW associated with the O1 interface). SMO 506 may interface with a legacy RAN 530 via PGW 518 and may interface with one or more O-RAN functions 532 via one or both of PGW-A1 526 or PGW-O1. The traditional RAN 530 can be compared with, for example Figure 3 The EMS 320 illustrated and described with reference to this figure is associated with, and may refer to, one or more of a custom RAN, S-RAN, or vRAN. O-RAN function 532 may include, for example... Figure 3 One or more of the near-RT RIC 332, O-CU-CP 334, O-CU-UP 336 and O-DU 338 illustrated and described with reference to the figure.

[0085] In some implementations, one or more devices, components, entities, or functions associated with network architecture 500 may support or otherwise facilitate an automated slice configuration process, under which recommendations associated with a requested network slice may be provided on demand. For example, devices associated with service management of the wireless network (such as devices that accommodate or otherwise associate functionality with one or both of NSMF 504 or SMO 506) may output recommendations associated with the requested network slice based on one or more of the SLA associated with the requested network slice, observed network conditions, current cell load, service forecasts, or slice admission policies, etc. In some implementations, devices associated with service management may use one or more ML / AI models 516 to assist in predicting resource allocation (e.g., on a per-cell basis) or assisting in outputting (e.g., determining) recommendations for the requested network slice. These one or more ML / AI models 516 may be trained based on observed network conditions, a collection of network snapshots (such as one or more), live network statistics, or any combination thereof.

[0086] For example, the device can train the ML / AI model 516 based on different types of networks with different cell types. During training, each cell can be associated with (e.g., maintaining) a unique RF distribution pattern and different cell physical data (such as different cell physical characteristics, which may include cell height, line-of-sight, distance between cell sites, or antenna configuration). Additionally or alternatively, the device can train the ML / AI model 516 taking into account different slice properties, corresponding to, for example, indoor settlement, outdoor settlement, mixed indoor-outdoor settlement (depending on which there may be some distribution of indoor and outdoor devices), or V2X motion / movement on a road. Based on this training, the device can achieve more accurate cell modeling (which can be used as a baseline for predicting PRB allocations for network slices of computation requests). Additionally or alternatively, the device can train the ML / AI model 516 using different frequency bands and frequencies, different morphologies, different types of SLA requests (from NSMF 502), different SLA latency thresholds, different SLA throughput thresholds, different load information (such as different numbers of UEs operating within the cell coverage area), or any combination thereof. Therefore, when selecting or otherwise determining the approval or rejection of a requested network slice, the ML / AI engine can use (such as considering or referencing) different bands and frequencies as well as different forms.

[0087] In some specific implementations, in response to receiving a request for a network slice, the device associated with service management may perform a series of operations, or trigger a series of applications, or any combination thereof. For example, NSMF 502 may instruct (such as output or send) the request for a network slice to NSMF 504. This request may include or be associated with the SLA of the requested network slice. For example, the request may indicate one or more parameters associated with the SLA of the requested network slice. Such one or more parameters may indicate the expected throughput (such as one or more throughput thresholds), latency constraints (such as one or more latency thresholds), bit error rate, or the expected number of users (such as UE115) at each cell in the envisioned slice coverage area. Additionally, in some specific implementations, one or more parameters may indicate a slice admission policy, such as an MNO slice admission policy. In some aspects, the expected throughput may be associated with a guaranteed bit rate, which can be understood as the minimum (downlink) throughput requested by the slice.

[0088] The requested network slice can be a new network slice or a modified version of an existing network slice. Furthermore, the requested network slice can be any type of network slice, such as any type of URLLC network slice.

[0089] NSSMF 504 can trigger resource allocation application 520 in SMO 506 upon receiving a request. In some implementations, resource allocation application 520 can provide resource allocation for the entire network slice. In other implementations, resource allocation application 520 can provide cell-by-cell resource estimates for the cells corresponding to the requested network slice. In some aspects, resource allocation application 520 can employ (e.g., using) per-cell planning, which can be understood as cell planning on a cell-by-cell basis. For example, resource allocation application 520 can determine (e.g., identify, select, predict, or calculate) the spectral portion (e.g., in terms of PRB) that is likely to satisfy the requested SLA based on RF conditions (e.g., observed network conditions) at each cell in the set of cells within the envisioned slice coverage area. In other words, resource allocation application 520 can provide PRB estimates based on service model analysis.

[0090] Therefore, the resource allocation application 520 (which can be understood as or otherwise referred to as a resource estimation application) can estimate the amount of resources (in terms of communication resources such as PRBs) that a requested network slice might consume to allow its implementation. In other words, the resource allocation application 520 can be associated with the ability or capability to predict the number of PRBs per cell or per group of cells for different types of network slice requests (such as different types of network slice requests of type SST=URLLC). Such URLLC type slices can be associated with latency thresholds to support relatively low latency operation.

[0091] In some implementations, the resource allocation application 520 may allow the user to adjust one or more evaluation thresholds based on network-specific performance, and the resource allocation application 520 may include, be associated with, or otherwise access (such as via a wired or wireless interface) backlog data for computation. Such evaluation thresholds, which can be understood as optimization parameters and can be associated with slice admission policies, may include backlog duration, percentile thresholds for RF measurement distributions, minimum number of RF measurement samples, a list of allowed frequencies, busy hour definitions, or any combination thereof. In other words, the device associated with service management may query the MNO for information indicating user coverage percentiles (such as the percentage of users to be covered, which may be related to a threshold number of expected users), percentiles of cells outside the slice coverage area (such as the percentage of cells outside the slice coverage area, which may be related to a threshold number of cells), and information related to security margin definitions associated with slice violations (such as the maximum PRB utilization defined for cells and compared with the allocated cell utilization (such as the actual measured utilization of the cell) and the predicted utilization of the new slice). The MNO may support different MNO slicing policies accordingly. MNO slicing strategies can be associated with different numbers or proportions of cells in the slice coverage area that comply with the SLA, different numbers or proportions of users in the slice coverage area that comply with the SLA, different security margins for maintaining the SLA of the slice, or any combination of these or other slicing strategy parameters.

[0092] Based on this resource estimation, resource allocation application 520 can select or predict the latency threshold at which a first cell (or each cell in a first group of cells) associated with relatively high-quality RF conditions, relatively low load conditions, or both might use a first, smaller number of PRBs to appropriately support the SLA of the requested network slice, and a second cell (or each cell in a second group of cells) associated with relatively poor-quality RF conditions, relatively high load conditions, or both might use a second, larger number of PRBs to appropriately support the latency threshold of the requested network slice's SLA. Additional details relating to this variation in RF conditions, load conditions, or both among cells within the envisioned slice coverage area, and the corresponding variation in PRB estimates, are provided through... Figure 6 This will be illustrated and described with reference to the diagram.

[0093] In some implementations, SMO 506 may use a resource allocation ML / AI engine (such as one or more ML / AI models in ML / AI model 516) to support resource estimation for a requested network slice. Depending on the use of such an ML / AI engine, SMO 506 may input one or more parameters into the ML / AI engine and obtain an estimated PRB allocation (such as multiple estimated PRB allocations on a per-cell basis) as the output of the ML / AI engine. Such one or more parameters that SMO 506 may input into the ML / AI engine may include a first set of one or more parameters associated with network slice modeling (such as those contributing to network slice modeling) and a second set of one or more parameters associated with the requested SLA. The first set of parameters associated with network slice modeling (such as per-cell modeling) may include parameters associated with RF conditions, or parameters associated with PRB and load distribution, or both. For example, cell modeling can be associated with one or more of the following: frequency band, duplex mode (such as FDD or TDD), traffic behavior (such as indoor, outdoor, indoor-outdoor mixed, or V2X motion / mobility on roads), MCS, rank indicator (RI), and cell RF profiles using various metrics (such as Channel Quality Indicator (CQI) statistics). Therefore, in some implementations, the device associated with service management can query the MNO for inputs including frequency band or frequency, traffic distribution (such as the percentage of expected users indoors and the percentage of expected users outdoors), and one or more RF profiles constructed based on the CQI.

[0094] The second set of parameters associated with the requested SLA may include the number of active and scheduled users per slice (or per cell, per slice), the target bit error rate, slice profile (such as SLA) throughput and latency thresholds, or any combination thereof. The output of the ML / AI engine may include the number of PRBs per cell or per group of cells for the requested network slice (or multiple requested network slices). Therefore, incremental PRBs may exist per cell, such that at a given cell, a first network slice can be allocated a first number of PRBs, a second network slice can be allocated a second number of PRBs, and a third network slice can be allocated a third number of PRBs.

[0095] In some respects, per-cell resource estimation techniques can support relatively more accurate estimates of PRB allocations for each cell. For example, in some other systems, operators may use a single PRB allocation value for all cells, which can lead to spectrum oversizing or undersizing. Spectrum oversizing (which can be equivalently understood as resource overestimation) can lead to or otherwise increase the likelihood of spectrum loss or waste. In other words, oversizing can generate false negatives (regarding whether a cell can accommodate a requested network slice), resulting in low network utilization. Spectrum undersizing (which can be equivalently understood as insufficient resource estimation) can lead to or otherwise increase the likelihood of SLA violations. In other words, undersizing can generate false positives in cells where slice SLA compliance could be avoided (or otherwise not guaranteed) (regarding whether a cell can accommodate a requested network slice). For example, in the case of undersizing, operators may violate SLAs for customers under certain conditions (such as under relatively high load conditions) by failing to meet latency thresholds. Therefore, based on the described cell-by-cell resource estimation technique, the system can avoid spectrum loss and enterprise or customer slicing violations, while also addressing the complexity associated with choosing resource allocation settings in terms of isolation levels such as dedicated, prioritized, or shared.

[0096] As output of resource allocation application 520, SMO 506 can obtain a resource estimate for the requested network slice, which can be understood or referred to as the corresponding PRB allocation for the network slice for each cell in the set of cells. Based on the obtained cell-by-cell resource estimate, SMO 506 can store the data associated with the cell-by-cell resource estimate in a database. For example, SMO 506 can output the results of resource allocation application 520 to the RAN resource inventory. In some implementations, the results may include cell-by-cell slice allocation scores based on the cell-by-cell resource estimate.

[0097] SMO 506 can trigger a slice feasibility check via slice feasibility application 522. Slice feasibility application 522 can take an input set and output a recommendation associated with the requested network slice. In some implementations, slice feasibility application 522 can send or output a recommendation associated with the requested network slice based on per-cell resource estimates and current per-cell resource utilization, as well as other factors such as service forecasts, slice admission policies, and performance metrics. In other words, for each cell in the set of cells within the envisioned slice coverage area, slice feasibility application 522 can add the corresponding predicted PRB allocation to the corresponding current PRB utilization to calculate (e.g., determine or predict) the total number of PRBs that might be used at that cell (potentially to support existing and requested network slices). Based on the calculation of the total number of PRBs that might be used at each cell in the set of cells within the envisioned slice coverage area, slice feasibility application 522 can scan across the set of cells, apply slice admission policies, and output approval or rejection of the requested network slice based on the scan and slice admission policies. In some implementations, SMO 506 may send or output an indication of whether a network slice request is approved or rejected to the RAN resource inventory. Additionally or alternatively, slice feasibility application 522 may output (e.g., to the RAN resource inventory, to NSMF 502) a feasibility indication for each cell in the set of cells corresponding to the requested network slice. For example, if the requested network slice is rejected, slice feasibility application 522 may indicate which cells in the set of cells failed to support the requested network slice (e.g., the latency threshold of the SLA for failing to support the requested network slice).

[0098] Additionally or alternatively, if not based on all input cells, approval or rejection of a requested network slice may be based on a subset of cells from a larger set of cells. For example, one or both of resource allocation application 520 and slice feasibility application 522 may acquire (e.g., receive, select, obtain, or otherwise determine) a number of [cells]. The cells are used as input (such as input for training machine learning models, or input for resource allocation and feasibility checks, or both), and can output information about the number of cells. of One community ( , including (Example) Decision-making. Besides precise (such as 1:1) cell-by-cell processing, or as an alternative, the first number can be achieved. This input from the community and the second quantity The provision of cell-related decisions (such as recommendations, which may include approval or rejection). In other words, cell-by-cell resource estimation may include the provision of cell-associated decisions (such as recommendations, which may include approval or rejection). ) is the number of inputs to the cell (such as A subset of ) (such that) ) or when the number of cell outputs (such as ) equals the number of inputs to the cell (such as (make) Cell-by-cell resource estimation at time. Generally speaking, among them The scenario can be understood as precise (such as 1:1) cell-by-cell processing, because decisions are provided for all input cells.

[0099] Such decision-making for a subset of cells may involve recommendations associated with the requested network slice applicable to that subset of cells. When outputting the final recommendation associated with the requested network slice, slice feasibility application 522 may consider (e.g., taking into account) one or more recommendations associated with per-cell processing, one or more recommendations associated with one or more subsets of the processed cells, or any combination thereof. In this context, per-cell resource estimation makes... In the example, different subsets of cells can include the same number of cells, or they can include different numbers of cells.

[0100] In some implementations, the slice feasibility application 522 can take the output of an ML / AI model (such as one or more ML / AI models in ML / AI model 516) as input, which provides ML / AI-enhanced insights relating to whether a requested network slice will be approved or rejected. In such implementations, the output of the ML / AI model can be correlated with automatic classification or KPI prediction, or both.

[0101] SMO 506 can output to NSSMF 504 or otherwise provide an indication of approving or rejecting a requested network slice. In an example where SMO 506 outputs approval of a requested network slice (based on the output of slice feasibility application 522), NSSMF 504 can deploy the requested network slice in a Network Slice Subnet Instance (NSSI) (such as an existing NSSI). NSSMF 504 can trigger slice configuration application 524 based on the approval of the requested network slice, and SMO 506 can provision the requested network slice accordingly. Associated with the provisioning of the requested network slice, NSSMF 504 can notify NSMF 502 that the requested network slice has been successfully configured. Additionally or alternatively, NSSMF 504 can perform resource reservation in a subsequent time period (such as based on analysis in resource allocation application 520). For example, a vendor can schedule the activation of a network slice at a later time (such as coinciding with an event). NSSMF 504 can reserve PRB resources for the later time to meet the SLA threshold for the scheduled activation of the network slice at that later time. However, these PRB resources can be reused before and after the time period corresponding to the resource reservation (e.g., by being reused by other network slices for other operations).

[0102] Alternatively, in an example where SMO 506 outputs a rejection of a requested network slice, NSMF 504 can notify NSMF 502 that the requested network slice has been rejected (and is not configured). In some implementations, NSMF 504 can indicate to NSMF 502 which cells have failed the feasibility analysis. Following the notification, NSMF 502 can send another request for another network slice. For example, NSMF 502, NSMF 504, and SMO 506 can iteratively and dynamically request and analyze multiple network slices (such as multiple SLAs) over time, which can satisfy one or more user expectations related to network responsiveness to network slice requests. Furthermore, according to the described techniques, devices associated with service management can support on-demand prediction of the number of PRBs for different types of cells using feasibility cell modeling for any type of slice URLLC SLA.

[0103] Based on the deployment of the requested network slice in the wireless network (such as after approval or admission), the ML / AI model (in ML / AI model 516) associated with the recommendation of the requested network slice can learn (e.g., based on received instructions on real-world network statistics) real-world network statistics. The ML / AI model can use these real-world network statistics to increase its accuracy for the next network slice request. In some implementations, devices associated with service management can receive information indicating one or more performance metrics (such as KPIs) associated with the deployed network slice and can update (e.g., refine or retrain) the ML / AI model based on these performance metrics. For example, the device can receive information indicating the actual PRB usage at each cell in a set of cells within the slice's coverage area, compare the actual PRB usage with the predicted PRB usage, and update (e.g., refine or retrain) the ML / AI model based on the increment between the actual and predicted PRB usage.

[0104] Figure 6 An example slice coverage area 600 supporting network slice feasibility evaluation for latency-based SLAs is shown. Slice coverage area 600 may include a set of cells, and according to the example implementation disclosed herein, the resource allocation application 520 of the SMO 506 can select (such as determine or predict) the appropriate PRB allocation for the requested network slice for each cell in the set of cells based on the SLA of the requested network slice. In some further implementations, the resource allocation application 520 can select (such as determine or predict) the appropriate PRB allocation for the requested network slice for each cell in the set of cells based on the SLA and observed network conditions (such as observed network conditions at each cell in the set of cells).

[0105] For example, each cell in the set of cells may be associated with potentially unique network conditions (such as RF conditions) and other unique factors or characteristics, and resource allocation application 520 may take into account this variability across the set of cells to select (such as determine or predict) the appropriate PRB allocation for the requested network slice for each cell in the set of cells. In other words, resource allocation application 520 may recognize or otherwise take into account that, to support a given latency per cell, a given throughput per cell, or both, different sized portions of spectrum may be used if the RF conditions differ. For example, if a first cell (or a first group of cells) is associated with relatively high-quality RF conditions, the first cell (or the first group of cells) may use a relatively small number of PRBs to conform to (such as satisfy) a given SLA (such as a latency-based SLA), which may inform resource allocation application 520 to allocate a relatively small number of PRBs to the first cell (or the first group of cells) for the given SLA. For another example, if a second cell (or a second group of cells) is associated with a relatively low-quality RF condition, the second cell (or the second group of cells) can use a relatively large number of PRBs to conform to (such as satisfy) a given SLA, which can instruct the resource allocation application 520 to allocate a relatively large number of PRBs to the second cell (or the second group of cells) for a given SLA.

[0106] Furthermore, different cells within the slice coverage area 600 can be associated with different amounts of resources (as a percentage of the available PRBs currently in use), or different signal-to-interference-plus-noise ratio (SINR) values, or both. In some specific implementations, the resource allocation application 520 can determine (such as select, calculate, or predict) a cell-by-cell resource estimate for the requested network slice by considering or otherwise using such observed network conditions at each cell within the slice coverage area 600. In some aspects, the resource allocation application 520 can determine (such as select, calculate, or predict) a cell-by-cell resource estimate based on a cell-specific model (such as a model associated with observed network conditions, such as one constructed based on observed network conditions).

[0107] In the example of slice coverage area 600, cells within slice coverage area 600 are exemplified as network entity 105, although multiple cells may be located at the same network entity 105, which is also within the scope of this disclosure. Therefore, cells within slice coverage area 600 may at least include or be associated with network entity 105. Similarly, per-cell resource allocation (such as per-cell PRB allocation) can be understood as per-network entity 105 resource allocation (such as per-network entity 105 PRB allocation). Each cell may be associated with a corresponding coverage area 602, which may cover or serve one or more intended users (such as one or more UEs 115) associated with the requested network slice. In some aspects, coverage area 602 may be as follows: Figure 1 An example of coverage area 110 is illustrated and referenced in the figure.

[0108] Figure 7 A block diagram of an example ML model represented by an ANN 700 supporting network slicing feasibility assessment for latency-based SLAs is shown. Devices (such as those associated with NSSMF, SMO, NSMF, network entity 105, or any combination thereof) may include ML models (such as the ANN 700). Some aspects and techniques described herein can be implemented, at least in part, using AI programs (such as programs that include ML models (such as the ANN 700 or any other type of ML model). The example ML model may include mathematical representations or define computational capabilities for inference from input data associated with patterns or relationships identified in the input data. As used herein, the term "inference" may include one or more of decision, prediction, determination, or value that may represent the output of the ML model. Computational capabilities may be defined based on certain parameters of the ML model, such as weights and biases. Weights may indicate a relationship between certain input data and certain outputs of the ML model, and biases may be examples of offsets that may indicate the starting point of the ML model's output. An example ML model operating on input data may start with an initial output based on biases and update its output based on a combination of input data and weights.

[0109] In some respects, the ML model can be configured to provide computational capabilities for wireless communication. Such an ML model can be configured with weights and biases to perform PRB resource estimation for requested network slices (e.g., on a per-cell basis), acceptance or rejection of network slices (e.g., based on slice feasibility analysis), or any combination thereof. Thus, during device operation, the ML model can receive input data (per-cell data or per-slice data), such as network parameters associated with a network snapshot, the number of RRC users (e.g., UE 115), the number of scheduled users, the number of expected users, PRB utilization, CQI distribution, traffic patterns, one or more SLA throughput thresholds, one or more SLA latency thresholds, or any combination thereof. Input data can be received from cell telemetry, requested network slice profiles, or combinations thereof. The ML model can perform inferences, such as the number of PRBs supporting a requested network slice profile given network parameters associated with weights and biases, or an indication of accepting or rejecting a network slice request, or both, based on SLA thresholds. The ML engine can be trained based on multiple (such as hundreds, thousands, or millions) network snapshots, including different RF conditions, different business patterns, and resulting latency.

[0110] The ML model can be deployed in one or more devices (such as network entity 105 and UE 115) and can be configured to enhance various aspects of the wireless communication system 100. For example, the ML model can be trained to identify patterns or relationships in data corresponding to networks, devices, or air interfaces. The ML model can support operational decisions involving one or more aspects associated with wireless communication devices, networks, or services. For example, the ML model can be used to support or improve aspects such as signal decoding / decoding, network routing, energy saving, transceiver circuit control, frequency synchronization, timing synchronization, channel state estimation, channel equalization, channel state feedback, modulation, demodulation, device location, beamforming, load balancing, operational and management functions, security, or other functionalities.

[0111] ML models can be characterized by a learning type that generates a specific type of learning model that performs a particular type of task. For example, different types of machine learning include supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, and other types of learning. ML models can be used to perform various tasks, such as classification or regression, where classification refers to determining one or more discrete output values ​​from a predefined set of output values, and regression refers to determining continuous values ​​that are not constrained by predefined output values. For example, a classification ML model configured according to aspects of this disclosure can produce outputs including acceptance or rejection of a requested network slice. A regression ML model configured as described herein can produce outputs including the number of PRBs (such as per cell) for the requested network slice. Some example ML models configured to perform such tasks include ANNs, such as convolutional neural networks (CNNs) and recurrent neural networks (RNNs), transformers, diffusion models, regression analysis models (such as statistical models), large language models (LLMs), decision tree learning (such as predictive models), support vector networks (SVMs), and probabilistic graphical models (such as Bayesian networks), among other types of models.

[0112] This paper illustrates, through examples, how one or more tasks or problems in wireless communications can benefit from the application of one or more ML models to more accurately determine the feasibility of network slice requests and improve resource allocation for requested network slices. For example, NSMF can more accurately select the PRB allocation for a network slice's cell based on a latency threshold of the network slice's SLA. This selection of PRB allocation can improve resource utilization and communication reliability by reducing the likelihood of over- or under-allocation of resources. Additionally or alternatively, NSMF can reduce the processing resources associated with network slice configuration based on one or more ML models that indicate the rejection of requested network slices that are infeasible given the network infrastructure, such as the cell associated with the requested network slice.

[0113] For ease of discussion, an ML model configured with an ANN is used; however, it should be understood that other types of ML models can be used instead of ANNs. Therefore, unless explicitly stated otherwise, the topic of ML models is not necessarily intended to be limited to ANN solutions. Furthermore, it should be understood that, unless otherwise specified, terms such as “AI / ML model,” “ML model,” “trained ML model,” “ANN,” “model,” and “algorithm” are intended to be used interchangeably.

[0114] ANN 700 can receive input data 706, which may include one or more bits of data 702, preprocessed data (optionally) output from preprocessor 704, or some combination thereof. Here, depending on, for example, the deployment phase of ANN 700, data 702 may include training data, validation data, application-related data, etc. In some other implementations, preprocessor 704 may be included within ANN 700. Preprocessor 704 may, for example, process all or part of data 702, which may result in some data 702 being altered, replaced, or deleted. In some implementations, preprocessor 704 may add additional data to data 702. In some implementations, preprocessor 704 may be another ML model, such as ANN.

[0115] In some implementations, the ANN 700 can be trained using network snapshots. For example, the wireless communication system 100 can generate a training set of data based on stored historical network parameters (such as cell telemetry) and obtained latency values. Alternatively, the ANN 700 can use simulated data from simulated network parameters and obtained latency values. The device can use the generated training set to train the weights of the ANN 700. Alternatively, the device can retrain or otherwise tune the weights of the ANN 700 based on new network snapshots, simulations, or both.

[0116] ANN 700 includes at least one first layer 708 of artificial neurons 710 to process input data 706 and provide the resulting first layer data to at least a portion of at least one second layer 714 via connections or edges (such as edge 712). The second layer 714 processes the data received via edge 712 and provides second layer output data to at least a portion of at least one third layer 718 via edge 716. The third layer 718 processes the data received via edge 716 and provides third layer output data to at least a portion of a final layer 722 comprising one or more artificial neurons 710 via edge 720 to provide output data 724. All or part of the output data 724 may be further processed in some way by a post-processor 726 (optionally). Thus, in some examples, ANN 700 may provide output data 728 associated with output data 724, post-processed data output from post-processor 726, or some combination thereof.

[0117] The structure and training of the artificial neurons 710 in each layer can be customized to meet the specific requirements of the application. Within a given layer (such as the first layer 708, the second layer 714, or the third layer 718 of ANN 700), some or all of the neurons can be configured to process the information provided to that layer and output corresponding transformed information from that layer. For example, the transformed information from a layer can represent a weighted sum of input information associated with a nonlinear activation function or other activation functions used to “activate” the artificial neurons in the next layer. Such artificial neurons in a layer can be activated by or in response to parameters such as the weights and biases previously described for ANN 700. The weights and biases of ANN 700 can be adjusted during training or during operation of ANN 700. The weights of various artificial neurons can control the strength of connections between layers or artificial neurons, while the biases can control the direction of connections between layers or artificial neurons. Activation functions can select or determine whether an artificial neuron sends its output to the next layer in response to the data received by that artificial neuron.

[0118] Different activation functions can be used to model different types of nonlinear relationships. By introducing nonlinearity into the ML model, activation functions allow the configuration of the ML model to change in response to identifying or detecting complex patterns and relationships in the input data. Some non-exhaustive examples of activation functions include sigmoid-based activation functions, hyperbolic tangent (tanh)-based activation functions, convolutional activation functions, upsampling, pooling, and rectified linear unit (ReLU)-based activation functions.

[0119] Training data can be used to train ML models such as ANN 700. Training data can include one or more datasets that ANN 700 can use to identify patterns or relationships. Training data can represent various types of information, including written, visual, audio, environmental context, operational attributes, or other types of information. For example, training data can include one or more counters associated with latency measurements, states, the number of RRC users, MCS values, PRB load information, or any combination of these or other counters or training data. During training, parameters of the artificial neuron 710 (such as weights and biases) can be changed, for example, to minimize or otherwise reduce the loss function or cost function. The training process can be repeated multiple times to fine-tune the ANN 700 using each iteration.

[0120] ANN 700 or other ML models can be implemented in various types of processing circuitry, along with their memory and applicable instructions. For example, the model can be implemented using general-purpose hardware circuitry such as one or more central processing units (CPUs), one or more graphics processing units (GPUs), or suitable combinations thereof. In some specific implementations, one or more tensor processing units (TPUs), neural processing units (NPUs), or other dedicated processors, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., may also be used.

[0121] In terms of examples, the ML model can be trained at some point before or after the operation of the ML model (such as ANN 700). When training the ML model, information can be collected or otherwise created in the form of suitable training data for use in training the ANN accordingly. For example, training data can be collected or otherwise created regarding information associated with received / transmitted signal strength, interference, and resource usage data, as well as any other relevant data that can be used to train the model to solve one or more problems or challenges in a communication system. In some implementations, all or part of the training data can originate from UE 115 or other devices in the wireless communication system, or one or more network entities 105, or be aggregated from multiple sources such as UE 115 and network entity 105, one or more other UE 115s, the Internet, etc. In some other implementations, the training data can be generated or collected online, offline, or both online and offline by UE 115, network entity 105, or other devices, and all or part of such training data can be transmitted or shared (in real-time or near real-time), such as through store-and-forward functions.

[0122] Once the ANN has been configured by setting parameters (including weights and biases) from the training data, its performance can be evaluated. In some scenarios, evaluation / validation tests can be conducted using a validation dataset, which may include data not present in the training data, to compare the model's performance against a baseline or other benchmark. The ANN configuration can be further refined, for example, by changing its architecture, retraining it on the data, or using different optimization techniques.

[0123] In some implementations, one or more devices or services may support processes related to the use, maintenance, activation, or reporting of ML models. In some aspects, all or part of a dataset or model may be shared across multiple devices to provide or otherwise enhance or improve processing. In some implementations, signaling mechanisms may be used at various nodes in a wireless network to signal capabilities for performing specific functions related to the ML model, support for a specific ML model, capabilities for collecting, creating, and transmitting training data, or other ML-related capabilities. ML models in wireless communication systems may, for example, be employed to support decisions or improve performance related to wireless resource allocation or selection, wireless channel condition estimation, interference mitigation, beam management, positioning accuracy, energy saving, etc. In some implementations, model deployment may occur jointly or separately at various network levels (such as UE115, network entity 105 (such as BS), or decomposed network entity 105 (such as CU, DU, or RU)).

[0124] Figure 8 A block diagram of an example ML architecture 800 supporting network slicing feasibility assessment for latency-based SLAs is shown. As illustrated, the ML architecture 800 includes multiple logical entities, such as a model training host 802, a model inference host 804, a data source 806, and an agent 808. The model inference host 804 is configured to run an ML model associated with inference data 812 provided by the data source 806. The model inference host 804 can produce an output 814, which may include predictions or inferences, such as discrete or continuous values ​​associated with the inference data 812, which may be provided as input to the agent 808.

[0125] Agent 808 may represent a component or entity of a wireless communication system, including, for example, a RAN, network entity 105, SMO, NSMF, NSM, or any other entity. In some specific implementations, agent 808 may be a type of agent that depends on the type of task performed by model inference host 804, the type of inference data 812 provided to model inference host 804, or the type of output 814 produced by model inference host 804.

[0126] Data can be collected from data source 806 and can be used as training data 816 for training an ML model or as inference data 812 for feeding ML model inference operations. Data source 806 can collect data from various action subject 810 entities (such as network entity 105 or cells supporting one or more network slices) and provide the collected data to model training host 802 for ML model training. Model training host 802 can be deployed at the same or different entity as the entity where model inference host 804 is deployed. For example, to offload model training processing that may affect the performance of model inference host 804, model training host 802 can be deployed at a model server.

[0127] Figure 9 A block diagram of an example device 905 supporting network slicing feasibility assessment for latency-based SLAs is shown. Device 905 can communicate with one or more network entities 105, one or more UEs 115, or any combination thereof, including communication via one or more wired interfaces, one or more wireless interfaces, or any combination thereof. Device 905 may include components supporting output and acquisition of communication, such as a communication manager 920, a transceiver 910, one or more antennas 915, at least one memory 925, code 930, and at least one processor 935. These components may communicate electronically or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., bus 940).

[0128] Transceiver 910 may support bidirectional communication via a wired link, a wireless link, or both, as described herein. In some embodiments, transceiver 910 may include a wired transceiver and be capable of bidirectional communication with another wired transceiver. Additionally or alternatively, in some embodiments, transceiver 910 may include a wireless transceiver and be capable of bidirectional communication with another wireless transceiver. In some embodiments, device 905 may include one or more antennas 915 that may be capable of transmitting or receiving wireless transmissions (e.g., concurrently). Transceiver 910 may also include a modem for modulating signals, for providing modulated signals for transmission (e.g., via one or more antennas 915 or via a wired transmitter), for receiving modulated signals (e.g., from one or more antennas 915 or from a wired receiver), and for demodulating signals. In some embodiments, transceiver 910 may include one or more interfaces, such as one or more interfaces coupled to one or more antennas 915 configured to support various receive or acquire operations, or one or more interfaces coupled to one or more antennas 915 configured to support various transmit or output operations, or combinations thereof. In some embodiments, transceiver 910 may include one or more processors or one or more memory components, or be configured to couple to such processors or memory components, which are operable to perform or support operations based on received or acquired information or signals, or generate information or other signals for transmission or other output, or any combination thereof. In some embodiments, transceiver 910, or transceiver 910 and one or more antennas 915, or transceiver 910 and one or more antennas 915 and one or more processors or one or more memory components (such as at least one processor 935, at least one memory 925, or both), may be included in a chip or chip assembly mounted in device 905. In some implementations, transceiver 910 may be able to operate to support communication via one or more communication links, such as communication link 125, backhaul communication link 120, midhaul communication link 162, and fronthaul communication link 168.

[0129] At least one memory 925 may include random access memory (RAM), read-only memory (ROM), or any combination thereof. At least one memory 925 may store computer-readable code, computer-executable code, or processor-executable code, such as code 930. Code 930 may include instructions that, when executed by one or more processors of at least one processor 935, cause device 905 to perform the various functions described herein. Code 930 may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. In some embodiments, code 930 may not be directly executable by one of the processors of at least one processor 935, but may enable a computer (such as when compiled and executed) to perform the functions described herein. In some embodiments, among other things, at least one memory 925 may include a basic input / output (I / O) system (BIOS) that controls basic hardware or software operations, such as interaction with peripheral components or devices. In some embodiments, at least one processor 935 may include multiple processors, and at least one memory 925 may include multiple memories. One or more of a plurality of processors may be coupled to one or more of a plurality of memories, which may be configured individually or collectively to perform the various functions described herein (such as a processing system, a memory system, or a portion thereof).

[0130] At least one processor 935 may include intelligent hardware devices such as general-purpose processors, DSPs, ASICs, CPUs, FPGAs, microcontrollers, programmable logic devices, discrete gate or transistor logic units, discrete hardware components, or any combination thereof. In some embodiments, at least one processor 935 may be configured to operate a memory array using a memory controller. In some other embodiments, the memory controller may be integrated into one or more processors in at least one processor 935. At least one processor 935 may be configured to execute computer-readable instructions stored in memory (such as one or more memories in at least one memory 925) to cause device 905 to perform various functions (such as functions or tasks supporting network slicing feasibility assessments for latency-based SLAs). For example, device 905 or components of device 905 may include at least one processor 935 and at least one memory 925 coupled to one or more processors in at least one processor 935, wherein the at least one processor 935 and the at least one memory 925 are configured to perform the various functions described herein. At least one processor 935 may be an example of a cloud computing platform (such as one or more physical nodes and supporting software such as an operating system, virtual machine, or container instance) that can host functions (such as by executing code 930) to perform the functions of device 905. At least one processor 935 may be any one or more suitable processors capable of executing scripts or instructions of one or more software programs stored in device 905 (such as within one or more memories of at least one memory 925). In some implementations, at least one processor 935 may include multiple processors, and at least one memory 925 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, which may be configured individually or collectively to perform the various functions described herein.

[0131] In some implementations, at least one processor 935 may be a component of a processing system, which may refer to a system of machines (such as a series of machines), circuitry (including, for example, one or both of processor circuitry (which may include at least one processor 935) and memory circuitry (which may include at least one memory 925)) or components that receive or receive input and process the input to produce, generate, or obtain a set of outputs. The processing system may be configured to perform one or more of the functions described herein. For example, at least one processor 935 or a processing system including at least one processor 935 may be configured, capable of being configured, or operable to cause device 905 to perform one or more of the functions described herein. Furthermore, as described herein, “configured to,” “capable of being configured,” and “operable to” are used interchangeably and may be associated with the ability to perform one or more of the functions described herein when executing code stored in at least one memory 925 or otherwise.

[0132] In some implementations, the processing system of device 905 may refer to a system that includes various other components or sub-components of device 905 (such as at least one processor 935, or transceiver 910, or communication manager 920, or other components or combinations of components of device 905). The processing system of device 905 may interface with other components of device 905 and may process information received from other components (such as inputs or signals) or output information to other components. For example, the chip or modem of device 905 may include the processing system and one or more interfaces for outputting information or for receiving information, or both.

[0133] One or more interfaces may be implemented as, or otherwise include, a first interface configured to output information and a second interface configured to receive information, or the same interface configured to both output and receive information, as well as other embodiments. In some embodiments, one or more interfaces may refer to an interface between the processing system of the chip or modem and the transmitter, such that device 905 can transmit information output from the chip or modem. Additionally or alternatively, in some embodiments, one or more interfaces may refer to an interface between the processing system of the chip or modem and the receiver, such that device 905 can receive information or signal input, and such information can be delivered to the processing system. Those skilled in the art will readily recognize that the first interface may also receive information or signal input, and the second interface may also output information or signal output.

[0134] Device 905 may include one or more chips, SoCs, chipsets, packages, or devices that individually or collectively constitute or include a processing system. The processing system includes processor (or “processing”) circuitry in the form of one or more processors, microprocessors, processing units (such as CPUs, GPUs, or DSPs), processing blocks, ASICs, programmable logic devices (such as FPGAs), or other discrete gate or transistor logic components or circuits (all of which are generally referred to herein individually as “processors” or collectively as “processors” or “processor circuitry”). One or more of these processors may be individually or collectively configured to perform the various functions or operations described herein. The processing system may also include memory circuitry in the form of one or more memory devices, memory blocks, memory elements, or other discrete gate or transistor logic components or circuitry, each of which may include tangible storage media such as RAM or ROM or combinations thereof (all of which are generally referred to herein individually as “memory” or collectively as “memory” or “memory circuitry”). One or more of these memories may be coupled to one or more processors and may store processor-executable code, individually or collectively, which, when executed by the one or more processors, configures the one or more processors to perform the various functions or operations described herein. Additionally or alternatively, in some embodiments, the one or more processors may be pre-configured to perform the various functions or operations described herein without software configuration. The processing system may also include or be coupled to one or more modems (such as Wi-Fi (e.g., IEEE compliant) modems or cellular (e.g., 3GPP 4G LTE, 5G, or 6G compliant) modems). In some embodiments, one or more processors of the processing system include or implement one or more modems. The processing system may also include or be coupled to multiple radio components (collectively, “radio components”), multiple RF chains, or multiple transceivers, each of which may in turn be coupled to one or more antennas. In some embodiments, one or more processors of the processing system include or implement one or more of the radio components, RF chains, or transceivers.

[0135] In some implementations, bus 940 may support communication at protocol layers of the protocol stack (such as within a protocol layer). In some implementations, bus 940 may support communication associated with logical channels of the protocol stack (such as between protocol layers of the protocol stack), and the communication may include communication performed within components of device 905, or communication performed between different components of device 905 that are co-addressable or may be located in different locations (such as where device 905 may refer to a system in which one or more of communication manager 920, transceiver 910, at least one memory 925, code 930 and at least one processor 935 may be located in one component of different components or partitioned between different components).

[0136] In some implementations, the communication manager 920 can manage various aspects of communication with the core network 130, such as via one or more wired or wireless backhaul links. For example, the communication manager 920 can manage the delivery of data communications by client devices such as one or more UEs 115. In some implementations, the communication manager 920 can manage communication with one or more other network entities 105 and may include a controller or scheduler for controlling communication with UE 115, such as in cooperation with one or more other network devices. In some implementations, the communication manager 920 may support an X2 interface within LTE / LTE-A wireless communication network technology to provide communication between network entities 105.

[0137] Based on the examples disclosed herein, the communication manager 920 may support service management for a wireless network. For example, the communication manager 920 may be capable of, configured to, or operable to support components for receiving or otherwise obtaining a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with the network slice's SLA. The communication manager 920 may be capable of, configured to, or operable to support components for receiving or otherwise obtaining load information associated with a network slice of the wireless network. The load information may include information related to the number of users (such as UE 115) operating within the coverage area of ​​the requested network slice. The communication manager 920 may be capable of, configured to, or operable to support components for selecting a PRB allocation for the network slice based on the latency threshold and the load information. The communication manager 920 may be capable of, configured to, or operable to support components for sending or otherwise outputting an indication of accepting or rejecting a request associated with the network slice to the NSMF and based on the network slice's PRB allocation.

[0138] In some implementations, the request associated with the network slice further indicates a throughput threshold associated with the network slice's SLA. In some implementations, the PRB allocation for the network slice is further selected based on the throughput threshold. In some implementations, the request associated with the network slice is received from the NSMF or otherwise obtained.

[0139] In some implementations, the communication manager 920 is capable of, configured to, or operable to support components for selecting the appropriate PRB allocation for a network slice for each cell in a set of cells of a wireless network associated with the network slice, based on the PRB allocation of the network slice, wherein the indication of accepting or rejecting a request associated with the network slice is based on the appropriate PRB utilization at each cell in the set of cells and the appropriate PRB allocation for the network slice for each cell in the set of cells.

[0140] In some implementations, the communication manager 920 is capable of, configured to, or operable to support components for outputting indications of the corresponding PRB allocation for a network slice for each cell in a set of cells. In some implementations, the indication for accepting or rejecting a request associated with a network slice satisfies a latency threshold based on a threshold proportion of the set of cells.

[0141] In some implementations, the communication manager 920 is capable of, configured to, or operable to support components for sending or otherwise outputting instructions to a database for the allocation of PRBs to network slices, instructions for accepting or rejecting requests associated with network slices, or both.

[0142] In some specific implementations, the communication manager 920 is capable of, configured to, or operable to support components for reserving a set of multiple PRBs for a network slice within a time period based on the PRB allocation of the network slice.

[0143] In some implementations, the communication manager 920 is capable of, configured to, or operable to support components for sending or otherwise outputting an indication of activating a network slice within a time period based on a set of multiple PRBs reserved for the network slice. In some implementations, the communication manager 920 is capable of, configured to, or operable to support components for sending or otherwise outputting an indication of deactivating a network slice based on the expiration of a time period.

[0144] In some specific implementations, the PRB allocation for a network slice is selected based on one or more parameters associated with the network slice. These parameters include: load information, the frequency band associated with the network slice, the number of UEs associated with the network slice, the type of environment of the network slice, the UE service distribution associated with the network slice, the cell type associated with the network slice, the CQI associated with the network slice, the MCS associated with the network slice, or a combination thereof.

[0145] In some implementations, to support the selection of PRB allocations for network slices, the communication manager 920 is capable of, configured to, or operable to support components for selecting a corresponding PRB allocation for each cell in a set of cells of a radio network associated with a network slice, based on one or more parameters associated with the network slice. In some implementations, the PRB allocation for a network slice is based on a latency threshold that the network slice satisfies for a threshold proportion of the number of UEs associated with the network slice.

[0146] In some implementations, the communication manager 920 is capable of, configured to, or operable to support components for training a first machine learning model based on latency thresholds and load information to output PRB allocations for network slices. In some implementations, to support training the first machine learning model, the communication manager 920 is capable of, configured to, or operable to support components for providing a set of multiple network snapshots as a first training set associated with the first machine learning model, wherein each network snapshot in the set corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof. In some implementations, to support training the first machine learning model, the communication manager 920 is capable of, configured to, or operable to support components for receiving or otherwise obtaining information indicating one or more performance metrics associated with a network slice, based on the deployment of the network slice in the wireless network. In some specific implementations, in order to support the training of the first machine learning model, the communication manager 920 can be configured or operated to support components for updating the first machine learning model based on one or more performance metrics.

[0147] In some implementations, the communication manager 920 is capable of, configured to, or operable to support components for training a second machine learning model to output an indication of accepting or rejecting a request associated with a network slice, based on the PRB allocation of a network slice, the corresponding PRB utilization for each cell in a set of cells of a radio network associated with the network slice, one or more radio frequency metrics associated with the set of cells, a morphology associated with the set of cells, or a combination thereof. In some implementations, to support training the second machine learning model, the communication manager 920 is capable of, configured to, or operable to support providing a set of multiple network snapshots as a component of a second training set associated with the second machine learning model, wherein each network snapshot in the set corresponds to a suitable PRB allocation for the requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or a combination thereof. In some implementations, to support the training of a second machine learning model, the communication manager 920 is capable of, configured to, or operable to support components for receiving or otherwise obtaining information indicating one or more performance metrics associated with a network slice, based on the deployment of the network slice in the wireless network. In some implementations, to support the training of a second machine learning model, the communication manager 920 is capable of, configured to, or operable to support components for updating the second machine learning model based on one or more performance metrics.

[0148] In some specific implementations, load information includes simulated load information of a set of cells of a wireless network associated with a network slice, observed load information of a set of cells of a wireless network associated with a network slice, or both.

[0149] In some implementations, the communication manager 920 may be configured to perform various operations (such as receiving, acquiring, monitoring, outputting, and transmitting) using a transceiver 910, one or more antennas 915 (where applicable), or any combination thereof, or otherwise cooperating with them. Although the communication manager 920 is illustrated as a separate component, in some implementations, one or more functions described with reference to the communication manager 920 may be supported or performed by the transceiver 910, one or more processors in at least one processor 935, one or more memories in at least one memory 925, code 930, or any combination thereof (such as a processing system including at least a portion of at least one processor 935, at least one memory 925, code 930, or any combination thereof). For example, code 930 may include instructions that can be executed by one or more processors in at least one processor 935 to cause device 905 to perform various aspects of network slicing feasibility assessment for delay-based SLAs as described herein, or at least one processor 935 and at least one memory 925 may be otherwise configured to perform or support such operations individually or jointly.

[0150] Figure 10 A flowchart illustrating a method 1000 for network slicing feasibility evaluation for latency-based SLAs is shown. The operation of method 1000 can be implemented by network entities or components thereof as described herein. For example, the operation of method 1000 can be implemented by, as referenced... Figures 1 to 9 The network entity described herein performs the function. In some specific implementations, the network entity may execute an instruction set to control the functional elements of the network entity to perform the described function. Additionally or alternatively, the network entity may use dedicated hardware to perform aspects of the described function.

[0151] At 1005, the method may include: receiving a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with the SLA of the network slice. The operation at 1005 may be performed according to the examples disclosed herein.

[0152] At 1010, the method may include receiving load information associated with a network slice of the wireless network. The operation of 1010 may be performed according to the examples disclosed herein.

[0153] At point 1015, the method may include selecting a PRB allocation for a network slice based on a latency threshold and load information. The operation at point 1015 can be performed according to the examples disclosed herein.

[0154] At 1020, the method may include sending an indication to the NSMF, and based on the PRB allocation of the network slice, to accept or reject a request associated with the network slice. The operation of 1020 may be performed according to the examples disclosed herein.

[0155] Specific implementation examples are described in the following numbered clauses: Aspect 1: An apparatus associated with service management of a wireless network, the apparatus comprising: a processing system including processor circuitry and memory circuitry storing code, the processing system being configured to cause the apparatus to: obtain a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with an SLA of the network slice; obtain load information associated with the network slice of the wireless network; select a PRB allocation for the network slice based on the latency threshold and the load information; and output an indication to the NSMF and based on the PRB allocation of the network slice to accept or reject the request associated with the network slice.

[0156] Aspect 2: The device according to Aspect 1, wherein: the request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice; and the PRB allocation of the network slice is further selected based on the throughput threshold.

[0157] Aspect 3: The device according to any one of Aspect 1 or 2, wherein the request associated with the network slice is obtained from the NSMF.

[0158] Aspect 4: The device according to any one of Aspects 1 to 3, wherein the processing system is further configured to cause the device to: select a corresponding PRB allocation for the network slice for each cell in the set of cells of the wireless network associated with the network slice, based on the PRB allocation of the network slice, wherein the indication for accepting or rejecting the request associated with the network slice is based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation for the network slice of each cell in the set of cells.

[0159] Aspect 5: The device according to aspect 4, wherein the processing system is further configured to cause the device to: output an indication of the corresponding PRB allocation for the network slice of each cell in the set of cells.

[0160] Aspect 6: The device according to any one of Aspects 4 or 5, wherein the indication for accepting or rejecting the request associated with the network slice satisfies the latency threshold according to a threshold proportion of the set of cells.

[0161] Aspect 7: The device according to any one of Aspects 1 to 6, wherein the processing system is further configured to cause the device to: output to a database an indication of the PRB allocation for the network slice, an indication of accepting or rejecting the request associated with the network slice, or both.

[0162] Aspect 8: The device according to any one of Aspects 1 to 7, wherein the processing system is further configured to enable the device to: reserve a set of multiple PRBs for the network slice within a time period according to the PRB allocation of the network slice.

[0163] Aspect 9: The device according to aspect 8, wherein the processing system is further configured to cause the device to: output an indication to activate the network slice during the time period based on the set of multiple PRBs reserved for the network slice; and output an indication to deactivate the network slice based on the expiration of the time period.

[0164] Aspect 10: The device according to any one of Aspects 1 to 9, wherein the PRB allocation for selecting the network slice is based on one or more parameters associated with the network slice, the one or more parameters including: the load information, the frequency band associated with the network slice, the number of UEs associated with the network slice, the type of environment of the network slice, the UE service distribution associated with the network slice, the cell type associated with the network slice, the CQI associated with the network slice, the MCS associated with the network slice, or a combination thereof.

[0165] Aspect 11: The apparatus according to aspect 10, wherein, in order to select the PRB allocation for the network slice, the processing system is configured to cause the apparatus to: select a corresponding PRB allocation for each cell in a set of cells of the wireless network associated with the network slice, based on one or more parameters associated with the network slice.

[0166] Aspect 12: The device according to any one of Aspects 10 or 11, wherein the PRB allocation of the network slice is based on the latency threshold that satisfies the threshold ratio for the number of UEs associated with the network slice.

[0167] Aspect 13: The device according to any one of Aspects 1 to 12, wherein the processing system is further configured to cause the device to: train a first ML model based on the latency threshold and the load information to output the PRB allocation of the network slice.

[0168] Aspect 14: The apparatus according to aspect 13, wherein, in order to train the first ML model, the processing system is configured to cause the apparatus to: provide a set of multiple network snapshots as a first training set associated with the first ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0169] Aspect 15: The device according to any one of Aspects 13 or 14, wherein, in order to train the first ML model, the processing system is configured to cause the device to: obtain information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and update the first ML model based on the one or more performance metrics.

[0170] Aspect 16: The device according to any one of Aspects 1 to 15, wherein the processing system is further configured to cause the device to: train a second ML model to output the indication for accepting or rejecting the request associated with the network slice based on the PRB allocation of the network slice, the corresponding PRB utilization for each cell in the set of cells of the wireless network associated with the network slice, one or more RF metrics associated with the set of cells, the morphology associated with the set of cells, or a combination thereof.

[0171] Aspect 17: The apparatus according to aspect 16, wherein, in order to train the second ML model, the processing system is configured to cause the apparatus to: provide a set of multiple network snapshots as a second training set associated with the second ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0172] Aspect 18: The device according to any one of Aspects 16 or 17, wherein, in order to train the second ML model, the processing system is configured to cause the device to: obtain information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and update the second ML model based on the one or more performance metrics.

[0173] Aspect 19: The device according to any one of Aspects 1 to 18, wherein the load information includes simulated load information of a set of cells of the wireless network associated with the network slice, observed load information of the set of cells of the wireless network associated with the network slice, or both.

[0174] Aspect 20: A method for network slice management of a wireless network, the method comprising: receiving a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with an SLA of the network slice; receiving load information associated with the network slice of the wireless network; selecting a PRB allocation for the network slice based on the latency threshold and the load information; and sending an indication to the NSMF and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

[0175] Aspect 21: According to the method of aspect 20, wherein: the request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice; and the PRB allocation of the network slice is further selected based on the throughput threshold.

[0176] Aspect 22: The method according to any one of Aspects 20 or 21, wherein the request associated with the network slice is received from the NSMF.

[0177] Aspect 23: The method according to any one of Aspects 20 to 22, the method further comprising: selecting a corresponding PRB allocation of the network slice for each cell in a set of cells of the wireless network associated with the network slice based on the PRB allocation of the network slice, wherein the indication for accepting or rejecting the request associated with the network slice is based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation of the network slice for each cell in the set of cells.

[0178] Aspect 24: The method according to aspect 23, the method further comprising: sending an indication of the corresponding PRB allocation for the network slice of each cell in the set of cells.

[0179] Aspect 25: The method according to any one of Aspects 23 or 24, wherein the indication for accepting or rejecting the request associated with the network slice satisfies the latency threshold according to a threshold proportion of the set of cells.

[0180] Aspect 26: The method according to any one of Aspects 20 to 25, the method further comprising: sending to a database an indication of the PRB allocation of the network slice, an indication of accepting or rejecting the request associated with the network slice, or both.

[0181] Aspect 27: The method according to any one of Aspects 20 to 26, the method further comprising: reserving a set of multiple PRBs for the network slice within a time period based on the PRB allocation of the network slice.

[0182] Aspect 28: The method according to aspect 27, the method further comprising: sending an instruction to activate the network slice during the time period based on the set of multiple PRBs reserved for the network slice; and sending an instruction to deactivate the network slice upon the expiration of the time period.

[0183] Aspect 29: The method according to any one of Aspects 20 to 28, wherein the PRB allocation of the network slice is selected based on one or more parameters associated with the network slice, the one or more parameters including: the load information, the frequency band associated with the network slice, the number of UEs associated with the network slice, the type of environment of the network slice, the UE service distribution associated with the network slice, the cell type associated with the network slice, the CQI associated with the network slice, the MCS associated with the network slice, or a combination thereof.

[0184] Aspect 30: The method according to aspect 29, wherein selecting the PRB allocation of the network slice includes: selecting a corresponding PRB allocation of the network slice for each cell in a set of cells of the wireless network associated with the network slice based on one or more parameters associated with the network slice.

[0185] Aspect 31: The method according to any one of Aspects 29 or 30, wherein the PRB allocation of the network slice is based on the latency threshold that satisfies the threshold ratio for the number of UEs associated with the network slice.

[0186] Aspect 32: The method according to any one of Aspects 20 to 31, the method further comprising: training a first ML model based on the latency threshold and the load information to output the PRB allocation of the network slice.

[0187] Aspect 33: According to the method of aspect 32, training the first ML model includes: providing a set of multiple network snapshots as a first training set associated with the first ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0188] Aspect 34: The method according to any one of Aspects 32 or 33, wherein training the first ML model comprises: receiving information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and updating the first ML model based on the one or more performance metrics.

[0189] Aspect 35: The method according to any one of Aspects 20 to 34, the method further comprising: training a second ML model to output the indication for accepting or rejecting the request associated with the network slice based on the PRB allocation of the network slice, the corresponding PRB utilization for each cell in the set of cells of the wireless network associated with the network slice, one or more RF metrics associated with the set of cells, a morphology associated with the set of cells, or a combination thereof.

[0190] Aspect 36: According to the method of aspect 35, training the second ML model includes: providing a set of multiple network snapshots as a second training set associated with the second ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0191] Aspect 37: The method according to any one of Aspects 35 or 36, wherein training the second ML model comprises: receiving information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and updating the second ML model based on the one or more performance metrics.

[0192] Aspect 38: The method according to any one of Aspects 20 to 37, wherein the load information includes simulated load information of the set of cells of the wireless network associated with the network slice, observed load information of the set of cells of the wireless network associated with the network slice, or both.

[0193] Aspect 39: An apparatus associated with service management of a wireless network, the apparatus comprising: components for receiving a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with an SLA of the network slice; components for receiving load information associated with the network slice of the wireless network; components for selecting a PRB allocation for the network slice based on the latency threshold and the load information; and components for sending an indication to the NSMF and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

[0194] Aspect 40: The device according to aspect 39, wherein: the request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice; and the PRB allocation of the network slice is further selected based on the throughput threshold.

[0195] Aspect 41: The device according to any one of Aspects 39 or 40, wherein the request associated with the network slice is received from the NSMF.

[0196] Aspect 42: The apparatus according to any one of aspects 39 to 41, the apparatus further comprising: a component for selecting a corresponding PRB allocation of the network slice for each cell in a set of cells of the wireless network associated with the network slice based on the PRB allocation of the network slice, wherein the indication for accepting or rejecting the request associated with the network slice is based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation of the network slice for each cell in the set of cells.

[0197] Aspect 43: The apparatus according to aspect 42, the apparatus further comprising: a component for transmitting an indication of the corresponding PRB allocation for the network slice of each cell in the set of cells.

[0198] Aspect 44: The device according to any one of Aspects 42 or 43, wherein the indication for accepting or rejecting the request associated with the network slice satisfies the latency threshold according to a threshold proportion of the set of cells.

[0199] Aspect 45: The apparatus according to any one of Aspects 39 to 44, the apparatus further comprising: a component for sending to a database an instruction for the PRB allocation of the network slice, the instruction for accepting or rejecting the request associated with the network slice, or both.

[0200] Aspect 46: The apparatus according to any one of aspects 39 to 45, the apparatus further comprising: a component for reserving a set of multiple PRBs for the network slice within a time period based on the PRB allocation of the network slice.

[0201] Aspect 47: The apparatus according to aspect 46 further includes: means for sending an indication to activate the network slice during the time period based on the set of multiple PRBs reserved for the network slice; and means for sending an indication to deactivate the network slice upon the expiration of the time period.

[0202] Aspect 48: The device according to any one of Aspects 39 to 47, wherein the PRB allocation for selecting the network slice is based on one or more parameters associated with the network slice, the one or more parameters including: the load information, the frequency band associated with the network slice, the number of UEs associated with the network slice, the type of environment of the network slice, the UE service distribution associated with the network slice, the cell type associated with the network slice, the CQI associated with the network slice, the MCS associated with the network slice, or a combination thereof.

[0203] Aspect 49: The apparatus according to aspect 48, wherein the component for selecting the PRB allocation of the network slice includes: a component for selecting a corresponding PRB allocation of the network slice for each cell in a set of cells of the wireless network associated with the network slice based on the one or more parameters associated with the network slice.

[0204] Aspect 50: The device according to any one of Aspects 48 or 49, wherein the PRB allocation of the network slice is based on the latency threshold that satisfies the threshold ratio for the number of UEs associated with the network slice.

[0205] Aspect 51: The apparatus according to any one of Aspects 39 to 50, the apparatus further comprising: a component for training a first ML model based on the latency threshold and the load information to output the PRB allocation of the network slice.

[0206] Aspect 52: The apparatus according to aspect 51, wherein the component for training the first ML model comprises: a component for providing a set of multiple network snapshots as a first training set associated with the first ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0207] Aspect 53: The device according to any one of Aspects 51 or 52, wherein the components for training the first ML model include: components for receiving information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and components for updating the first ML model based on the one or more performance metrics.

[0208] Aspect 54: The apparatus according to any one of Aspects 39 to 53, the apparatus further comprising: a component for training a second ML model to output the indication for accepting or rejecting the request associated with the network slice based on the PRB allocation of the network slice, the corresponding PRB utilization for each cell in a set of cells of the wireless network associated with the network slice, one or more RF metrics associated with the set of cells, a morphology associated with the set of cells, or a combination thereof.

[0209] Aspect 55: The apparatus according to aspect 54, wherein the component for training the second ML model comprises: a component for providing a set of multiple network snapshots as a second training set associated with the second ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0210] Aspect 56: The device according to any one of Aspects 54 or 55, wherein the components for training the second ML model include: components for receiving information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and components for updating the second ML model based on the one or more performance metrics.

[0211] Aspect 57: The device according to any one of Aspects 39 to 56, wherein the load information includes simulated load information of a set of cells of the wireless network associated with the network slice, observed load information of the set of cells of the wireless network associated with the network slice, or both.

[0212] Aspect 58: A non-transitory computer-readable medium storing code for network slice management in a wireless network, the code including instructions executable by a processing system to: obtain a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with an SLA of the network slice; obtain load information associated with the network slice of the wireless network; select a PRB allocation for the network slice based on the latency threshold and the load information; and output an indication to the NSMF and based on the PRB allocation of the network slice to accept or reject the request associated with the network slice.

[0213] Aspect 59: A non-transitory computer-readable medium according to aspect 58, wherein: the request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice; and the PRB allocation of the network slice is further selected based on the throughput threshold.

[0214] Aspect 60: A non-transitory computer-readable medium according to any one of aspects 58 or 59, wherein the request associated with the network slice is obtained from the NSMF.

[0215] Aspect 61: A non-transitory computer-readable medium according to any one of aspects 58 to 60, wherein the instructions are further executable by the processing system to: select a corresponding PRB allocation for the network slice for each cell in a set of cells of the wireless network associated with the network slice, based on the PRB allocation of the network slice, wherein the indication for accepting or rejecting the request associated with the network slice is based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation for the network slice of each cell in the set of cells.

[0216] Aspect 62: According to the non-transitory computer-readable medium of aspect 61, wherein the instructions are further executable by the processing system to: output an indication of the corresponding PRB allocation for the network slice of each cell in the set of cells.

[0217] Aspect 63: A non-transitory computer-readable medium according to any one of aspects 61 or 62, wherein the indication for accepting or rejecting the request associated with the network slice satisfies the latency threshold according to a threshold proportion of the set of cells.

[0218] Aspect 64: A non-transitory computer-readable medium according to any one of aspects 58 to 63, wherein the instructions are further executable by the processing system to: output to a database an instruction for the PRB allocation of the network slice, an instruction for accepting or rejecting the request associated with the network slice, or both.

[0219] Aspect 65: A non-transitory computer-readable medium according to any one of aspects 58 to 64, wherein the instructions are further executable by the processing system to: reserve a set of multiple PRBs for the network slice within a time period according to the PRB allocation of the network slice.

[0220] Aspect 66: According to the non-transitory computer-readable medium of aspect 65, wherein the instructions are further executable by the processing system to: output an instruction to activate the network slice during the time period based on the set of multiple PRBs reserved for the network slice; and output an instruction to deactivate the network slice upon the expiration of the time period.

[0221] Aspect 67: A non-transitory computer-readable medium according to any one of Aspects 58 to 66, wherein the PRB allocation for selecting the network slice is based on one or more parameters associated with the network slice, the one or more parameters including: the load information, the frequency band associated with the network slice, the number of UEs associated with the network slice, the type of environment of the network slice, the UE service distribution associated with the network slice, the cell type associated with the network slice, the CQI associated with the network slice, the MCS associated with the network slice, or a combination thereof.

[0222] Aspect 68: According to the non-transitory computer-readable medium of aspect 67, the instructions for selecting the PRB allocation of the network slice are executable by the processing system to: select the appropriate PRB allocation of the network slice for each cell in the set of cells of the wireless network associated with the network slice, based on the one or more parameters associated with the network slice.

[0223] Aspect 69: A non-transitory computer-readable medium according to any one of Aspects 67 or 68, wherein the PRB allocation of the network slice is based on the latency threshold that satisfies the threshold ratio for the number of UEs associated with the network slice.

[0224] Aspect 70: A non-transitory computer-readable medium according to any one of aspects 58 to 69, wherein the instructions are further executable by the processing system to: train a first ML model based on the latency threshold and the load information to output the PRB allocation of the network slice.

[0225] Aspect 71: According to the non-transitory computer-readable medium of aspect 70, wherein the instructions for training the first ML model are executable by the processing system to: provide a set of multiple network snapshots as a first training set associated with the first ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0226] Aspect 72: A non-transitory computer-readable medium according to any one of aspects 70 or 71, wherein the instructions for training the first ML model are executable by the processing system to: obtain information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and update the first ML model based on the one or more performance metrics.

[0227] Aspect 73: A non-transitory computer-readable medium according to any one of aspects 58 to 72, wherein the instructions are further executable by the processing system to: train a second ML model to output the indication to accept or reject the request associated with the network slice based on the PRB allocation of the network slice, the corresponding PRB utilization for each cell in the set of cells of the wireless network associated with the network slice, one or more RF metrics associated with the set of cells, a morphology associated with the set of cells, or a combination thereof.

[0228] Aspect 74: The non-transitory computer-readable medium according to aspect 73, wherein the instructions for training the second ML model are executable by the processing system to: provide a set of multiple network snapshots as a second training set associated with the second ML model, wherein each network snapshot in the set of multiple network snapshots corresponds to a suitable PRB allocation for a requested network slice and is associated with a unique permutation of: one or more cell types, one or more cluster sizes, one or more cell physical characteristics, one or more cell load conditions, or one or more cell channel quality distributions, one or more interference levels, or combinations thereof.

[0229] Aspect 75: A non-transitory computer-readable medium according to any one of Aspects 73 or 74, wherein the instructions for training the second ML model are executable by the processing system to: obtain information indicating one or more performance metrics associated with the network slice based on the deployment of the network slice in the wireless network; and update the second ML model based on the one or more performance metrics.

[0230] Aspect 76: A non-transitory computer-readable medium according to any one of aspects 58 to 75, wherein the load information includes simulated load information of a set of cells of the wireless network associated with the network slice, observed load information of the set of cells of the wireless network associated with the network slice, or both.

[0231] As used herein, the term "determine" or "determine" encompasses a wide variety of actions, and therefore, "determine" can include calculation, computation, processing, derivation, investigation, lookup (such as by searching in a table, database, or other data structure), inference, identification, and similar actions. Additionally, "determine" can include receiving (such as receiving information), accessing (such as accessing data stored in memory), and similar actions. Furthermore, "determine" can include parsing, selecting, choosing, building, and other such similar actions.

[0232] As used in this article, the phrase “at least one of the items” refers to any combination of these items, including a single member. As an example, “at least one of a, b, or c” is intended to cover: a, b, c, ab, ac, bc, and abc.

[0233] As used herein, including in claims, the article “a” preceding a noun is open-ended and is understood to refer to “at least one” or “one or more” of those nouns. Therefore, the terms “a,” “at least one,” “one or more,” and “at least one of one or more” are interchangeable. For example, where a claim enumerates “components” performing one or more functions, each of the individual functions may be performed by a single component or by any combination of multiple components. Thus, the term “component” having a characteristic or performing a function may refer to “at least one of one or more components” having a particular characteristic or performing a particular function. Subsequent references to a component introduced with the article “a” using the terms “the” or “the” can refer to any or all of the one or more components. For example, a component introduced with the article “a” can be understood to mean “one or more components,” and subsequent reference to “the component” in a claim can be understood as equivalent to referring to “at least one of the one or more components.” Similarly, subsequent references to a component introduced with the terms “the” or “the” as “one or more components” can refer to any or all of the one or more components. For example, reference to "the one or more components" in the subsequent claims can be understood as equivalent to reference to "at least one of the one or more components".

[0234] The various exemplary logics, logic blocks, modules, circuits, and algorithmic processes described in conjunction with the specific implementations disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. The interchangeability of hardware and software has been broadly described in terms of functionality and illustrated in the various exemplary components, blocks, modules, circuits, and processes described above. Whether such functionality is implemented using hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0235] Hardware and data processing apparatuses for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented or executed using general-purpose single-chip or multi-chip processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), graphics processing units (GPUs), neural processing units (NPUs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic components, discrete hardware components, or any combination thereof. A general-purpose processor may be a microprocessor, or any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In some specific implementations, specific processes and methods may be performed by circuitry specific to a given function.

[0236] In one or more aspects, the described functionality may be implemented using hardware, digital electronic circuits, computer software, firmware, including the structures disclosed herein and their structural equivalents, or in any combination thereof. Specific implementations of the subject matter described herein may also be implemented as one or more computer programs, such as one or more modules of computer program instructions encoded on a computer storage medium for execution by a data processing apparatus or for controlling the operation of a data processing apparatus.

[0237] If implemented in software, the functionality can be stored or transmitted using one or more instructions or code on a computer-readable medium. The processes of the methods or algorithms disclosed herein can be implemented in a processor-executable software module that can reside on a computer-readable medium. Computer-readable media include both computer storage media and communication media, including any medium that can be implemented to transfer a computer program from one location to another. Storage media can be any available medium accessible to a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible to a computer. Furthermore, any connection may be properly referred to as a computer-readable medium. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs. A disk can magnetically reproduce data, and an optical disc can optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operation of a method or algorithm may reside as a set of code and instructions or any combination of code and instructions on a machine-readable medium and a computer-readable medium that may be incorporated into a computer program product.

[0238] Various modifications to the specific embodiments described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other specific embodiments without departing from the spirit or scope of this disclosure. Therefore, the claims are not intended to be limited to the specific embodiments shown herein, but should be granted the broadest scope consistent with this disclosure and the principles and features disclosed herein.

[0239] Additionally, those skilled in the art will readily recognize that the terms “upper” and “lower” are sometimes used to facilitate the description of the drawings and to indicate relative positioning on a correctly oriented page corresponding to the orientation of the drawings, and may not reflect the correct orientation of any device as implemented.

[0240] Some features described in this specification in the context of a single embodiment may also be implemented in combination in that single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as functioning in some combination and even initially claimed in this way, one or more features from the claimed combination may be removed from that combination, and the claimed combination may involve sub-combinations or variations thereof.

[0241] Similarly, although operations are depicted in a specific order in the figures, this should not be construed as requiring such operations to be performed in the shown specific order or sequential order, or to perform all illustrated operations to achieve the desired result. Furthermore, the figures may schematically depict one or more example processes in the form of flowcharts. However, other operations not depicted may be incorporated into the schematically illustrated example processes. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the illustrated operations. In some environments, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be construed as requiring such separation in all embodiments, but rather should be understood as meaning that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other embodiments are within the scope of the appended claims. In some embodiments, the actions recited in the claims may be performed in a different order and still achieve the desired result.

Claims

1. An apparatus associated with service management of a wireless network, the apparatus comprising: A processing system, comprising processor circuitry and memory circuitry for storing code, is configured to cause the device to: Obtain a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with a Service Level Agreement (SLA) of the network slice; Obtain load information associated with the network slice of the wireless network; The physical resource block (PRB) allocation for the network slice is selected based on the latency threshold and the load information. as well as The Network Slice Management Function (NSMF) outputs an indication to accept or reject the request associated with the network slice based on the PRB allocation of the network slice.

2. The device according to claim 1, wherein: The request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice; and The PRB allocation for the network slice is further selected based on the throughput threshold.

3. The device of claim 1, wherein the request associated with the network slice is obtained from the NSMF.

4. The apparatus of claim 1, wherein the processing system is further configured to cause the apparatus to: The appropriate PRB allocation for the network slice is selected for each cell in the set of cells of the wireless network associated with the network slice, based on the PRB allocation of the network slice. The indication for accepting or rejecting the request associated with the network slice is based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation for the network slice of each cell in the set of cells.

5. The apparatus of claim 4, wherein the processing system is further configured to cause the apparatus to: Output an indication of the corresponding PRB allocation for the network slice of each cell in the set of cells.

6. The device of claim 4, wherein the indication for accepting or rejecting the request associated with the network slice satisfies the latency threshold according to a threshold proportion of the set of cells.

7. The apparatus of claim 1, wherein the processing system is further configured to cause the apparatus to: Multiple PRBs are reserved for the network slice within a time period based on the PRB allocation of the network slice.

8. The apparatus of claim 7, wherein the processing system is further configured to cause the apparatus to: Based on reserving the plurality of PRBs for the network slice, an instruction is output to activate the network slice within the time period; and An instruction to deactivate the network slice is output based on the expiration of the stated time period.

9. The device of claim 1, wherein the PRB allocation for selecting the network slice is based on one or more parameters associated with the network slice. The one or more parameters include: The load information, the frequency band associated with the network slice, the number of user equipment (UE) associated with the network slice, the type of environment of the network slice, the UE service distribution associated with the network slice, the cell type associated with the network slice, the channel quality indicator (CQI) associated with the network slice, the modulation and decoding scheme (MCS) associated with the network slice, or a combination thereof.

10. The device of claim 9, wherein, in order to select the PRB allocation for the network slice, the processing system is configured to cause the device to: The appropriate PRB allocation for the network slice is selected for each cell in the set of cells of the wireless network associated with the network slice, based on one or more parameters associated with the network slice.

11. The device of claim 9, wherein the PRB allocation of the network slice is based on the latency threshold that satisfies a threshold ratio for the number of UEs associated with the network slice.

12. The device of claim 1, wherein the load information includes simulated load information of a set of cells of the wireless network associated with the network slice, observed load information of the set of cells of the wireless network associated with the network slice, or both.

13. A method for network slice management in a wireless network, the method comprising: Receive a request associated with a network slice of the wireless network at a device associated with service management of the wireless network, the request indicating a latency threshold associated with a service level agreement (SLA) of the network slice; Receive load information associated with the network slice of the wireless network; The physical resource block (PRB) allocation for the network slice is selected based on the latency threshold and the load information. as well as Send an indication to the Network Slice Management Function (NSMF) and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

14. The method of claim 13, wherein: The request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice; and The PRB allocation for the network slice is further selected based on the throughput threshold.

15. The method of claim 13, wherein the request associated with the network slice is received from the NSMF.

16. The method according to claim 13, further comprising: The appropriate PRB allocation for the network slice is selected for each cell in the set of cells of the wireless network associated with the network slice, based on the PRB allocation of the network slice. The indication for accepting or rejecting the request associated with the network slice is based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation for the network slice of each cell in the set of cells.

17. The method according to claim 16, further comprising: Send an instruction for the corresponding PRB allocation for the network slice of each cell in the set of cells.

18. The method of claim 16, wherein the indication for accepting or rejecting the request associated with the network slice satisfies the latency threshold according to a threshold proportion of the set of cells.

19. The method according to claim 13, further comprising: Multiple PRBs are reserved for the network slice within a time period based on the PRB allocation of the network slice.

20. The method according to claim 19, further comprising: Instructions to activate the network slice within the time period are sent based on the multiple PRBs reserved for the network slice; as well as An instruction to deactivate the network slice is sent upon the expiration of the stated time period.

21. The method of claim 13, wherein the PRB allocation for selecting the network slice is based on one or more parameters associated with the network slice. The one or more parameters include: The load information, the frequency band associated with the network slice, the number of user equipment (UE) associated with the network slice, the type of environment of the network slice, the UE service distribution associated with the network slice, the cell type associated with the network slice, the channel quality indicator (CQI) associated with the network slice, the modulation and decoding scheme (MCS) associated with the network slice, or a combination thereof.

22. The method of claim 21, wherein selecting the PRB allocation for the network slice comprises: The appropriate PRB allocation for the network slice is selected for each cell in the set of cells of the wireless network associated with the network slice, based on one or more parameters associated with the network slice.

23. The method of claim 21, wherein the PRB allocation of the network slice is based on the latency threshold that the network slice satisfies a threshold ratio for the number of UEs associated with the network slice.

24. The method of claim 13, wherein the load information includes simulated load information of a set of cells of the wireless network associated with the network slice, observed load information of the set of cells of the wireless network associated with the network slice, or both.

25. An apparatus associated with service management of a wireless network, the apparatus comprising: A component for receiving a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with a Service Level Agreement (SLA) of the network slice; A component for receiving load information associated with the network slice of the wireless network; A component for selecting the physical resource block (PRB) allocation for the network slice based on the latency threshold and the load information; and A component for sending an indication to the Network Slice Management Function (NSMF) and, based on the PRB allocation of the network slice, to accept or reject the request associated with the network slice.

26. A non-transitory computer-readable medium storing code for network slice management in a wireless network, the code including instructions executable by a processing system to perform the following operations: Obtain a request associated with a network slice of the wireless network, the request indicating a latency threshold associated with a Service Level Agreement (SLA) of the network slice; Obtain load information associated with the network slice of the wireless network; The physical resource block (PRB) allocation for the network slice is selected based on the latency threshold and the load information. as well as The Network Slice Management Function (NSMF) outputs an indication to accept or reject the request associated with the network slice based on the PRB allocation of the network slice.

27. The non-transitory computer-readable medium according to claim 26, wherein: The request associated with the network slice further indicates a throughput threshold associated with the SLA of the network slice; and The PRB allocation for the network slice is further selected based on the throughput threshold.

28. The non-transitory computer-readable medium of claim 26, wherein the request associated with the network slice is obtained from the NSMF.

29. The non-transitory computer-readable medium of claim 26, wherein the instructions are further executable by the processing system to: The appropriate PRB allocation for the network slice is selected for each cell in the set of cells of the wireless network associated with the network slice, based on the PRB allocation of the network slice. The indication for accepting or rejecting the request associated with the network slice is based on the corresponding PRB utilization at each cell in the set of cells and the corresponding PRB allocation for the network slice of each cell in the set of cells.

30. The non-transitory computer-readable medium of claim 29, wherein the instructions are further executable by the processing system to: Output an indication of the corresponding PRB allocation for the network slice of each cell in the set of cells.

Images