OPTIMIZING USER EUIPQMENT SERVICE LEVEL AGREEMENT VIOLATIONS FOR NETWORK SLICE ALLOCATION TECHNICAL FIELD [0001] The present disclosure relates generally to communications, and more particularly to communication methods and related devices and nodes supporting encoding and decoding. BACKGROUND [0002] Network slicing is one of the fundamental features of 5G systems which aims to bring flexibility and scalability. Network slicing enables using a single physical infrastructure to form multiple segregated logical networks, each tailored for a particular type of service or need. Since 5G is aimed to provide a framework for a diverse device ecosystem and use cases, networking with one size fits all method may not work, hence network slicing becomes significant. Network slicing helps to achieve better resource utilization, traffic isolation, high degree of automation and granular SLA (Service Level Agreement) observation. [0003] Network slicing techniques were standardized from 3GPP Rel-15 onwards and applicable to NR (New Radio) SA (stand-alone) Option 2 deployments which implies NR SA capable UE (user equipment) connected to NR SA RAN (NR-SA-radio access network) along with 5G Core network. Each network slice uses a set of network resources which could be physical or virtual network functions. [0004] 3GPP TS 23.501 specifies the network slicing framework for slice identification and selection in the RAN and core network domains. The network slicing is based on the Single Network Slice Selection Assistance Information (S-NSSAI). Tuple of PLMNID (Public Land Mobile Network Identity) and Single Network Slice Selection Assistance information (S- NSSAI) are used for slice differentiation. [0005] For slice provisioning, the NSSAIs (Network Slice Selection Assistance information) must be consistently provisioned in each tracking area in the RAN. Each network slice is associated with SLAs (Service Level Agreements). Each SLA describes service expectations and is agreed between service provider and consumer. A SLS (Service Level Specification) is derived from SLAs. These are the technical representation of the SLA requirements on the network level.3GPP has specified a list of service attributes as part of the service profile (ServiceProfile) in TS 28.541. A combination of these attributes might be sufficient to meet the SLA between the service provider and consumer. The service profile captures the E2E (end to end) network requirements of a network slice. The related attributes need to be further translated into RAN, Transport, and Core Network domain-specific attributes represented in 3GPP TS 28.541 through a corresponding slice profile (SliceProfile). Each domain will have performance target as per slice profile depending on type of service e.g., in RAN for eMBB (enhanced mobile broadband) type of slice, it could be throughput, while in uRLLC(ultra-reliable low latency communication), it could be latency, and so on. [0006] In RAN, to assure resource availability and better traffic management, NR Radio Resource Partitioning can be done for NR cell resources across PLMNs, network slices (S- NSSAIs), and service traffic flows (5QIs (5G QoS Identifiers)). The RAN scheduler monitors and updates their resource utilization during each Transmission Time Interval (TTI) for each resource partition to assure that the assigned resource shares are maintained. [0007] When radio resources are available, they can flexibly be shared among the partitions. But when there is a shortage of radio resources in the NR cell, that indicates resource contention, each partition is confined to use its configured share. [0008] Current scheduling for partitions in a RAN can be done in a way that the scheduling probability for bearers is adjusted dependent on the current resource utilization of the partitions that are mapped to along with user radio conditions. The scheduler monitors the resource utilization per partition and adjusts the scheduling probability per slot (TTI) which enables the timely enforcement of the allocated resource shares.5Qis is associated for each QoS (Quality of Service) and follows 3GPP standardized QoS characteristics. [0009] Figure 1 covers an example of how different QoS requirement services gets scheduled. Figure 1 illustrates the current architecture of radio resource provisioning. Different 5G QoS identifiers (5QIs) can be associated with different network slices. Each slice can have configured radio resource ratio mentioned as partition ½ etc. In the system, certain thresholds can be defined for each partition to identify the usage statistics. For example, for partition 1, the physical resource block (PRB) usage equal to 80% can be set as a threshold. The threshold may depend on the service type. In Figure 1, these thresholds are highlighted as X/Y. Partition 1 and Partition 2 are shown as being overutilized in the lower part of Figure 1. High priority services can be configured in a way that they will get prioritized access to radio resources even during resource contention. In Figure 1, the priority partition refers to such a radio resource partition that provides prioritized access. [0010] There currently exist certain challenge(s). Currently, a scheduler utilizes resources which are available and assigns to UEs as per the priorities defined by respective 5Qis based on MCS (Modulation and coding scheme) feedback received from the UE. [0011] For a defined partition, proactive approach of SLA drift is not considered i.e., for upcoming measurement period whether SLA is going to be fulfilled or not, this information is simply not considered by the scheduler. Radio resources though configured by vendor as per service provider spectrum (Bandwidth) but at peak utilization, available spectrum (Bandwidth) could be a limiting factor for fulfilling SLAs for all admitted UEs. There is a fix set of available spectrum (Bandwidth) which can serve a simultaneous finite number of UEs with certain minimum rate. [0012] Since the RAN part of network deals with air interface where conditions do not remain static and can vary, this may lead to varied RF (radio frequency) health. This phenomenon may cause increased requirement of radio resources (spectrum) to achieve similar kind of SLA performance. Thus, the problem in existing solution can be defined in below two statements 1. Unavailability of proactive SLA drift detection. 2. Non optimized resource allocation for served UEs. [0013] During no resource contention, resources can be utilized from other partitions as well. A main issue arises when there is resource contention since in similar priority also i.e., 5QI there will be multiple users with diverse radio conditions. UEs with good radio conditions will be allocated with most of radio resources while users at cell edge and distant location will get a lower number of shares to sustain the Service SLA. Though the QoS requirements are the same, users with good radio may overachieve the desired SLA because of higher share of resources while other users may be deprived of resources and cannot meet SLAs. This kind of resource contention will result in non-optimized resource allocation and less slice user accommodation. In the case of eMBB, though scheduler can calculate the transport block size and accordingly throughput it can provide, but still, it does not intelligently allocate the resource share among available users and statically uses MCS. Also, the current partition ratios are statically configured in Managed Object (MO class) e.g., a partition can be reserved in under below hierarchy GNBDUFunction>ResourceAllocationPolicy and spectrumsharedl parameter. [0014] Such SLA violation instances may result in penalty to service provider as opposed to slice monetization and will result in poor customer perception. The current scheduler also lacks co-ordination with neighbor cells and calculations for proactive decision to preempt resources to calculate the QoS. [0015] Mechanisms available in the prior art such as U.S. patent publication no. 20210160897A1 include minimization of weighted sum of SLA violations. The SLA determination is directly based on computed Key Performance Indicators (KPIs); however, the determination of weights may not be based on specific parameters. Further, U.S. patent application publication no.20200296615A1 proposes multiple optimization functions that are used to determine threshold parameters to realize a self-organizing network, which may be understood to be computationally expensive, and a generic solution that does not consider analysis of attributes that may influence SLA violation criteria. SUMMARY [0016] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. Various embodiments mitigate some of these issues in two stages: 1. During PDU session establishment, and, 2. During ongoing PDU session. [0017] Since current schedulers admit the UEs based on resource utilization and allocate resources on their RF condition basis, the current schedulers essentially do not guarantee the SLA targets for most of the UEs – primarily just UEs which are in very good radio conditions. Various embodiments estimate the target key performance indicator(s) (KPI) [performance metric for SLA] during admission guaranteeing minimum resources to meet SLA during resource contention so that freed up resources can be utilized to other users having similar QoS requirements but are deprived of resources due to bad RF health or high utilization, also help in deciding proactively at scheduler, the PDCCH CCE (physical downlink control channel – control channel elements) aggregation needed to comply with SLA. Various embodiments include SLA drift detection for the UEs w.r.t their identified SLA violation cause. During ongoing protocol data unit (PDU) session some embodiments may continuously monitor and forecast the PDU session performance to predict if any SLA drift is going to occur due to UE mobility or preemption of resources so that 5G-NR enabled cell supporting slicing can be prepared to take necessary actions to minimize such occurrences. Dynamic configuration of resource partition based on traffic profile, time of day and UE mobility is enables so that in place of having static configuration, configured spectrum share can meet the slice requirement(s). [0018] According to some embodiments, a method performed in a network node includes performing drift detection in a slice to identify a number of data points in drift in at least one of network specific performance parameters and/or user equipment, UE, specific performance parameters. The method includes obtaining weighting parameters of the at least one of the network specific performance parameters and the UE specific performance parameters. The method includes combining a function of data points in drift of the at least one of the network specific performance parameters and the UE specific performance parameters with each data point of the number of data points in drift weighed by the weighting parameters associated with data point. The method includes determining one or more service level agreement, SLA, violations as a weighted average of individual drift in one or more of the at least one of network specific performance parameters and UE specific performance parameters. The method includes performing an action based on determining the one or more SLA violations. [0019] Analogous network nodes, computer programs, and computer program products are also provided. [0020] Certain embodiments may provide one or more of the following technical advantage(s). With some of the embodiments, each slice will be able to accommodate more UEs with meeting SLAs. This will result in better resource utilization, lower SLA violations, better customer experience, etc. Some embodiments can help in identifying traffic pattern to configure spectrum share for resource partition dynamically which will help in maximizing the resource shares where it is required. SLA drift analysis and configurable weights can provide flexibility to service providers to configure the weightage as per service needs. [0021] According to some other embodiments, a method in a network node includes receiving, from a UE, a UE request for service on a slice. The method includes performing a SLA estimation for the UE for the requested service to predict if any SLA drift is going to occur due to admitting the UE to determine whether or not to admit the UE to the slice, the SLA estimation based on a slice service type of the slice. The method includes determining whether or not SLA has been met. The method includes responsive to the SLA being met based on the SLA estimation, admitting the UE to the slice. [0022] Analogous network nodes, computer programs, and computer program products are also provided. BRIEF DESCRIPTION OF THE DRAWINGS [0023] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings: [0024] Figure 1 is an illustration of how different QoS requirement services gets scheduled; [0025] Figure 2 is a block diagram illustrating the role of NSMF in slice performance management; [0026] Figure 3 is a signaling diagram illustrating transactions between NSMF and NSSMF; [0027] Figure 4A is a flow chart illustrating operations of a network node in accordance with some embodiments; [0028] Figure 4B is an illustration showing detection of drift in accordance with some embodiments; [0029] Figures 5-15 are flow charts illustrating operations of a network node according to some embodiments of inventive concepts; [0030] Figure 16 is a block diagram of a service management and orchestration platform which can host non-RT RIC module consisting of non-RT RIC applications (rApps) according to some embodiments; [0031] Figure 17 is a block diagram of a communication system in accordance with some embodiments; [0032] Figure 18 is a block diagram of a user equipment in accordance with some embodiments; [0033] Figure 19 is a block diagram of a network node in accordance with some embodiments; [0034] Figure 20 is a block diagram of a host, which may be an embodiment of the host of Figure 17 in accordance with some embodiments; [0035] Figure 21 is a block diagram of a virtualization environment in accordance with some embodiments; and [0036] Figure 22 shows a communication diagram of a host communicating via a network node with a user equipment over a partially wireless connection in accordance with some embodiments. DETAILED DESCRIPTION [0037] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. , in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment. [0038] As previously indicated, target KPI is estimated during admission guaranteeing minimum resources to meet SLA during resource contention so that freed up resources can be utilized to other users having similar QoS requirements but are deprived of resources due to bad RF health or high utilization. The various embodiments can be realized in Slice Manager or O&M (Operation and Maintenance) or in SMO (Service Management and Orchestration). It can also be in form of a rAPP in case of O-RAN (open radio access network). [0039] The first step in some embodiments is to identify the optimal value of resource partition configuration. Traffic pattern analysis with the use of Machine Learning (ML) based approaches can achieve this. This includes estimation of suitable resource partition configuration parameter dynamically (as opposed to the current approach where the configuration for this parameter is static) based on the resource requirements of the slices. This can be computed from KPIs derived from various counters, such as traffic, resource block utilization, among others. The ML model (such as a constrained optimization problem) would use this information (from KPIs) to estimate the optimal resource partition configuration. The advantage of this approach as compared to static configuration is that it would allow the slice allocation to be done based on the anticipated resource requirements, which would lead to improved slice allocation policy and efficient network utilization (including preemption as per resource requirements). [0040] A SpectrumshareDL parameter is used to configure the resource partition in RAN for each specific slice. Each 5QI traffic can be analyzed for each slice. A counter with a filter PartitionID and a serviceID can be used to monitor the resource utilization for each 5QI type. Traffic and resource utilization combinations will be computed across various slices and time of the day to identify the instances where each slice requires higher share of spectrumshareDL and according to service provider desired weights the respective parameter can be adjusted. Once the spectrum share of resource partition is configured, SLA observability will start during resource contention. [0041] Drift detection (or change point detection) techniques for identifying SLA violations are performed in various embodiments. These techniques can help detect sudden, gradual, or recurring changes in the monitored network and UE parameters, based on the detection technique used. The key advantage of using the drift detection techniques is that they are computationally simpler to implement compared to training and deploying complex machine learning models. Further, these techniques can quickly identify various kinds of drift in the parameters, which makes the technique scalable for time-critical use-cases, for example, where there are several UEs for which such analysis or resource estimation may need to be done. [0042] While drift detection techniques can efficiently detect drift in the monitored parameters and indicate an SLA violation, some embodiments use configurable weights associated with the respective monitored parameters for catering to specific requirements. This may, for example, allow the operator to define weights to give higher priority to specific parameters in comparison to others (by configuring higher values for the weights of the respective parameters), while configuring lower weights for the other parameters. In such a scenario, even though drift may have been detected in either set(s) of parameters, the indication of SLA violation would only be provided when there is significant drift in those parameters corresponding to higher weights, as the overall SLA violation would be determined as a weighted sum of the drifts indicated in respective parameters and the associated weights. An additional advantage of introducing these weights is that they can be configured or changed over time based on specific requirements which the operator may need to cater to. [0043] The various embodiments can be used for the case when a new UE is to be admitted to a slice and the case when a UE in an existing slice may request for additional resources. In the former case, some embodiments use simulated (parameter) data based on the existing UEs in the slice for the slice to proactively estimate SLA violations with respect to the incoming UE. In the latter case, the embodiments can be used on the available network and UE parameters to estimate SLA violations. [0044] To use a service in a slice, a UE must go through UE registration and UE PDU session establishment. In UE registration, the UE registers with a network for a specific slice as per provisioning in UDM (Unified data management) for a subscribed slice. [0045] The various embodiments estimate the SLA indicator / QoS for a UE once the UE requests a PDU session after registration phase. The SLA indicator will be dependent on slice service type i.e., the 5QIs which it is serving.3GPP standard TS 23501 specifies the slice service type as below definition Slice Service Type (SST) Service differentiator (SD) Service Type ₅ HMTC [0046] The SLA indicator/QoS data could be throughput in case of eMBB (enhanced mobile broadband) while for uRLLC (ultra-reliable low-latency communication) case it could be latency. Similarly, V2X (vehicle to everything) will have combination of both and in case of mIoT (massive Internet of Things) it will be device density and HMTC (high performance machine-type communications) will be dependent on use case e.g., if it is mission critical. [0047] QoS data corresponding to a particular service instance i.e., the slice indicates whether the network slice instance delivers services at expected QoS level. [0048] Figure 2 is an illustration of an end-to-end 5G system architecture. The figure shows various network components and how the NSMF guides these components throughout the network to maintain target KPI. As can be seen in Figure 2, to have performance management of network slice in E2E slice architecture, the NSMF (Network Slice Management Function) does all the performance management tracking and perform suitable actions. It generates slice performance measurement data based on performance measurement data related to NSSI (Network slice subnet instance(s)) and/or NFs (network functions) associated with the network slice. NSSI could be RAN or Core related. To monitor each NSSI, the NSMF uses NSSMF (Network Slice Subnet Management Function). [0049] The transactions between NSMF and NSSMF could be policies related to healing when there are SLA breaches or optimization policies as seen in Figure 3. Turning to Figure 3, in operation 1, the NSMF receives NSI (network slice instance) automated optimization policies. In operation 2, the NSMF receives NSSI related performance data. In operation 3, NSI automated optimization is triggered. In operation 4, the NSMF requests the NSSMF to perform optimization actions. In operation 5, the NSSMF performs optimization actions requested by the NSMF. In operation 6, the NSSMF reports the optimization results to the NSMF. [0050] Some embodiments can be part of the NSMF/NSSMF which utilizes the performance data from a respective domain. In the description herein, the RAN part of NSSI will be used to describe the embodiments. Once a UE request for PDU session establishment various type of performance data e.g., related to RF (MCS (Modulation and coding scheme)/CQI (Channel quality index)/distance from the base station etc.), utilization (PRB utilization, number of connected users, TTI utilization, scheduling element utilization), average UE session time, average UE data traffic, list of PDU sessions, packet loss ratio, latency etc. can be used to estimate the QoS data/SLA indicator which UE is going to perceive. [0051] As an example, in the case of an eMBB slice, based on MCS conditions and requested data, a scheduler can determine transmission block size (TBS), falling under resource partition for that slice. The current schedulers will determine best possible case based on radio conditions, but it will not corelate the other UE demands. That means in good RF, a UE may get many resources overachieving the QoS/ SLA indicator while others may starve. The various embodiments, shown summarily in Figures 4A-4B, 5A-5B, continue using RF health indicators while also considering the performance of other users. That means while serving the demand, the first target is to meet the minimum QoS or SLA indicator so that resources above the SLA meeting criteria are not used and available for other users with same QoS requirement. If in same QoS requirement there is lower user count, then UE can further be facilitated with additional resources. Our solution targets to first estimate the SLA indicator or QoS considering the QoS serving of existing UEs and forecasted demand of existing UE during their PDU session lifecycle. Once SLA indicator is forecasted, ML based SLA drift detection can be used to indicate whether the UE will violate the SLA criteria. [0052] A key contributor to some of the embodiments is the SLA violation estimation that may combine drift detected in one more identified network and UE-specific parameters, that may further be combined with one or more operator configurable weight parameters (also referred to as weights) to determine slice allocation. This offers multiple advantages, which includes: a. A simpler method to detect SLA violation, as compared to training large machine learning models which also require significant amount of training data and compute requirements. b. Capturing multiple changes in the network and UE parameters, including sudden, periodic, recurrent, or gradual drift, based on the drift detection approach used. c. Enabling the use of operator-configurable weights in conjunction with drift detection output on the parameters to determine effective slice allocation. d. Extending the approach involving drift detection to determine effect/impact of slice allocation on other resources/entities in the network. [0053] Figure 4A and 5 illustrates operations that the various embodiments may perform. Turning to Fig.4A and 5 in block 501, a network node receives at least one of network specific performances parameters 400 and UE specific performance parameters 402. Thus, a combination of network parameters 400 [e.g., Physical Resource Block (PRB) Utilization, Admission to Rejection UE Ratio, Scheduling Element(SE) Utilization, Average Data Traffic, Avg UE session duration, downlink throughput, number of connected users, cell downtime, uplink received signal strength indicator, RSSI, physical uplink control channel, PUCCH; etc.] and UE parameters 402 [e.g., UE reported Modulation and Coding Scheme (MCS), Distance from Base Station, UE specific Packet Data Unit (PDU) Session list, bearer Quality of Service Class Identifier (QCI/5QI), Channel Quality Indicator (CQI) etc.] may be used to identify drift by means of using a drift detection algorithm in block 404. [0054] In block 503, the network node obtains weighting parameters 406 of the at least one of the network specific performance parameters 400 and the UE specific performance parameters 402 so that a drift detection algorithm 404 can determine the number of data points (taken at respective Reporting Operating Periods (ROPs) in drift in the respective network and UE parameters. This may be numerically represented by a function f, representing the drift, such as number of data points in drift for a parameter. [0055] A violation of SLA(s) may have been caused due to drift in one or more parameters. The nature of drift may also be determined based on the choice of drift detection algorithm selected. [0056] In block 507, the network node combines a function of data points in drift of the at least one of the network specific performance parameters and the UE specific performance parameters with each data point of the number of data points in drift weighed 408 by the weighting parameters 406 associated with the data points. Thus, weighting of the drift detected in individual parameters (represented by f) by weights (determined by operator or from functional knowledge in operation 408 is done during the combining operation. [0057] A combination of the drift across parameters to determine SLA violation is determined. In some embodiments as illustrated in block 509, the network node determines one or more service level agreement, SLA, violations 410 as a weighted average of individual drift in one or more of the at least one of network specific performance parameters (400) and UE specific performance parameters (402). The determination may be done to identify the number of data points in drift within at least one specified time window. This would allow determining SLA violation as weighted average of the individual drift in parameters in operation 410. It would also allow prioritization of parameters for the operator based on any specific network or traffic requirements (e.g., eMBB, URLLC). [0058] In block 511, the network node performs an action based on determining the one or more SLA violations. For example, the SLA violation may be reported to other network nodes, core network nodes, etc. The described mechanism may be used for determining SLA violation(s) for the upcoming ROP. [0059] Figure 4B illustrates an example of detecting SLA violations. The drift detection output is shown on a few parameters in Figure 4B, such as downlink throughput 420, number of connected users 422, cell downtime 424 and uplink RSSI PUCCH 426. The bolded vertical lines indicate the ROPs at which the respective parameters are in drift. In this example, for the ROP 430 on 16 April 2021, the KPIs have drifted once for connected users 422 and thrice for UL RSSI PUCCH 426. Similarly, these numbers are nine, one, four and seven for the respective parameters for the ROP 432 on 26 April 2021. These would be determined by the indicator function f. Further, these may be combined using weights on the respective parameters. This can allow the operator to increase/decrease priority on parameters by assigning suitable weights (lower weight, lower priority). The weighted average is then used to determine SLA violation. [0060] Note that the number of such data points, their aggregation level or time window in which such drift should be detected are configurable parameters in the drift detection algorithm, and the plots in Figure 4B are representative. In the example above, if throughput was the target SLA determined by drift in other parameters shown above, this may be determined by such a weighted average. In the example, it is evident that the throughput KPI continues to be in drift due to other parameters being in drift. Hence, by a suitable choice of parameters and weights, the determination of SLA violation can be estimated by our approach, without the need to train large machine learning models, which also requires training data to be available (and this is often a challenge). [0061] Prior to discussing Figures 6A-16, a general overview of the various embodiments shall be described. If there is not a SLA violation (using the approach discussed above), then the UE is admitted in the slice but if SLA are not met, then first respective root cause analysis is required which can indicate whether the SLA violations are from the UE end or from the network side. As can be seen from the flow chart of Figures 5A and 5B (discussed in detail below), UE capabilities check will help in ensuring the UE is compatible for subscribed service. Further, reported MCS/CQI along with distance from the base station will help in determining the RF health. In case of bad RF health to achieve the SLA indicator, the UE will need higher resources than the UEs which are in good or normal radio conditions. In such scenarios, with the UE admission, it is important to facilitate the UE with such additional resources to maintain the desired QoS. Here, a check on existing UEs which have ongoing PDU sessions is performed. If any UEs which are over QoS target and can be throttled to free up resources which can be supplied to poor radio conditions UEs, then such directives will be passed on to controller which could be part of NSMF or NSSMF. If such UEs are not found in same slice, then a resource request in other resource partition can be generated. If there is no resource contention, then other resource partition can directly lend the resources but in case of resource contention each slice is bound till configured resource partition. In such scenario, the UEs which are above SLA indicators will be identified and if resources will be passed on if that slice can allow such donation. If resources cannot be accommodated and if any neighbor cell is available irrespective of frequency but configured with same slice set will be looked upon for handover possibility if such neighbor can provide either better coverage or additional resources. If any of the condition is met then UE will be redirected to neighbor else UE PDU session will not be established. In case of RF health is good but still SLA drift is detected then evaluation at network side must be performed. For example, if because of high PRB (Physical Resource Block) usage inside a resource partition if a UE cannot meet SLA indicator, then like previous step, a same slice resource partition using existing UEs PDU sessions will be evaluated to identify any candidates which can be throttled down for better resource allocation. If such UEs are found, then with additional resources UE with new PDU session request will be evaluated. If it can meet the SLA criteria, then the UE will be admitted. If UE candidates are not found for throttling or even after throttling, there are not enough resources then subsequent processes will be adopted. [0062] In case of non-resource contention, resources can be borrowed from other slice partitions but in case of resource contention slices will be evaluated if any UEs above SLA indicators exists. If so, then throttling in other slice will be done to see if these resources can be passed on. If resources can be carved out by this exercise, then again a SLA indicator check will be performed if UE will meet SLA or not. If it is fine with additional resources, then UE will be admitted if not or if nor resources are available in other resource partition then best set of neighbors will be searched to which UE will be redirected. [0063] If none of the conditions are met, then UE PDU session request will be rejected at that moment and NSMF will be updated for the cause resources not available. [0064] Operations of the network node 1900 (implemented using the structure of the block diagram of Figure 19) will now be discussed with reference to the flow charts of Figures 6A-15 according to some embodiments. For example, modules may be stored in memory 1904 of Figure 18, and these modules may provide instructions so that when the instructions of a module are executed by respective network node processing circuitry 1902, the network node 1900 performs respective operations of the flow charts. In the description that follows, UE 1800, which is described further below will be used in the description. [0065] Turning to Figures 6A and 7, in block 701, the network node 1900 receives from a UE 1800, a UE request for service on a slice. The UE request may be in the form of a UE registration with the network node 1900 for a specific service on the slice. [0066] In block 703, the network node 1900 performs a QoE/SLA estimation for the UE for the requested service. The estimation is to determine if admission of the UE to the slice will likely result in an SLA violation. Such an estimation may be based on when the function described above will have sudden drift if the UE 1800 is admitted. [0067] For example, in some embodiments, estimation of SLA violations is based on inputs including { ^^ _^ ^{^} ^ ^{^} ^ _^ , ^^ _^ ^{^} ^ ^{^} ^ _^ } parameters from network and UE (here KPIs are computed for UE parameters proactively) and { ^^ _^ ^{^^} ^ _^^ , ^^ _^ ^{^^} ^ _^^ } that are configurable normalized weights (0≤w≤1) to determine parameter importance. [0068] An example of using these parameters and weights is determining that an SLA violation may occur when ^^( ^^ _^ ^{^} ^ ^{^} ^ _^ , ^^ _^ ^{^} ^ ^{^} ^ _^ ) has ”sudden” drift. Here, ^^ can represent any change point (or drift) detection algorithm, e.g., Adaptive Windowing. Once ”sudden” drift is detected in any of the parameters, the network node 1900 predicts SLA violation based on combining effect of drift and weights as [0069] An example of using Adaptive Windowing with inputs ^^ _^ ^{^^} ^ _^^ } is as follows: ^ Initialize Window ^^ for all the network and UE parameters. o For each ^^ ∈ { ^^ _^ ^{^} ^ ^{^} ^ _^ , ^^ _^ ^{^} ^ ^{^} ^ _^ } o Update corresponding ^^ with ^^ o Drop elements from W until | ^^ _^^0 − ^^ _^^1 | > ^^ for splits of ^^ into ^^ ₀ (where ^^ indicates mean) o Mark { ^^ _^ ^{^} ^ ^{^} ^ _^ , ^^ _^ ^{^} ^ ^{^} ^ _^ } in drift when threshold is violated, this is denoted as or ^^( ^^ _^ ^{^} ^ ^{^} ^ _^ ). ^ Compute SLA violation [0070] This results in a robust adaptive model for predicting SLA violations for new UEs. [0071] In block 705, the network node 1900 determines if the SLA has been met. If the SLA has been met, the network node 1900 admits the UE 1800 to the slice. [0072] If the SLA has not been met, the network node 1900 proceeds to block 709, where the network node 1900 determines if bad radio frequency, RF, health resulted in the SLA not being met based on the SLA estimation. [0073] Turning to Figures 6A and 8, in block 801, the network node 1900, responsive to determining that bad RF health resulted in the SLA not being met, transmits diversity availability to the UE 1800. Diversity availability considers sending a same copy of data via different available antennas resulting in redundancy which may be helpful in the event of high errors path. If diversity is not available, the existing link will not be able to provide a good radio to achieve the agreed SLA. [0074] In block 803, responsive to receiving a selection of a new antenna path from the UE 1800, the network node 1900 performs a second SLA estimation and impact on resources for other UEs using the new antenna path to predict if any SLA drift is going to occur due to admitting the UE 1800 to determine whether or not to admit the UE 1800 to the slice, the SLA estimation based on a slice service type of the slice. The second SLA estimation can be performed as described above. [0075] In block 805, the network node 1900, responsive to the SLA being met based on the second SLA estimation, admits the UE 1800 to the slice. [0076] Turning to Figures 6A and 9, responsive to the SLA not being met based on the second SLA estimation or not receiving a selection of a new antenna path, the network node 1900 in block 901 determines a next best slice neighbor. [0077] In block 903, the network node 1900 determines whether or not the next best slice neighbor is available to be used. In block 905, responsive to the next best slice neighbor being available to be used, the network node 1900 admits the UE 1800 to the next best slice neighbor. [0078] In block 907, responsive to the next best slice neighbor not being available to be used, the network node 1900 rejects the UE 1800 from being admitted to the next best slice neighbor. [0079] Turning to Figures 6A and 10, in block 1001, the network node 1900, responsive to determining that bad RF health did not result in the SLA not being met, determines whether or not the UE 1800 is compatible for the service requested on the slice. For example, the UE 1800 may not have enough resources for the service, be on a different platform than the service runs on, etc. [0080] In block 1003, the network node 1900, responsive to determining that the UE 1800 is not compatible for the service requested, rejects the UE 1800 from being admitted to the slice. [0081] Turning to Figures 6A and 11, in block 1101, the network node 1900, responsive to determining that the UE 1800 is compatible for the service requested, determines whether or not network utilization is above a threshold. In block 1103, the network node 1900, responsive to determining that network utilization is below the threshold, admits the UE to the slice. [0082] Turning to Figures 6A and 12, in block 1201, the network node 1900, responsive to determining that network utilization is above the threshold, determines whether or not UEs are available for throttling. [0083] Responsive to determining that UEs are available for throttling, in block 1203, the network node 1900 throttles one or more UEs. In block 1205, the network node 1900 performs, after the throttling of the one or more UEs, a third SLA estimation for the UE 1800 for the requested service to predict if any SLA drift is going to occur due to admitting the UE 1800 to determine whether or not to admit the UE 1800 to the slice, the SLA estimation based on a slice service type of the slice. The second SLA estimation can be performed as described above. [0084] In block 1207, responsive to the SLA being met based on the third SLA estimation, the network node 1900 admits the UE 1800 to the slice. [0085] Turning to Figures 6B and 13, responsive to the SLA not being met based on the third SLA estimation or determining that UEs are not available for throttling, the network node 1900 in block 1301, determines whether or not a low priority slice is available. [0086] In block 1303, the network node 1900, responsive to determining that a low priority slice is not available, determines whether or not resources are available in higher priority slices. In block 1305, the network node 1900, responsive to determining that resources are available in higher priority slices, performs, with additional resources from the higher priority slices, a fourth SLA estimation for the UE 1800 for the requested service to predict if any SLA drift is going to occur due to admitting the UE 1800 to determine whether or not to admit the UE 1800 to the slice, the SLA estimation based on a slice service type of the slice. [0087] In block 1307, the network node 1900, responsive to the SLA being met based on the fourth SLA estimation, borrows the additional resources and admits the UE 1800 to the slice. [0088] Turning to Figures 6B and 14, in block 1401, the network node 1900 responsive to the SLA not being met based on the fourth SLA estimation, finds the next best slice neighbor. The network node 1900 also, in block 1403, responsive to determining that no resources are available in higher priority slices, finds the next best slice neighbor. [0089] In block 1405, the network node 1900, after finding the next best slice neighbor, determines whether or not the next best slice neighbor is available to be used. Responsive to the next best slice neighbor being available to be used, the network node 1900 in block 1407 admits the UE 1800 to the next best slice neighbor. In block 1409, the network node 1900, responsive to the next best slice neighbor is not available to be used, rejects the UE 1800 from being admitted to the next best slice neighbor. [0090] Turning to Figures 6B and 15, in block 1501, the network node 1900 responsive to determining that a low priority slice is available, determines whether or not preemption of resources in the low priority slice is possible. [0091] Responsive to determining that preemption of resources in the low priority slice is possible, in block 1503m the network node 1900 performs, with additional resources preempted from the low priority slice, a fifth SLA estimation for the UE 1800 for the requested service to predict if any SLA drift is going to occur due to admitting the UE 1800 to determine whether or not to admit the UE 1800 to the slice, the SLA estimation based on a slice service type of the slice. [0092] In block 1505, responsive to the SLA being met based on the fifth SLA estimation, preempting (1505) the additional resources and admitting the UE (1712A-1712D, 1800, 2102, 2204) to the slice. [0093] In block 1507, the network node 1900, responsive to the SLA not being met based on the fifth SLA estimation, finds the next best slice neighbor. After finding the next best slice neighbor, in block 1509, the network node 1900 determines whether or not the next best slice neighbor is available to be used. In block 1511, the network node 1900, responsive to the next best slice neighbor being available to be used, admits the UE 1800 to the next best slice neighbor. In block 1513, the network node 1900, responsive to the next best slice neighbor not being available to be used, rejects the UE 1800 from being admitted to the next best slice neighbor. [0094] Various operations from the flow chart of Figure 5 and 7 may be optional with respect to some embodiments of communication devices and related methods. For example, operations of blocks 501 and 709 of Figures 5 and 7 may be optional in some embodiments. [0095] Thus, it can be seen that when UE requests services and KPIs are below threshold, conventional schedulers would directly admit UE instead of evaluating experience the UE would achieve. Conventional schedulers, based on Radio conditions will allocate resources irrespective of over achievement of SLA. Such over allocation may not be optimal in purview of targeting multiple UEs with minimum SLA meet. In contrast, the various embodiments described herein evaluate expected QoE by computing KPI proactively. The various embodiments use drift detection methods in combination with (operator) configurable parameters for SLA violations and RCA for corrective actions. [0096] The various embodiments have no need to solve optimization problems for determining weights on parameters such as SLA violations or KPIs at network/cell level or use large/complex models for estimation. The various embodiments do not need to train individual models at UE level to predict SLA violations within same slice. The various embodiments reduce computation cost as there is no need for periodic model re-training. [0097] The drift detection approaches described above enables quickly predicting SLA violations. The configurable parameters enable incorporating operator or technology-specific parameter importance for SLA estimation. [0098] Model generation and LCM (life cycle management) aspects can be managed at the core side rather than UE. Model generation and LCM (life cycle management) aspects can also be managed at the network node or in the SMO (service management and orchestration). [0099] Turning to Figure 16, the open RAN (O-RAN) Alliance defines O-Cloud as a cloud computing platform comprised of a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN functions, the supporting software components, and the appropriate management and orchestration functions. [0100] The O-RAN Alliance recommends the SMO (Service management and Orchestration) platform which can host non-RT RIC (non-real-time RAN intelligent controller) modules consisting non-RT RIC applications (rApps). The various embodiments described herein can be implemented in form of an rApp hosted on SMO platform which can have offline learning and online inference either in near RT RIC or intelligent eNodebs/gNodebs which are E2 nodes. [0101] Figure 17 shows an example of a communication system 1700 in accordance with some embodiments. [0102] In the example, the communication system 1700 includes a telecommunication network 1702 that includes an access network 1704, such as a radio access network (RAN), and a core network 1706, which includes one or more core network nodes 1708. The access network 1704 includes one or more access network nodes, such as network nodes 1710A and 1710B (one or more of which may be generally referred to as network nodes 1710), or any other similar 3 ^rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 1710 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1712A, 1712B, 1712C, and 1712D (one or more of which may be generally referred to as UEs 1712) to the core network 1706 over one or more wireless connections. [0103] Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1700 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 1700 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system. [0104] The UEs 1712 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 1710 and other communication devices. Similarly, the network nodes 1710 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 1712 and/or with other network nodes or equipment in the telecommunication network 1702 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 1702. [0105] In the depicted example, the core network 1706 connects the network nodes 1710 to one or more hosts, such as host 1716. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1706 includes one more core network nodes (e.g., core network node 1708) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1708. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF). [0106] The host 1716 may be under the ownership or control of a service provider other than an operator or provider of the access network 1704 and/or the telecommunication network 1702, and may be operated by the service provider or on behalf of the service provider. The host 1716 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. [0107] As a whole, the communication system 1700 of Figure 17 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z- Wave, Near Field Communication (NFC) ZigBee, LiFi (Light Fidelity), and/or any low-power wide-area network (LPWAN) standards such as LoRa (Long Range) and Sigfox. [0108] In some examples, the telecommunication network 1702 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1702 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1702. For example, the telecommunications network 1702 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive IoT (Internet of Things) services to yet further UEs. [0109] In some examples, the UEs 1712 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1704 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1704. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e., being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved- UMTS Terrestrial Radio Access Network) New Radio – Dual Connectivity (EN-DC). [0110] In the example, the hub 1714 communicates with the access network 1704 to facilitate indirect communication between one or more UEs (e.g., UE 1712C and/or 1712D) and network nodes (e.g., network node 1710B). In some examples, the hub 1714 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1714 may be a broadband router enabling access to the core network 1706 for the UEs. As another example, the hub 1714 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1710, or by executable code, script, process, or other instructions in the hub 1714. As another example, the hub 1714 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1714 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1714 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1714 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 1714 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices. [0111] The hub 1714 may have a constant/persistent or intermittent connection to the network node 1710B. The hub 1714 may also allow for a different communication scheme and/or schedule between the hub 1714 and UEs (e.g., UE 1712C and/or 1712D), and between the hub 1714 and the core network 1706. In other examples, the hub 1714 is connected to the core network 1706 and/or one or more UEs via a wired connection. Moreover, the hub 1714 may be configured to connect to an M2M service provider over the access network 1704 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1710 while still connected via the hub 1714 via a wired or wireless connection. In some embodiments, the hub 1714 may be a dedicated hub – that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 1710B. In other embodiments, the hub 1714 may be a non-dedicated hub – that is, a device which is capable of operating to route communications between the UEs and network node 1710B, but which is additionally capable of operating as a communication start and/or end point for certain data channels. [0112] Figure 18 shows a UE 1800 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE. [0113] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and/or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). [0114] The UE 1800 includes processing circuitry 1802 that is operatively coupled via a bus 1804 to an input/output interface 1806, a power source 1808, a memory 1810, a communication interface 1812, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 18. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc. [0115] The processing circuitry 1802 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1810. The processing circuitry 1802 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1802 may include multiple central processing units (CPUs). [0116] In the example, the input/output interface 1806 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1800. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device. [0117] In some embodiments, the power source 1808 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1808 may further include power circuitry for delivering power from the power source 1808 itself, and/or an external power source, to the various parts of the UE 1800 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1808. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1808 to make the power suitable for the respective components of the UE 1800 to which power is supplied. [0118] The memory 1810 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read- only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1810 includes one or more application programs 1814, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1816. The memory 1810 may store, for use by the UE 1800, any of a variety of various operating systems or combinations of operating systems. [0119] The memory 1810 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and/or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1810 may allow the UE 1800 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1810, which may be or comprise a device-readable storage medium. [0120] The processing circuitry 1802 may be configured to communicate with an access network or other network using the communication interface 1812. The communication interface 1812 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1822. The communication interface 1812 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1818 and/or a receiver 1820 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1818 and receiver 1820 may be coupled to one or more antennas (e.g., antenna 1822) and may share circuit components, software or firmware, or alternatively be implemented separately. [0121] In the illustrated embodiment, communication functions of the communication interface 1812 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short- range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol/internet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth. [0122] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1812, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient). [0123] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input. [0124] A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and/or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 1800 shown in Figure 18. [0125] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. [0126] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators. [0127] Figure 19 shows a network node 1900 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). [0128] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). [0129] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs). [0130] The network node 1900 includes a processing circuitry 1902, a memory 1904, a communication interface 1906, and a power source 1908. The network node 1900 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1900 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1900 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1904 for different RATs) and some components may be reused (e.g., a same antenna 1910 may be shared by different RATs). The network node 1900 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1900, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1900. [0131] The processing circuitry 1902 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 1900 components, such as the memory 1904, to provide network node 1900 functionality. [0132] In some embodiments, the processing circuitry 1902 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1902 includes one or more of radio frequency (RF) transceiver circuitry 1912 and baseband processing circuitry 1914. In some embodiments, the radio frequency (RF) transceiver circuitry 1912 and the baseband processing circuitry 1914 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1912 and baseband processing circuitry 1914 may be on the same chip or set of chips, boards, or units. [0133] The memory 1904 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 1902. The memory 1904 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 1902 and utilized by the network node 1900. The memory 1904 may be used to store any calculations made by the processing circuitry 1902 and/or any data received via the communication interface 1906. In some embodiments, the processing circuitry 1902 and memory 1904 is integrated. [0134] The communication interface 1906 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 1906 comprises port(s)/terminal(s) 1916 to send and receive data, for example to and from a network over a wired connection. The communication interface 1906 also includes radio front-end circuitry 1918 that may be coupled to, or in certain embodiments a part of, the antenna 1910. Radio front-end circuitry 1918 comprises filters 1920 and amplifiers 1922. The radio front-end circuitry 1918 may be connected to an antenna 1910 and processing circuitry 1902. The radio front-end circuitry may be configured to condition signals communicated between antenna 1910 and processing circuitry 1902. The radio front-end circuitry 1918 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1918 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1920 and/or amplifiers 1922. The radio signal may then be transmitted via the antenna 1910. Similarly, when receiving data, the antenna 1910 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1918. The digital data may be passed to the processing circuitry 1902. In other embodiments, the communication interface may comprise different components and/or different combinations of components. [0135] In certain alternative embodiments, the network node 1900 does not include separate radio front-end circuitry 1918, instead, the processing circuitry 1902 includes radio front-end circuitry and is connected to the antenna 1910. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1912 is part of the communication interface 1906. In still other embodiments, the communication interface 1906 includes one or more ports or terminals 1916, the radio front-end circuitry 1918, and the RF transceiver circuitry 1912, as part of a radio unit (not shown), and the communication interface 1906 communicates with the baseband processing circuitry 1914, which is part of a digital unit (not shown). [0136] The antenna 1910 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 1910 may be coupled to the radio front-end circuitry 1918 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 1910 is separate from the network node 1900 and connectable to the network node 1900 through an interface or port. [0137] The antenna 1910, communication interface 1906, and/or the processing circuitry 1902 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna 1910, the communication interface 1906, and/or the processing circuitry 1902 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment. [0138] The power source 1908 provides power to the various components of network node 1900 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1908 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1900 with power for performing the functionality described herein. For example, the network node 1900 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1908. As a further example, the power source 1908 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. [0139] Embodiments of the network node 1900 may include additional components beyond those shown in Figure 19 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 1900 may include user interface equipment to allow input of information into the network node 1900 and to allow output of information from the network node 1900. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1900. [0140] Figure 20 is a block diagram of a host 2000, which may be an embodiment of the host 1716 of Figure 17, in accordance with various aspects described herein. As used herein, the host 2000 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 2000 may provide one or more services to one or more UEs. [0141] The host 2000 includes processing circuitry 2002 that is operatively coupled via a bus 2004 to an input/output interface 2006, a network interface 2008, a power source 2010, and a memory 2012. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 18 and 19, such that the descriptions thereof are generally applicable to the corresponding components of host 2000. [0142] The memory 2012 may include one or more computer programs including one or more host application programs 2014 and data 2016, which may include user data, e.g., data generated by a UE for the host 2000 or data generated by the host 2000 for a UE. Embodiments of the host 2000 may utilize only a subset or all of the components shown. The host application programs 2014 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 2014 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 2000 may select and/or indicate a different host for over-the-top services for a UE. The host application programs 2014 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc. [0143] Figure 21 is a block diagram illustrating a virtualization environment 2100 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 2100 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. [0144] Applications 2102 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 2100 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. [0145] Hardware 2104 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 2106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 2108A and 2108B (one or more of which may be generally referred to as VMs 2108), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 2106 may present a virtual operating platform that appears like networking hardware to the VMs 2108. [0146] The VMs 2108 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 2106. Different embodiments of the instance of a virtual appliance 2102 may be implemented on one or more of VMs 2108, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. [0147] In the context of NFV, a VM 2108 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 2108, and that part of hardware 2104 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 2108 on top of the hardware 2104 and corresponds to the application 2102. [0148] Hardware 2104 may be implemented in a standalone network node with generic or specific components. Hardware 2104 may implement some functions via virtualization. Alternatively, hardware 2104 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 2110, which, among others, oversees lifecycle management of applications 2102. In some embodiments, hardware 2104 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 2112 which may alternatively be used for communication between hardware nodes and radio units. [0149] Figure 22 shows a communication diagram of a host 2202 communicating via a network node 2204 with a UE 2206 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1712A of Figure 17 and/or UE 1800 of Figure 18), network node (such as network node 1710A of Figure 17 and/or network node 1900 of Figure 19), and host (such as host 1716 of Figure 17 and/or host 2000 of Figure 20) discussed in the preceding paragraphs will now be described with reference to Figure 22. [0150] Like host 2000, embodiments of host 2202 include hardware, such as a communication interface, processing circuitry, and memory. The host 2202 also includes software, which is stored in or accessible by the host 2202 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 2206 connecting via an over-the-top (OTT) connection 2250 extending between the UE 2206 and host 2202. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 2250. [0151] The network node 2204 includes hardware enabling it to communicate with the host 2202 and UE 2206. The connection 2260 may be direct or pass through a core network (like core network 1706 of Figure 17) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet. [0152] The UE 2206 includes hardware and software, which is stored in or accessible by UE 2206 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 2206 with the support of the host 2202. In the host 2202, an executing host application may communicate with the executing client application via the OTT connection 2250 terminating at the UE 2206 and host 2202. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 2250 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 2250. [0153] The OTT connection 2250 may extend via a connection 2260 between the host 2202 and the network node 2204 and via a wireless connection 2270 between the network node 2204 and the UE 2206 to provide the connection between the host 2202 and the UE 2206. The connection 2260 and wireless connection 2270, over which the OTT connection 2250 may be provided, have been drawn abstractly to illustrate the communication between the host 2202 and the UE 2206 via the network node 2204, without explicit reference to any intermediary devices and the precise routing of messages via these devices. [0154] As an example of transmitting data via the OTT connection 2250, in step 2208, the host 2202 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 2206. In other embodiments, the user data is associated with a UE 2206 that shares data with the host 2202 without explicit human interaction. In step 2210, the host 2202 initiates a transmission carrying the user data towards the UE 2206. The host 2202 may initiate the transmission responsive to a request transmitted by the UE 2206. The request may be caused by human interaction with the UE 2206 or by operation of the client application executing on the UE 2206. The transmission may pass via the network node 2204, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 2212, the network node 2204 transmits to the UE 2206 the user data that was carried in the transmission that the host 2202 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 2214, the UE 2206 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 2206 associated with the host application executed by the host 2202. [0155] In some examples, the UE 2206 executes a client application which provides user data to the host 2202. The user data may be provided in reaction or response to the data received from the host 2202. Accordingly, in step 2216, the UE 2206 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of the UE 2206. Regardless of the specific manner in which the user data was provided, the UE 2206 initiates, in step 2218, transmission of the user data towards the host 2202 via the network node 2204. In step 2220, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 2204 receives user data from the UE 2206 and initiates transmission of the received user data towards the host 2202. In step 2222, the host 2202 receives the user data carried in the transmission initiated by the UE 2206. [0156] In an example scenario, factory status information may be collected and analyzed by the host 2202. As another example, the host 2202 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 2202 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 2202 may store surveillance video uploaded by a UE. As another example, the host 2202 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 2202 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and/or transmitting data. [0157] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 2250 between the host 2202 and UE 2206, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 2202 and/or UE 2206. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 2250 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 2250 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 2204. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 2202. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 2250 while monitoring propagation times, errors, etc. [0158] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware. [0159] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally. [0160] References are identified below 1. US 20210160897A1 - System and Methods for Managing Service Level Agreements over Network Slices 2. US 20200296615A1 - Systems and Methods for a Self-Organizing Network based on User Equipment Information 3. Habibi, Mohammad Asif, et al. "The structure of service level agreement of slice-based 5G network." arXiv preprint arXiv:1806.10426 (2018). 4. https://www.o-ran.org