WO2024002535A1

WO2024002535A1 - Method and system for adjusting resource allocation based on business risk

Info

Publication number: WO2024002535A1
Application number: PCT/EP2023/057062
Authority: WO
Inventors: Ulf Eriksson; Johan Silvander; Peter ÖHLÉN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-07-01
Filing date: 2023-03-20
Publication date: 2024-01-04
Also published as: WO2024005681A1

Abstract

A method performed by a business support system (BSS) in a telecommunications network is provided. The method includes monitoring a plurality of services. The plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement. The method includes determining that a probability of the first service violating the first service level agreement is above a threshold. The method includes calculating a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service. The service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight. The method includes using the modified service allocation weight.

Description

METHOD AND SYSTEM FOR ADJUSTING RESOURCE ALLOCATION BASED ON BUSINESS RISK

TECHNICAL FIELD

[0001] Disclosed are embodiments related to a method and system for adjusting resource allocation based on business risk.

BACKGROUND

[0002] In today’s mobile network (NW), customer requirements on the delivered service are loosely specified (in the sense of not distinguishing between different customer aspects for a specific service), often based on maximum achievable bit rates and loose objectives for availability of services. In other words, customers are treated as a group, not as individuals. The specifications also are technical requirements that fail to address commercial aspects. This works well for mass-market mobile broadband and services which are not business critical, but less well in other contexts.

[0003] There is a desire to expand mobile technology into business-critical services where binding service-level agreements (SLAs) are defined between the customer and the service provider. The SLAs may have legal and/or financial consequences. For example, as part of an SLA, there may be financial obligations defined, with financial impact in terms of penalty payments when the operator cannot fulfil the agreed SLA. Where an operator is providing a business-to-business type service, it is also possible that the receiving party may also have SLAs to fulfill towards the operator, like infrastructure, response time from their side, etc. SLAs may go in both directions between the service provider and consumer.

[0004] There is ongoing development of intent-based automation and possible reasoning logic, both internally within telecommunication companies and also through work in setting standards. Some examples of intent initiatives, and related supporting technologies, are provided in the references below. This can provide a basis for specifying SLAs on a more granular way, both to the customer and between different parts of the network management system.

[0005] REFERENCES TMF IG1253 “Intent in Autonomous Networks”, https://www.tmforum.org/resources/standard/igl253-intent-in-autonomous- networks-vl-1-0/

• TMF623 SLA Management API REST Specification, https://www.tmforum.org/resources/interface/tmf623-sla-management-api-rest- specification-rl 4-5-0/

• Ericsson technology review, “Cognitive processes for adaptive intentbased networking”, https://www.ericsson.com/en/reports-and-papers/ericsson- technology-review/articles/adaptive-intent-based-networking

• Ericsson technology review, “Creating autonomous networks with intentbased closed loops”, https://www.ericsson.com/en/reports-and-papers/ericsson- technology-review/articles/creating-autonomous-networks-with-intent-based- closed-loops

• Silvander. J, “Component Selection with Fuzzy Decision Making”, Procedia Computer Science, Volume 126, 2018, https://doi.Org/10.1016/j.procs.2018.08.089.

SUMMARY

[0006] Other work has contributed to an aggregated view (normally based on a time window) of violations of measurements in the network level such as Key Performance Indicators (KPIs). This aggregated view may then decide if an SLA is broken and the consequences thereof. The consequences can be enforced by other systems, e.g., paying out a penalty fee to the effected customer. When an operator provides services which are mission-critical to a customer, the penalties of breaking such an SLA might be visible on the bottom line in an annual report. In these cases, today’s network has no business-related information about how to prioritize these types of services when the resources in the network must be reallocated, e.g., due to resource shortage.

[0007] Existing solutions do not provide for what should happen, in real time, when there is resource shortage due to problems in the network. They do not describe what network optimizations or SLA information would be used for real-time optimization, or how this would be realized in the communication between the business support system (BSS) and operations support system (OSS) of a telecommunications network. Assuming that minimization of the penalties (or alternatively, maximizing total business income) is the goal, changes to the SLAs on a BSS level can be considered as a violation of a business agreement. Changes of quality of service (QoS) parameters in the network, for example, to improve the possibility of not breaking an SLA, made by the OSS, BSS, or otherwise, is dependent of other customers’ QoS parameter settings. In essence, financial risk mitigation is an important consideration not previously addressed.

[0008] Previous work by the inventors provided for a financial risk evaluator in the BSS which looks after financial performance of current and planned services. Estimates of fulfilment over the aggregation period for the SLA may be used to adjust priorities between different services, to mitigate financial risk. Previous work by the inventors also provided an interface between the BSS and the OSS for communicating real-time priorities for resource allocation at the network level. The work did not discuss in detail how to mitigate estimated SLA violations caused by resource shortages in the network. Embodiments disclosed herein focus on this mitigation.

[0009] The BSS may monitor the SLA objectives and report if violations of these objectives have occurred during a defined measurement period. Currently, no actions to mitigate foreseen violations of the SLA objectives are performed. Proposals have been made to remedy the SLA violations by raising a weight factor for the service which will, or is foreseen to, break or which has broken SLA objectives. However, this solution has some critical issues. The first is the lack of understanding of the business value of the affected service. By empowering a service to cannibalize on resources needed by services with higher business value, the operator’s business can be put at risk, i.e., business risk control is lacking in the proposed solution. The second issue is to raise the weight factor. By doing so, more important services, which perform according to the agreed upon SLAs, can start to mal-perform. Instead of raising the weight of a service, the weight of less important services should be lowered. A third issue is that the probability for a system issue to happen, and a proposed solution to solve a system issue, is not considered. [0010] In embodiments, in order to mitigate SLA violations, trends are calculated for each customer-service tuple, e.g., in terms of fulfillment of the KPIs defined in the SLA. In addition to the most likely outcome, alternate outcomes may be calculated, each with an associated probability. Using this information, embodiments may calculate business risk, including financial results (e.g., revenues and possible penalties), along with an occurrence probability.

[0011] In cases where the financial outcome is outside defined expectations, a reoptimization of the service configuration may be performed. A re-optimization can mean pure service parameter re-configuration as well as re-calculated steering (e.g., financial) weight(s) for service(s) involved. Decisions may be based, e.g., on a high probability of a small penalty payment, or a low probability of a large penalty payment. To optimize the configuration, alternative scenarios may be identified with new priorities for the affected services. For each of these scenarios, new trends may be calculated and evaluated in terms of business risk (e.g., financial outcome) to select the best configuration.

[0012] Embodiments provide a number of advantages. There is a difference in how the OSS/NW, on the one hand, and the BSS , on the other hand, try to keep the contracted SLAs. On the network side, mKPIs are the targets of optimization for the NW. The BSS focuses on the total business, e.g., including customer size, contract size, contract penalties, market trends, and social changes, combined with the NW status. On the BSS side, the different mKPIs may be aggregated in a specific context, e.g., timeframe. The different aggregations might be used together to eventually evaluate if the service level objectives (SLOs) are met. By using service weight adjustment factors, in embodiments, the business aspects are influencing the optimization of the network. This makes it possible to inform the network of which mKPIs it should focus on for its optimization. This is done in a way which does not violate the business agreements and/or business targets on the provider side.

[0013] By predicting a service’s probability of violating its SLA objectives and putting a predicted violation in relation to the service’s business importance, embodiments can calculate the business risk control utility for adding needed resources to the service. When matching services with high business risk control utility (sink services) against services with low business risk control utility (source services), the BSS can optimize the total business control utility. The BSS is then, in embodiments, in a position where it can propose adjustments to the steering of network resource re-allocation based on business risk control. This provides a base for preventive actions.

[0014] By lowering the resource request for the source services, instead of raising it for sink services, embodiments provide a more stable and controlled resource re-allocation of the network. Instead of changing a service’s KPIs, or business importance, embodiments introduce an adjustment measure. This makes it possible to use or create the adjustments in respect to legal and business-related facts, e.g., the value range of an adjustment can depend on these facts. At the same time, embodiments do not tamper with contracted values, which makes it easier to adhere to regulations like sox-compliance.

[0015] According to a first aspect, a method performed by a business support system (BSS) in a telecommunications network is provided. The method includes monitoring a plurality of services, each service being governed by a service level agreement. The plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement. The method includes determining that a probability of the first service violating the first service level agreement is above a threshold. The method includes calculating a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service. The service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight. The method includes using the modified service allocation weight.

[0016] In some embodiments, using the modified service allocation weight comprises transmitting the modified service allocation weight towards an operations support system, OSS, coupled to the BSS. In some embodiments, the probability of the first service violating the first service level agreement corresponds to a time window such that it is the probability of the first service violating the first service level agreement during the time window. In some embodiments, the service weight adjustment is chosen to minimize a number of service agreement violations during the time window. In some embodiments, the service weight adjustment modifies the service allocation weight for the second service for a duration shorter than the time window. In some embodiments, calculating the service weight adjustment for the second service is further based at least in part on business information related to the first service level agreement.

[0017] In some embodiments, the method further includes, for each of the plurality of services other than the second service, calculating a further service weight adjustment for the corresponding service based at least in part on business information related to the corresponding service level agreement and a current performance of the corresponding service. In some embodiments, the method further includes, for each of the plurality of services, creating an order of the plurality of services based on a probability of the corresponding service violating the corresponding service level agreement and business information related to the corresponding service level agreement. In some embodiments, the business information related to the second service level agreement includes financial and legal information related to the second service level agreement. In some embodiments, calculating a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service, comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

[0018] According to a second aspect, a business support system (BSS) is provided. The BSS includes processing circuitry. The BSS includes a memory, the memory containing instructions executable by the processing circuitry. When executed the processing circuitry is configured to monitor a plurality of services, each service being governed by a service level agreement. The plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement. The processing circuitry is further configured to determine that a probability of the first service violating the first service level agreement is above a threshold. The processing circuitry is further configured to calculate a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service. The service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight. The processing circuitry is further configured to use the modified service allocation weight. [0019] According to a third aspect, a computer program is provided, comprising instructions which when executed by the processing circuitry of a node cause the node to perform the method of any of the embodiments of the first or second aspects.

[0020] According to a fourth aspect, a carrier is provided, containing the computer program of the fifth aspect. The carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

[0021] According to a fifth aspect, a business support system (BSS) is provided. The BSS is adapted to monitor a plurality of services, each service being governed by a service level agreement. The plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement. The BSS is adapted to determine that a probability of the first service violating the first service level agreement is above a threshold. The BSS is adapted to calculate a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service. The service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight. The BSS is adapted to use the modified service allocation weight.

[0022]

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0024] FIG. 1 illustrates an overview of the BSS 130 and OSS 132 interactions according to an embodiment.

[0025] FIG. 2 illustrates scenarios for when service weight adjustments are used, according to an embodiment.

[0026] FIG. 3 illustrates a block diagram of the BSS 130 and OSS 132 interacting in a telecommunications network, according to an embodiment.

[0027] FIG. 4 illustrates a sequence diagram according to some embodiments. [0028] FIGS. 5A and 5B illustrate the BSS and SMO interaction according to an embodiment.

[0029] FIG. 6 illustrates a flowchart according to an embodiment.

[0030] FIG. 7 is a block diagram of an apparatus according to an embodiment.

DETAILED DESCRIPTION

[0031] A service which needs more resources to meet its SLA objectives is called a sink service. A service which is abandoning resources to help another service to meet its SLA objectives is called a source service.

[0032] A service allocation weight may be used to utilize the existing resources based on calculated business risks. The cost of an SLA violation might be one factor in the business risk calculation. By using the information of actual and predicted violations, in the business risk calculations, an adaptive regulation of the resource utilization can be achieved. In embodiments, a service weight adjustment factor may be used to lower the resource allocation of a specific service for a limited period. Since an SLA violation might be an aggregated value of KPI violations during a certain period, the service adjustment factor may be used to trade controlled KPI violations for one or more source services against predicted KPI violations for a sink service. This may be done to mitigate an SLA violation (or predicted violation) for a sink service, but at the same time, keep the SLA agreement for the source services.

[0033] Embodiments predict a service’s probability to violate its stipulated SLA objectives. Embodiments may also use business information to calculate business important weights (e.g., as previously described by the inventors). For sink services, embodiments may calculate a service optimization order based on a violation probability and the business important weights. For source services, embodiments may calculate a service weight adjustment order based on contributions from one or more source services to sink services, in respect of the expected violation probability and the business important weights of a service. That is, these orders may be based on business risk utility. Embodiments may calculate a service weight adjustment factor for the source services selected for service weight adjustment. This may be done based on an optimized business risk utility. Embodiments may send the service weight adjustment factor for each selected source service to the NW. The NW may use business risk control information to steer the resource allocation.

[0034] As examples of business information that may be used to create service allocation weights for a service, the BSS may create a service allocation weight for a customer’s service based on financial and legal information. The financial and legal information may include information regarding the customer itself, the affected contract, the consequences of possible SLA violations, and the aggregated state of the service’s SLAs, among other possible sources of information. For example, market perceptions and the like (a type of financial information) may inform how the BSS creates the service allocation weight. It is possible to extend this to a service allocation weight for each of the service’s characteristics defined in the SLA. For example, the service allocation weight may be a vector where each entry of the vector describes a weight specifically tailored for one characteristic of a service defined in the SLA.

[0035] FIG. 1 illustrates an overview of the BSS 130 and OSS 132 interactions according to an embodiment. As shown, there is a financial impact analysis function 104 (which the BSS 130 is responsible for) that takes various inputs and communicates with a resource management function 112 (which the OSS 132 is responsible for). The resource management function 112 uses the input from the financial impact analysis function 104, along with operator defaults and baseline policies 116, among other possible inputs, to control the resource usage at the network domain level, including, e.g., the RAN 118, transport 120, cloud 122, and core 124.

[0036] The BSS 130 is mainly responsible for optimizing financial performance (e.g., revenue, profit, and monetary penalties), managing SLA fulfilment towards customers, and providing priority between customers. One of the inputs to the financial impact analysis function 104 includes SLA information 102. Aspects of the SLA to describe service requirements may include customer service function specifications 102a, customer service performance 102b (such as service level objectives (SLOs)), customer service legal and security information 102c, and customer service financial and penalty information 102d. There may also be other parts of the SLA, some of which may not be technically relevant, e.g., where disputes are handled or customer service provisions. In general, financial impact analysis function 104 may consider any part of the SLA information 102. Financial impact analysis function 104 may also consider other inputs, such as service-specific operator configurations and intents 106, operator defaults and baseline policies 108, and revenue and profit expectations for services 110.

[0037] The OSS 132 is mainly responsible for resource management and resource costs, network service KPI fulfilment, and optimizing resources in cases of conflict. As noted, some of the inputs to the resource management function 112 include input from the financial impact analysis function 104, along with operator defaults and baseline policies 116.

[0038] Other inputs to either the financial impact analysis function 104 or resource management function 114 may include service-related information 112. Service-related information 112 may include network service function specifications 112a, network service KPI specifications 112b, network service legal and security information 112c, network service resource cost limits 112d, and service priorities 112e.

[0039] The key shown in FIG. 1 indicates which aspects are defined for service, created on the BSS level, or are operator configuration and policy.

[0040] The BSS 130 may receive intents in various forms to describe several aspects of the customer services - e.g., the expected functionality of the service (e.g., 112a), legal requirements (e.g., 112c), performance/KPI requirements (e.g., 112b), and financial provisions (e.g., 104). There are also operator-provided intents to the BSS 130 which could be both specific to customer services (e.g., 106) or define global policies for service delivery (e.g., 108), financial goals (e.g., 110), and network operation.

[0041] In the next level of operations, the OSS 132 receives intents from the BSS 130, where parts of these (e.g., the expected functionality of the service (e.g., 112a), legal requirements (e.g., 112c), performance/KPI requirements (e.g., 112b)) have similar scope as on BSS 130 level, and others are introduced by the BSS 130 to optimize network performance.

These can include cost limits (e.g., 112d) and service priorities (e.g., 112e) that the OSS 132 may use for allocating resources to different services and setting relative priorities between different services.

[0042] In setting the priorities, different approaches can be taken: 1. Services assigned to priority in groups, e.g., highest, high, medium, low, lowest.

2. List services in priority order.

3. Penalty parameter for each service.

4. Penalty parameters for individual KPIs.

5. Exact penalty formula for each KPI (can change shape).

One or more of these approaches, among others, may be taken. In one example, option 3 or 4 above may be used, where a penalty parameter defines the penalty of not fulfilling a requirement (or a utility measure for fulfilling a requirement) which can follow different curves. For each KPI, a penalty may be calculated and added to the global penalty.

[0043] An overview of applying an adjustment weight and probability values is now provided. Reference to system processes in FIG. 4 are made in certain instances in this overview, and FIG. 4 is described in more detail later.

[0044] For a system in a “normal” business state, which has a desired behavior, no weight adjustment is necessary. “Normal” here means that the predicted SLA fulfillment is met. The normal service allocation weights are re-calculated over time (e.g., see 410 in FIG. 4) and are adapting to slow system changes describing the system's “normal state” evolution. Unless a system has issues (such as large system state deviations), service weight adjustments are not needed. In this case, a weight adjustment may be calculated as “no adjustment,” meaning that a “no impact” weight adjustment value set is used. This may also be accomplished by a “zero” adjustment weight, meaning that no adjustment is made. The “normal” weights are used when mitigating small system state deviations. The small deviations can be mitigated using the “normal” weights and without impacting the predicted SLA fulfillment over time.

[0045] For a system with an “issue,” some weight adjustment may be necessary. An “issue” here means a large system state deviation. When an “issue” is detected (e.g., see 406 in FIG. 4), a service weight adjustment value aimed to handle the “issue” may calculated (e.g., see 408 in FIG. 4). The calculated service weight adjustment values are provisioned to the target system. For example, an adjustment may lower the weight of a service by a certain amount. As another example, an adjustment may lower the weight of one or more services by a certain amount, and increase the weight of one or more other services by a certain amount, where the amount may vary depending on the specific service. The system may also calculate a probability table for each service, which may be used when addressing the issue, and determining the appropriate weight adjustments. When the service weight adjustment factor is being used, the system may be referred to as being in an “issue adjusted” state. The weight adjustment factor is preferably temporary, and may be applied for a certain time. For example, when the system reaches a “normal” state again, the weight adjustment may be deleted or cleared, such that the “normal” weights are used again. According to one possible implementation, a service allocation weight for an example set of services S1-S4 is calculated or configured as for example [1,8, 8, 2] and wherein, during normal state when no adjustments are needed the service weight adjustments are at its default values at [0,0, 0,0], As a result of some issues being detected, a probability of for example 77% that the SLA for SI will be breached and a weight adjustment of +10 is needed to mitigate such breach are calculated, a 43% probability for S2 not meeting its SLA and a weight adjustment of +4 for mitigation, a 20% probability for S3 with weight adjustment of -1 for mitigation, and a 0% risk of SLA for breach in case of S4. This would result in a service weight adjustment of [10, 4, -1,0] to be used in creating a modified service allocation weight [11 (i.e. 1+10), 12,7,2] or optionally including also the probability values, i.e.

[11177, 12|43,7|20,2|0], When the system is no longer in a “issue adjusted” state, it may revert to the normal state based on the unadjusted original service allocation weight.

[0046] FIG. 2 illustrates scenarios for when service weight adjustments are used according to some embodiments. In embodiments, mKPIs (NW measurements) are related to SLA objectives. How the mKPIs are related to different SLA objectives in the BSS may be unknown to the NW. In each scenario shown in FIG. 2, both the accumulated number of SLA issues and the average number of mKPI issues are plotted against time. There is an SLA violation value (indicated as a horizontal dashed line) which indicates when an SLA violation will occur, and an SLA violation period (indicated as a vertical dashed line) which indicates the time period for which the SLA violation value applies.

[0047] In the first scenario shown (labeled “1”), the average number of mKPI issues in the NW is constant, and the system is in a “normal” mode. The accumulated number of SLA issues have a constant slope, with negligible fluctuations. As indicated in FIG. 2, the number of SLA issues will not pass the SLA violation value (horizontal dashed line) before the SLA violation period (vertical dashed line) is over.

[0048] In the second scenario (labeled “2”), a peak in the mKPI issues appears does gradually goes back to the normal average value. This creates an increase in the accumulated SLA issues and, for a while, a steeper slope than normal is present. Even if the slope of the accumulated SLA issues is back to normal, as the upper dashed line indicates, a violation of the SLA objectives before the SLA validation period is over will occur because of the earlier peak in the mKPI issues. To mitigate this, a new slope which will mitigate the SLA violation is calculated, indicated by the dashed lower line. The difference between the slopes will be used to calculate the service weight adjustment. The service weight adjustment will be used to lower the average number of mKPI issues in the NW, as indicated in the bottom of the figure for second scenario.

[0049] The third scenario (labeled “3”) is the same as second scenario, with one exception. After the mKPI issues peak, the issues continue with the higher level of mKPI issues. Since the SLA violation is expected to happen closer to the current time compared to the second scenario, the service weight adjustment will be more aggressive in the beginning and may then be relaxed if the desired behavior of the mKPI issues is obtained.

[0050] In both the second and third scenarios, the service weight adjustment might decrease the average number of mKPI issues to an extent where the service weight adjustment is not needed to meet the SLA objectives, and the service weight adjustment can be removed in this case. That is, the service weight adjustment may be removed before the SLA violation period expires. The service weight adjustment may also vary during the period, e.g., such that there is a more drastic adjustment initially, that lowers throughout the period based on monitoring of SLA objectives and mKPI issues.

[0051] In the network, performance of the defined KPIs may be measured and reported back to the BSS 130. On the lowest level, these measurements are granular, more or less in raw form. Once they are passed upwards, one or several levels of refinement and aggregation may be performed. This can be close to the network function, in the OSS 132, or in the BSS 130. In the BSS 130, after the performance data is transformed into a suitable form, the fulfillment of the SLA and other requirements may be evaluated. Based on this evaluation, the intents and priorities can be updated to maximize the fulfillment of the operator goals and policies.

[0052] FIG. 3 illustrates a block diagram of the BSS 130 and OSS 132 interacting in a telecommunications network, according to an embodiment. As explained below, FIG. 4 illustrates a sequence diagram according to some embodiments. The sequence diagram in FIG. 4 is related to the block diagram in FIG. 3, and the following discussion should also be understood as related to the sequence that is shown in FIG. 4. The BSS 130, according to some embodiments, is adapted to perform any of the steps described herein, including the steps described with respect to FIGS 3-6 below.

[0053] Schemas for structured data & Data templates (Block B0 (302))

[0054] This block contains schemas used to build structured data in data templates. The schemas can, e.g., be created from scratch, by an open community (such as schema.org), or by a domain specific organization (such as FIBO.org). The schemas support the use of structured data, e.g., in the form of triplets.

[0055] This block contains schemas and templates regarding SLA information collection.

[0056] The data templates can be created as text documents where parts of the document contain structured data with placeholders for values. The values may be added in an instance of the data template (Block BT1).

[0057] Customer SLA Information Collector (Block BT1 (304))

[0058] This block is collecting Customer SLA information. The information is mapped to an instance of a dedicated data temple, which is created in Block B0.

[0059] Rules for Service Weight Adjustment Creation (Block BT2 (308)

[0060] This block is used to create and store rules regarding how the information from Block BT1 influences the calculation of service weight adjustment values. The information which is used to create the rules is governed by a dedicated data template, which is created in Block B0.

[0061] Service Weight Adjustment Creation (Block BT3 (306)) [0062] In this block, the BSS calculates service weight adjustment values based on information collected in Block BT1, the rules defined in Block BT2, and the calculated service weight allocations in Block B3.

[0063] Service Allocation Weight Creation (Block B3 (309))

[0064] In this block, the BSS 130 creates a service allocation weight for a customer’s service based on information collected in Block BT1, and the rules defined in Block BT2. For a specific customer, its instance of the data template is used together with the rules specified for that specific data template. By applying the rules on a specific customer’s data, a service allocation weight may be calculated for that specific customer.

[0065] Service Allocation Weight Interface (Block B4 (310))

[0066] In this block, translation of the service allocation weight is performed, if needed. With the help of the value range of the service allocation weight, values suitable for the corresponding utility functions can be created. This block can support the creation of a priority list, based on the service allocation values. Additionally, the block can handle service weight adjustment values.

[0067] Requirement evaluator (Block B5 (314))

[0068] This block receives intents for network service and priorities from Block B4 and stores these in a database. Using data on network, service state, and performance, typically in the form of KPIs, it evaluates a fulfillment level of all requirements, analyzes identified discrepancies, and calculates individual and global penalties.

[0069] Network optimizer (Block B6 (316))

[0070] In this block, different ways to improve the requirement discrepancies and associated penalties are identified. After selection of the best options in case of multiple possibilities, the chosen actions are taken towards the network 318.

[0071] Data collector (Block B7 (312))

[0072] In this block, different types of data are collected from the network 318 and analyzed to get a comprehensive view of the state of the network 318 and the deployed services. Data is present in various forms, e.g., counters, active measurements, events, etc., which are either used directly or transformed into KPIs that are used to evaluate fulfillment of requirements. On this level, typically data is representing current state and instantaneous values of different measurable items. Data related to the weight steering communication framework used may also be included here. In the intent case, the intent status reports may also be received by this block.

[0073] The particular communication of the blocks as shown is exemplary, as is the distribution of the blocks between the BSS 130 and OSS 132. Other arrangements and communication between blocks are possible.

[0074] FIG. 4 illustrates a sequence diagram according to some embodiments.

[0075] The functionality disclosed in FIG. 4 is shown in five layers, labeled as layers 1-5.

Loosely, these layers indicate the time frame of the functionality. For example, the functionality described in layer 1 typically is infrequent, while the functionality described in layer 5 is real time. This description is approximate, and in some embodiments the time frame of each layer may not be in this precise order. Additionally, the designations “B0),” through “B7)” in the figure refer back to the blocks described with respect to FIG. 3, and illustrate a particular example of how the functionality of those blocks may be implemented.

[0076] Layer 1

[0077] At 402, additional templates for Customer SLA information and service weight adjustment definitions are added.

[0078] At 404, this function makes it possible to create rules which will give service weight adjustment values. This makes it possible to influence the optimization of a network based on the prediction of SLA violations.

[0079] The functions used to calculate service weights adjustments can be implemented with different techniques, e.g., a graph-based execution flow.

[0080] What is shown in layer 1 is a design activity, such as the design of the contract templates. The task to evaluate the need for new or updated contract templates is a continuous task. Releases of new contract templates, however, may be at a fairly low frequency, such as monthly or less frequently for an established CSP. [0081] Nothing for layer 2 is shown. Layer 2 concerns contracts, marketing, and negotiations, and is not specific to service weight adjustment factors.

[0082] Layer 3

[0083] At 406, Customer SLA information is collected, according to data templates created in Block B0. The probability of a SLA violation is calculated.

[0084] At 408, the values of the Customer SLA information and service allocation weights are used to calculate service weight adjustment values, based on the rules created by the function in Layer 1 - BT2 and the information from Layer 3 - B3. This function is triggered when changes to the probability of SLA violations are detected.

[0085] At 410, a service allocation weight will be calculated.

[0086] At 412, the service weight adjustment values are sent to Layer 5 - Block B5.

[0087] The activity shown in layer 3 has several information sources. Each source may trigger a calculation or re-calculation. The information and calculation triggers include BT2 - Layer 1, Bl - Layer 4, and BT1 - Layer 3. These three sources may, for example, create calculations up to several times per hour. If there are many issues in a system, then the frequency can be higher, such as hundreds of calculations per hour.

[0088] Layer 4

[0089] At 414, data regarding the service performance is obtained.

[0090] Layer 5

[0091] At 416, depending on a service’s service weight adjustment values, a specific service resource adjustment is applied to this service.

[0092] At 418, the network optimizes the network based on current information, and at 420, reports of service performance are sent according to measurement settings and event rules.

[0093] Note that the functionality in this layer (layer 5) is mostly asynchronous to the functionality in layers 1-4. Layer 5 may receive steering, such as intent events, with the frequency from Layer 4. [0094] The report communication between Layer 5 and Layer 4 may have two parts. Responses and reports (B7 - Layer 5 to Bl - Layer 4) to the steering events may have a slightly higher frequency than the received events (from B4 - Layer 3 to B5 - Layer 5). This is so because more than one report may be issued while addressing a steering event, such as an intent. There are also the normal measurement streams related to network status, such as in the 5G case. These measurement streams may have a very high reporting frequency. In layer 5, the service control loops, which may be triggered by the intents from layer 4, may be down to real time and realized by closed loop processing.

[0095] The functionality 416-420 in layer 5 - evaluating requirements, optimizing the network based on the evaluation, and measuring service fulfillment - forms a loop that continuously executes. Similarly, the functionality 406-414 in layers 3 and 4 - updating customer business information, calculating service allocation weights and sending them to the OSS, and gathering data on current service performance - forms another loop that continuously executes. As indicated here, these two loops interact with each other.

[0096] FIGS. 5 A and 5B illustrate the BSS and SMO interaction according to an embodiment. As shown in FIG. 5 A, BSS 502 may communicate directly with Service Management and Orchestration (SMO) node 504, for example, where SMO 504 functions as an end-to-end network manager. As shown in FIG. 5B, BSS 502 may also communicate indirectly with SMO 504 through a separate end-to-end network manager 506. The manager 506 may also communicate with other domain managers 508.

[0097] The SMO management function within O-RAN does not currently include an intent interface. There is an ongoing discussion to add intents to the O-RAN SMO. Depending on the scope for the SMO, it could take either the role of an end-to-end network manager (option

1, as shown in FIG. 5 A) or as one domain manager (typically radio access network (RAN)) below a separate end-to-end network manager (option 2, as shown in FIG. 5B). In case of option

2, priorities would most likely need to be passed on (either directly, or after transformation) from the end-to-end manager 506 to the different domain managers 504, 508. Embodiments described herein would impact the intent-interface towards the SMO by adding priorities definitions for communicated service requirements. [0098] FIG. 6 is a flowchart illustrating a process 600, according to an embodiment, performed by a business support system (BSS) in a telecommunications network. Process 600 may begin in step s602.

[0099] Step s602 comprises monitoring a plurality of services, each service being governed by a service level agreement. The plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement.

[0100] Step s604 comprises determining that a probability of the first service violating the first service level agreement is above a threshold.

[0101] Step s606 comprises calculating a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service. The service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight.

[0102] Step s608 comprises using the modified service allocation weight.

[0103] In some embodiments, using the modified service allocation weight comprises transmitting the modified service allocation weight towards an operations support system, OSS, (132), coupled to the BSS (130). In some embodiments, the probability of the first service violating the first service level agreement corresponds to a time window such that it is the probability of the first service violating the first service level agreement during the time window. In some embodiments, the service weight adjustment is chosen to minimize a number of service agreement violations during the time window. In some embodiments, the service weight adjustment modifies the service allocation weight for the second service for a duration shorter than the time window. In some embodiments, calculating the service weight adjustment for the second service is further based at least in part on business information related to the first service level agreement.

[0104] In some embodiments, the method further includes, for each of the plurality of services other than the second service, calculating a further service weight adjustment for the corresponding service based at least in part on business information related to the corresponding service level agreement and a current performance of the corresponding service. In some embodiments, the method further includes, for each of the plurality of services, creating an order of the plurality of services based on a probability of the corresponding service violating the corresponding service level agreement and business information related to the corresponding service level agreement. In some embodiments, the business information related to the second service level agreement includes financial and legal information related to the second service level agreement. In some embodiments, calculating a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service, comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

[0105] FIG. 7 is a block diagram of apparatus 700 (e.g., BSS 130, OSS 132, BSS 502, SMO 504, E2E manager 506, domain manager 508), according to some embodiments, for performing the methods disclosed herein. As shown in FIG. 7, apparatus 700 may comprise: processing circuitry (PC) 702, which may include one or more processors (P) 755 (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., apparatus 700 may be a distributed computing apparatus); at least one network interface 748 comprising a transmitter (Tx) 745 and a receiver (Rx) 747 for enabling apparatus 700 to transmit data to and receive data from other nodes connected to a network 710 (e.g., an Internet Protocol (IP) network) to which network interface 748 is connected (directly or indirectly) (e.g., network interface 748 may be wirelessly connected to the network 710, in which case network interface 748 is connected to an antenna arrangement); and a storage unit (a.k.a., “data storage system”) 708, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. Interface 760 may connect PC 702 and storage unit 708, interface 762 may connect PC 702 and network interface 748, and interface 764 may connect network interface 748 and network 710. In embodiments where PC 702 includes a programmable processor, a computer program product (CPP) 741 may be provided. CPP 741 includes a computer readable medium (CRM) 742 storing a computer program (CP) 743 comprising computer readable instructions (CRI) 744. CRM 742 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 744 of computer program 743 is configured such that when executed by PC 702, the CRI causes apparatus 700 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus 700 may be configured to perform steps described herein without the need for code. That is, for example, PC 702 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[0106] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above described exemplary embodiments. Moreover, any combination of the above-described embodiments in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0107] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

1. A method performed by a business support system, BSS, (130) in a telecommunications network, the method comprising: monitoring (s602) a plurality of services, each service being governed by a service level agreement, wherein the plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement; determining (s604) that a probability of the first service violating the first service level agreement is above a threshold; calculating (s606) a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service, wherein the service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight; and using (s608) the modified service allocation weight.

2. The method of claim 1, wherein using (s608) the modified service allocation weight comprises transmitting the modified service allocation weight towards an operations support system, OSS, (132), coupled to the BSS (130).

3. The method of any one of claims 1-2, wherein the probability of the first service violating the first service level agreement corresponds to a time window such that it is the probability of the first service violating the first service level agreement during the time window.

4. The method of claim 3, wherein the service weight adjustment is chosen to minimize a number of service agreement violations during the time window.

5. The method of any one of claims 3-4, wherein the service weight adjustment modifies the service allocation weight for the second service for a duration shorter than the time window.

6. The method of any one of claims 1-5, wherein calculating (s606) the service weight adjustment for the second service is further based at least in part on business information related to the first service level agreement.

7. The method of any one of claims 1 -6, further comprising, for each of the plurality of services other than the second service, calculating a further service weight adjustment for the corresponding service based at least in part on business information related to the corresponding service level agreement and a current performance of the corresponding service.

8. The method of any one of claims 1-7 further comprising, for each of the plurality of services, creating an order of the plurality of services based on a probability of the corresponding service violating the corresponding service level agreement and business information related to the corresponding service level agreement.

9. The method of any one of claims 1-8, wherein the business information related to the second service level agreement includes financial and legal information related to the second service level agreement.

10. The method of any one of claims 1-9, wherein calculating (s606) a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service, comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

11. A business support system, BSS, (130) comprising: processing circuitry (702); and a memory, the memory containing instructions (744) executable by the processing circuitry (702), whereby when executed the processing circuitry (702) is configured to: monitor a plurality of services, each service being governed by a service level agreement, wherein the plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement; determine that a probability of the first service violating the first service level agreement is above a threshold; calculate a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service, wherein the service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight; and use the modified service allocation weight.

12. The BSS (130) of claim 11, wherein using the modified service allocation weight comprises transmitting the modified service allocation weight towards an operations support system, OSS, (132), coupled to the BSS (130).

13. The BSS (130) of any one of claims 11-12, wherein the probability of the first service violating the first service level agreement corresponds to a time window such that it is the probability of the first service violating the first service level agreement during the time window.

14. The BSS (130) of claim 13, wherein the service weight adjustment is chosen to minimize a number of service agreement violations during the time window.

15. The BSS (130) of any one of claims 13-14, wherein the service weight adjustment modifies the service allocation weight for the second service for a duration shorter than the time window.

16. The BSS (130) of any one of claims 11-15, wherein calculating the service weight adjustment for the second service is further based at least in part on business information related to the first service level agreement.

17. The BSS (130) of any one of claims 11-16, further comprising, for each of the plurality of services other than the second service, calculating a further service weight adjustment for the corresponding service based at least in part on business information related to the corresponding service level agreement and a current performance of the corresponding service.

18. The BSS (130) of any one of claims 11-17 further comprising, for each of the plurality of services, creating an order of the plurality of services based on a probability of the corresponding service violating the corresponding service level agreement and business information related to the corresponding service level agreement.

19. The BSS (130) of any one of claims 11-18, wherein the business information related to the second service level agreement includes financial and legal information related to the second service level agreement.

20. The BSS (130) of any one of claims 11-19, wherein calculating a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service, comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

21. A computer program (743) comprising instructions which when executed by processing circuitry (702) of a node (700), causes the node (700) to perform the method of any one of claims 1-10.

22. A carrier containing the computer program (743) of claim 21, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (742).

23. A business support system, BSS, (130) adapted to: monitor a plurality of services, each service being governed by a service level agreement, wherein the plurality of services includes a first service governed by a first service level agreement and a second service governed by a second service level agreement; determine that a probability of the first service violating the first service level agreement is above a threshold; calculate a service weight adjustment for the second service based at least in part on business information related to the second service level agreement and a current performance of the second service, wherein the service weight adjustment modifies a service allocation weight for the second service to generate a modified service allocation weight that is less than the second service allocation weight; and use the modified service allocation weight.