WO2024005681A1

WO2024005681A1 - Method and system for system optimization using service allocation weighting factors

Info

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

Abstract

A method performed by a business support system (BSS) in a telecommunications network is provided. The method includes calculating a service allocation weight for a service governed by a service level agreement based at least in part on business information related to the service level agreement and a current performance of the service. The method includes translating the service allocation weight to a service prioritization value usable by an operations support system (OSS) coupled to the BSS. The method includes transmitting the service prioritization value towards the OSS.

Description

METHOD AND SYSTEM FOR SYSTEM OPTIMIZATION

USING SERVICE ALLOCATION WEIGHTING FACTORS

TECHNICAL FIELD

[0001] Disclosed are embodiments related to a method and system for system optimization using service allocation weighting factors.

BACKGROUND

[0002] In today’s mobile network, 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.

[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-v 1-1-0/ • TMF623 SLA Management API REST Specification, https://www.tmforum.org/resources/interface/tmf623-sla-management-api-rest- specification-r 14-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] Accordingly, embodiments provide 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. Embodiments also provide an interface between the BSS and the OSS for communicating real-time priorities for resource allocation at the network level.

[0009] Embodiments herein focus on what happens when there is resource shortage in the network. When this happens, the SLAs are not the only components to drive optimization of the affected services. Instead, the service allocation weight will tell the network which service to optimize for. As an example, Customer A has high demanding SLAs but low service allocation weight, while it is the opposite for Customer B. Thus, in embodiments, Customer B’s needs are first satisfied (having the higher service allocation weight) and then Customer A get its share. This might mean that Customer A’s SLAs are broken, but the business relationship with Customer B is considered more valuable by the content service provider (CSP). In this way, embodiments can guard the business relationship and make sure the resource optimization is based on this relationship, in real time. Although the focus is on when resource shortages occur, embodiments are also applicable in other contexts.

[0010] In today’s networks, mostly fixed QoS markings are used to discriminate between different subscribers. The network level is typically managed by the OSS, whereas the SLAs and financial performance is managed by the BSS. As a result, there is a disconnect between financial performance of services and configuration of services in infrastructure. The configuration of services on the BSS level and the OSS level are fairly static and optimized for an average expectation in terms of network service performance and resulting SLA fulfillment. Often this is done on a coarse grouping of subscribers/services (e.g., gold, silver, and bronze), leading to over-fulfillment of SLAs, or penalty payments for not fulfilling SLAs. [0011] Also contributing to this, is that the evaluation of performance is done differently in the BSS level, where performance data is aggregated over measurement periods (typically monthly), and in the OSS level, which looks at the current performance situation in real time.

[0012] Breaking an SLA has a stated consequence according to a contract. The full financial impact of breaking an SLA might be more severe than the stated consequences, due to the reaction of the affected customer. In other cases, breaking an SLA might not render any consequences since the customer might not have fulfilled their obligations of the contract. By using financial and legal information regarding a customer and its contracts, an initial/actual service allocation weight, based on a value range (within the BSS) of a specific service can be calculated. Then, by considering both the actual service allocation weight and the current financial, and legal information, the BSS can recalculate the service allocation weight. The service allocation weight, once translated to a value usable by the OSS, may be used by the OSS to perform instantaneous priorities for fulfilling the various performance requirements on the network level.

[0013] By the BSS’s giving an absolute weight to each service, the weight can be used as a scaling factor in the techniques used for resource allocation in the network. With the help of the service specific weight, the network can take informed decisions based on financial aspects when services in the network cannot be delivered according to contracted performance. This can have the following benefits compared to the current state-of-the-art solutions:

• The resource allocation is based on financial aspects, using service allocation weighting factors, and therefore provides for financial risk mitigation.

• The financial aspects are translated into real-time priorities of instantiated network services, allowing the OSS to make informed real-time decisions based on financial risk mitigation.

• The translation is supported by the value range of the service allocation weight, which gives the OSS the possibility to use a weighting factor which is suitable to a specific utility function.

The translation can be used to create a service priority list. • The proactive approach allows the OSS to optimize network resources from both technical and financial perspectives.

• The BSS is decoupled from real-time requirements in the OSS, regarding network resource optimization.

[0014] According to a first aspect, a method performed by a business support system (BSS) in a telecommunications network is provided. The method includes calculating a service allocation weight for a service governed by a service level agreement based at least in part on business information related to the service level agreement and a current performance of the service. The method includes translating the service allocation weight to a service prioritization value usable by an operations support system (OSS) coupled to the BSS. The method includes transmitting the service prioritization value towards the OSS.

[0015] In some embodiments, translating the service allocation weight to a service prioritization value comprises using range information for the service allocation weight. In some embodiments, transmitting the service prioritization value towards the OSS comprises transmitting range information for the service prioritization value. In some embodiments, the service allocation weight for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement. In some embodiments, the business information related to the service level agreement includes financial and legal information related to the service level agreement.

[0016] In some embodiments, the method further includes re-calculating the service allocation weight based on a current value of the service calculation weight and updated information regarding performance of the service. In some embodiments, calculating a service allocation weight for a service governed by a service level agreement comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

[0017] According to a second aspect, a method performed by an operations support system (OSS) in a telecommunications network is provided. The method includes receiving from a business support system (BSS) coupled to the OSS a service prioritization value for a service governed by a service level agreement. The method includes detecting a resource shortage in the telecommunications network. The method includes causing resources to be reallocated based at least in part on the service prioritization value.

[0018] In some embodiments, receiving from a business support system (BSS) coupled to the OSS a service prioritization value comprises receiving range information for the service prioritization value. In some embodiments, the service prioritization value for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement. In some embodiments, detecting a resource shortage in the telecommunications network comprises evaluating fulfillment of the service level agreement and additional service level agreements for additional services. In some embodiments, causing resources to be re-allocated comprises minimizing penalties for failing to fulfill service level agreements, wherein at least one of the penalties is adjusted based on the service prioritization value. In some embodiments, at least one of the penalties is further adjusted based on a range associated with the service prioritization value.

[0019] According to a third aspect, a business support system (BSS) is provided. The BSS includes processing circuitry; and a memory, the memory containing instructions executable by the processing circuitry. When executed the processing circuitry is configured to calculate a service allocation weight for a service governed by a service level agreement based at least in part on business information related to the service level agreement and a current performance of the service. When executed the processing circuitry is configured to translate the service allocation weight to a service prioritization value usable by an operations support system (OSS) coupled to the BSS. When executed the processing circuitry is configured to transmit the service prioritization value towards the OSS.

[0020] According to a fourth aspect, an operations support system (OSS) is provided. The OSS includes processing circuitry; and a memory, the memory containing instructions executable by the processing circuitry. When executed the processing circuitry is configured to receive from a business support system (BSS) coupled to the OSS a service prioritization value for a service governed by a service level agreement. When executed the processing circuitry is configured to detect a resource shortage in the telecommunications network. When executed the processing circuitry is configured to cause resources to be re-allocated based at least in part on the service prioritization value. [0021] According to a fifth 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.

[0022] According to a sixth 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.

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 penalties associated with individual KPIs calculated and added to form a global penalty, 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 an execution pipeline according to an embodiment.

[0030] FIG. 7 illustrates a flowchart according to an embodiment.

[0031] FIG. 8 illustrates a flowchart according to an embodiment.

[0032] FIG. 9 is a block diagram of an apparatus according to an embodiment.

DETAILED DESCRIPTION

[0033] In some embodiments, the BSS creates 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.

[0034] Service allocation weights may then be translated into a value which is suitable to a corresponding utility function in the OSS, which is referred to herein as a service prioritization value. The OSS may use the service prioritization value with the corresponding utility function to optimize network performance and resource allocation of different services. Because this value is generated by the BSS based on financial information, these actions of the OSS are now influenced by a financial importance value.

[0035] Accordingly, in some embodiments, an OSS which operates on the current state and KPIs to optimize performance and resource allocation of different services, may be controlled by a BSS which aggregates performance measurements (typically over certain time periods) and evaluates these to maximize a financial value of contracted services and generates a current priority of those services. These priorities may be passed from the BSS to the OSS, where the OSS maximizes a corresponding utility function in real time.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

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

[0041] 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.

[0042] 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.

[0043] 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 is calculated and added to the global penalty, as shown in FIG. 2.

[0044] In the OSS 132, the network configuration and resource allocations are optimized to minimize a global penalty, or equivalently, to maximize a utility function. FIG. 2 illustrates penalties associated with individual KPIs calculated and added to form a global penalty, according to an embodiment. As shown, each of KPLa, KPLb, KPLc, and KPLd have a penalty function, and a total penalty is obtained by summing each of the individual penalties. Other penalty function metrics are possible, as well as other aggregation techniques to form a total penalty. Of note, the “penalties” addressed here refer to resource allocation costs associated with utility functions used by the OSS, and should not be confused with penalties (e.g., financial penalties) contained within an SLA (e.g., that may be incurred by breaking a guarantee within the SLA).

[0045] 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.

[0046] 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.

[0047] Schemas for structured data & data templates (Block 0 (“B0”))

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

[0049] 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 by Block 1.

[0050] Business Information Collector (Block 1 (“Bl”))

[0051] This block 304 is collecting financial, and legal, information regarding each customer, the affected contracts, the consequences of the service’s SLA violations, and the aggregated state of the service’s SLAs. All this data plus underlying status data from Block 7 may be used for calculations for estimation/prediction of the SLA state. The information for a specific customer is mapped to an instance of a dedicated data temple, which are created in Block 0. The block 304 may also receive service specifications and other external data.

[0052] Rules for Service Allocation Weight Creation (Block 2 (“B2”))

[0053] This block 308 is used to create and store rules regarding how the information from Block 1 influences the service allocation weights. The information which may be used to create the rules are governed by a dedicated data template, which is created in Block 0. The block 306 may also receive operator provided rules. [0054] Service Allocation Weight Creation (Block 3 (“B3”))

[0055] In this block 306, the BSS 130 creates a service allocation weight for a customer’s service based on information collected in Block 1, and the rules defined in Block 2. 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.

[0056] Service Allocation Weight Interface (Block 4 (“B4”))

[0057] In this block 310, 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.

[0058] Requirement evaluator (Block 5 (“B5”))

[0059] This block 314 receives intents for network service and priorities from Block 4 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.

[0060] Network optimizer (Block 6 (“B6”))

[0061] In this block 316 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.

[0062] Data collector (Block 7 (“B7”))

[0063] In this block 312, 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 312.

[0064] 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.

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

[0066] 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.

[0067] Layer 1

[0068] At 402, a contract template is created which is aimed at a specific business model.

[0069] At 404, a business information template is created to retrieve information regarded as vital to measure financial aspects regarding costumers of a specific type of contracts.

[0070] At 406, based on the information in the business information model, rules are created to calculate the service allocation weights.

[0071] 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.

[0072] Layer 2

[0073] At 408, a contract is created and signed for a specific customer. This contains, among other things, SLAs and their consequences. [0074] At 410, information about identifiers and other data needed to retrieve customer financial data according to the business information template is gathered and put into the customer business information instance.

[0075] What is shown in layer 2 is marketing followed by negotiations. Brand new contracts, as well as updated contracts in the form of new contracts replacing old ones is a continuous activity for a CSP having a healthy business. New contracts, and thereby new data, may happen more frequently than the release of new contract templates in layer 1. For example, the functionality at this stage may happen at least weekly.

[0076] Layer 3

[0077] At 412, updates of the information in a customer business information instance is performed.

[0078] At 414, the updated information is used together with the rules to calculate service allocation weight values.

[0079] At 416, the service allocation weight values and range are adopted to the OSS requirements and sent to the OSS. The corresponding SLA parameters are sent as well, if needed.

[0080] 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 B2 - Layer 1, Bl - Layer 4, and Bl - 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.

[0081] Layer 4

[0082] At 418, data regarding the service performance is obtained.

[0083] Layer 5

[0084] At 420, the network evaluates the information from layer 4 and at 422, optimizes the network based on this information. At 424, reports of service performance are sent according to measurement settings and event rules. [0085] Note that the functionality in this layer (layer 5) is mostly asynchronous to the functionality in layers 1-4. Layer 4 may receive steering, such as intent events, with the frequency from Layer 4.

[0086] The report communication between Layer 5 and Layer 4 may have two parts. Responses and reports (B7 - Layer 5 to B 1 - 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.

[0087] The functionality 420-424 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 412-418 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.

[0088] Having now presented the overall sequence diagram, several additional remarks are now made with respect to specific functionality illustrated in FIG. 4.

[0089] Layer 1 - B2 (“Create rules for service allocation weight calculation, based on business information template”)

[0090] The functionality described here makes it possible to create rules which will give service allocation weights for a customer’s services as a result. Compared to traditional SLA rules, embodiments do not exclusively use the technical parameters in the rules. Instead, embodiments base the rules on financial aspects. This makes it possible to influence the optimization of a network based on financial aspects.

[0091] The functions used to calculate service allocation weights can be implemented with different techniques, e.g., a graph-based execution flow, or fuzzy logic. [0092] Layer 3 - B3 (“Calculate service allocation weights using service allocation weight rules, based on customer business information”)

[0093] The functionality described here may use the values of the financial information to calculate a service allocation weight, based on the rules created by the function in Layer 1 - B2. This function is triggered when changes to the financial, and legal, information is detected. The consequences of breaking an SLA might be part of the financial information. In this case there may be two different aspects. The consequences themselves are static information, but the possibility of breaking an SLA is a dynamic aspect. Embodiments typically do not change the SLAs (e.g., specified consequences) to perform network optimization, since this might be a violation of a business agreement.

[0094] When the consequences are part of the financial information, the network can take informed decisions regarding the evaluation and optimization of the SLAs themselves. This is not possible with the traditional SLA solutions.

[0095] Layer 3- B4 (“Send requirements to OSS”)

[0096] The functionality described here may be responsible for transforming the service allocation weight into a scale which is suitable for the optimization and evaluation functions in Layer 5. This decouples the calculation of a service allocation weight from the requirements on the parameter ranges in the network environment where it will be used. This may give the possibility to use the same service allocation weight measure in different network environments, e.g., mobile networks, Wi-Fi, etc. An additional functionality is the possibility to create a priority list based on the service allocation weight, which can be used by the optimization and evaluation functions in Layer 5.

[0097] Layer 5 - B5 and B6 (“Evaluate requirements on network level” and “Optimize network based on requirements”)

[0098] During a resource shortage in the network, these functions make use of the service allocation weight, or the translated service prioritization value, to evaluate and optimize the network in real-time. The evaluation and optimization are based on financial aspects, but the BSS 130 does not have to be involved in the real-time decisions. Thus, embodiments may break the executional dependencies between the network and the BSS 130 when financial optimizations and evaluations are performed in the network. This is an advantage to the proposed approach.

[0099] FIGS. 5A and 5B illustrate the BSS and SMO interaction according to an embodiment. As shown in FIG. 5A, 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.

[0100] 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.

[0101] As described above, FIG. 4 shows a sequence diagram that includes how to calculate a service allocation weight (occasionally referred to below as a SAW). An example of this process is now described.

[0102] To exemplify how the sequence diagram in FIG. 4 can be implemented, assume a simplified example of a fictional company. The company uses autonomous vehicles to transport special parts of cargos to a specific shipping station. This is not very mission critical for their business and can be considered as a trail. During the discussion with the company the CSP gets the feeling of a medium interest from the company to expand their use of autonomous vehicles.

[0103] B0 - Level 1 (“Create business information template”)

[0104] This component is used to create the template for the business information parameters which shall be part of the service allocation weight creation. The component may include a scope type for which the service allocation weight calculation is performed; and an identification (“ID”) of the instantiated scope type, for which the service allocation weight calculation is performed.

[0105] The information for each parameter used in the scope may be structured as:

• Parameter name

• Parameter description

• The access path to the parameter

• Value ranges

• Unit of measurement (UoM)

• Place holder of the customer Id

[0106] A simplified example using this structure as an example follows:

• Scope type = NWS_service

• Scope: <scope type instance Id>

• Parameter 1

• Name: mission_criticality

• Description: The estimated mission criticality of the delivered services

• Path: GET: https://estimates.comrus.com/lcidj/emc

• Value range: 1 - 10

• UoM = int

• Customer Id: <cid>

• Parameter 2

• Name: long-term_value

• Description: The estimated long-term value of a customer

• Path: GET: https://estimates.comrus.com/jcidj/ltv

• Value range: 1 - 10

• UoM = int

• Customer Id: <cid>

Parameter 3 • Name: financial_value

• Description: The financial value of a customer

• Path: GET: https://finance.comrus.com/lcidj/fcv

• Value range: 0 - 10000000000

• UoM = US cent

• Customer Id: <cid>

[0107] Bl - Level 2 (“Create a customer business information instance regarding financial data according to the template (includes contract info and SLA violation consequences)”)

[0108] When a customer signs a contract, the business information template from B0 - Level 1 is instantiated and the Customer IDs <CID> for the different source data systems are given values. The identifier of the instantiated scope type is saved as well.

[0109] A simplified example (continued):

• Scope = Service X

• Parameter 1: CID = 4567-3

• Parameter 2: CID = 4567-3

• Parameter 3: CID = 343467

[0110] Bl - Level 3 (“Update customer business information instance with financial data and estimated SLA fulfillment information”)

[0111] When service allocation weight values for a customer needs to be checked, the instantiated version of the business information template, from Bl - Level 2, is used. These values are used by B3 - Level 3, to calculate the service allocation weight values.

[0112] A simplified example (continued):

• Scope = Service X

• Value of Parameter 1 = 5

• Value of Parameter 2 = 4

• Value of Parameter 3 = 100000 [0113] B2 - Level 1

[0114] This component is a toolbox which can be configured according to the needs of the persons with the knowledge of how to utilize the business information in an optimal way, to impact the network optimization according to the best possible financial outcome. By using a calculation model of the service allocation weight, it is possible to use heuristics and/or learn the calculation model based on data with the help of artificial intelligence (Al) or machine learning (ML).

[0115] Scope type:

• Scope type

[0116] Configuration data:

• An importance weight for each parameter

• A value range for the SAW

• A calculation model of the SAW

• An execution pipeline.

[0117] Functions:

• A scaling function for each parameter

• A scaling function for the importance weights

• A model execution function

[0118] A simplified example (continued):

• Scope type = NWS_service

• Value range for service weight = 0 - 10

• Parameter 1

• importance weight = 9

• Scaling function = value * 1 * max(SAW) / max(value range)

• Parameter 2

• importance weight = 6

• Scaling function = value * 1 * max(SAW) / max(value range) Parameter 3

• importance weight = 3

• Scaling function = log(value) * max(SAW) / log(max(value range))

• Important weight scaling function = scaled_IW(p(n)) = IW(p(n)) / sum(IW)

• Parameter 1 scaled IW = 1 / 2

• Parameter 2 scaled IW = 1 / 3

• Parameter 3 scaled IW = 1 / 6

• Calculation model: linear => scaled_PW(p(n)) * scaled_IW(p(n))

• The execution pipeline is illustrated in FIG. 6. The scaling function for each parameter is separately applied to the parameters. In some cases, each of the parameters may have the same scaling function, in other cases (as indicated here), one or more of the parameters may have a different scaling function. This results in a scaled importance weight for each parameter. The scaled importance weight is then aggregated (here passed to a summation function) to produce the service allocation weight. In some embodiments, other methods may be used to aggregate the scaled importance parameters, e.g., a weighted sum, average, minimum, maximum, etc.

• Execution pipeline:

• <Parameter 1 value> * 1 / 2 + <Parameter 2 value> * 1 / 3 + log(<Parameter 3 value>) * 1 / 6

[0119] In the example, “IW” refers to “importance weight,” and “PW” refers to “parameter weight.”

[0120] The above is an example calculation of service allocation weights. The weights can be implemented with different techniques than shown, e.g., a graph-based execution flow, or fuzzy logic, among others.

[0121] B3 - Level 3 (“Calculate service allocation weight rules, based on customer business information”) [0122] This component is using the obtained values from Bl - Level 3, together with the rules defined in B2 - Level 1, to calculate the service allocation weight.

[0123] A simplified example (continued):

• Execution pipeline result: 5 * 1 / 2 + 4 * 1 / 3 + 5 * 1 / 6 = (15 + 8 + 5) / 6 = 28 / 6 = 4 + 2 / 3 -= 4.67

[0124] B4 - Level 3 (“Send requirements to OSS”)

[0125] This component gets its information from B3 - Level 3 and involves translation towards the OSS for weight decoupling. For example, it may send an intent to the OSS, containing the scope, the service allocation weight, and the value range of the service allocation weight (or service prioritization value and corresponding value range). Only sending these parameters decouples the BSS and the OSS in two dimensions. First, the real time evaluation of business-critical aspects can be done in the network. Second, the BSS does not need to have a detailed understanding of how services will be optimized in the network.

[0126] A simplified example (continued):

• Scope = Service X

• Service allocation weight = 4.67

• Value range = 0 - 10

[0127] The weight definition, exemplified in the next section, may be sent to a receiver, like to the OSS (B5 - Level 5) from the BSS. The receiver may then parse and translate the received intent information into intent definitions applicable within the receiver’ s context, meaning domain and area of responsibility.

[0128] Interface between B4 & B5 (the bolded arrow in FIG. 4 from B4 - Level 3 to B5 - Level 5)

[0129] Within level 5, the service priority definition sent from B4 - Level 3 may need transformation into values and intents adapted to the level 5 contexts. For example, the service allocation weight may be translated into a service prioritization value usable by the OSS. [0130] One approach to do this is to extend the current intent standards in TMF, defined in the different IG1253 documents. Using an example from IG1253A p. 44, the currently defined data could be extended like shown below. Three possible options for priority definitions are shown, with extensions marked in bold in the simplified example below:

@ prefix ex: <http ://service-in ventory.operator.com/ServiceXforCompY > ©prefix spd: <http://www.sdo2.Org/TelecomServicePrioDef/V ersion_1.3/> ex : ExamplelntentX YZ a icm: Intent ; icrmhasExpectation ex: Expl -delivery , ex:Exp2_property . spd:default_priority [ spd: type spd: quadratic , spd:penalty_parameter 4.7 ] . spd:penalty_range [ spd:rangeStart 0 ; spd:rangeStop 10 ]

# penalty = 0.47*max(KPI-limit,0)^A2 ex : Exp2_property a icrmPropertyExpectation ; icrmtarget _: service ; icrmparams ex:Par2_latency , ex:Par3_throughput , ex:Par4_availability . ex:Par2_latency a icm:PropertyParam ; met:latency [ icm:atMost "10 ms" ]

# Here, we increase the weight of latency spd: priority [ spd:type spd: quadratic , spd:penalty_parameter 4.7 ] . ex:Par3_throughput a icm:PropertyParam ; met:throughput [ icrmatLeast [ met:value 5 ; met:unit met:unitMBPS ] ] . spd: priority [ spd: type spd dinear , spd:penalty_parameter 1 ] . ex : Par4_availability a icm:PropertyParam ; met: availability [ icrmgreater [ met:value 99.9 ; met:unit met:percentage ] . spd: priority [ spd: type spd: formula , spd:penalty_parameter 1 spd:penalty_parameter25 spd : penalty_formula ' ' $ A *exp(- ($x-$limit) * $B - 1) "

] .

[0131] It is of course possible to adapt this to other types of interfaces, based on other standards than TMF. For example, 3GPP uses a different mechanism in their intent API than TMF, based on UML.

[0132] FIG. 7 is a flowchart illustrating a process 700, according to an embodiment, performed by a business support system (BSS) in a telecommunications network. Process 700 may begin in step s702. [0133] Step s702 comprises calculating a service allocation weight for a service governed by a service level agreement based at least in part on business information related to the service level agreement and a current performance of the service.

[0134] Step s704 comprises translating the service allocation weight to a service prioritization value usable by an operations support system (OSS) coupled to the BSS.

[0135] Step s706 comprises transmitting the service prioritization value towards the OSS.

[0136] In some embodiments, translating the service allocation weight to a service prioritization value comprises using range information for the service allocation weight. In some embodiments, transmitting the service prioritization value towards the OSS comprises transmitting range information for the service prioritization value. In some embodiments, the service allocation weight for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement. In some embodiments, the business information related to the service level agreement includes financial and legal information related to the service level agreement.

[0137] In some embodiments, the method further includes re-calculating the service allocation weight based on a current value of the service calculation weight and updated information regarding performance of the service. In some embodiments, calculating a service allocation weight for a service governed by a service level agreement comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

[0138] FIG. 8 is a flowchart illustrating a process 800, according to an embodiment, performed by an operations support system (OSS) in a telecommunications network. Process 800 may begin in step s802.

[0139] Step 802 comprises receiving from a business support system (BSS) coupled to the OSS a service prioritization value for a service governed by a service level agreement.

[0140] Step 804 comprises detecting a resource shortage in the telecommunications network.

[0141] Step 806 comprises causing resources to be re-allocated based at least in part on the service prioritization value. [0142] In some embodiments, receiving from a business support system (BSS) coupled to the OSS a service prioritization value comprises receiving range information for the service prioritization value. In some embodiments, the service prioritization value for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement. In some embodiments, detecting a resource shortage in the telecommunications network comprises evaluating fulfillment of the service level agreement and additional service level agreements for additional services. In some embodiments, causing resources to be re-allocated comprises minimizing penalties for failing to fulfill service level agreements, wherein at least one of the penalties is adjusted based on the service prioritization value. In some embodiments, at least one of the penalties is further adjusted based on a range associated with the service prioritization value.

[0143] FIG. 9 is a block diagram of apparatus 900 (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. 9, apparatus 900 may comprise: processing circuitry (PC) 902, which may include one or more processors (P) 955 (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 900 may be a distributed computing apparatus); at least one network interface 948 comprising a transmitter (Tx) 945 and a receiver (Rx) 947 for enabling apparatus 900 to transmit data to and receive data from other nodes connected to a network 910 (e.g., an Internet Protocol (IP) network) to which network interface 948 is connected (directly or indirectly) (e.g., network interface 948 may be wirelessly connected to the network 910, in which case network interface 948 is connected to an antenna arrangement); and a storage unit (a.k.a., “data storage system”) 908, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. Interface 960 may connect PC 902 and storage unit 908, interface 962 may connect PC 902 and network interface 948, and interface 964 may connect network interface 948 and network 910. In embodiments where PC 902 includes a programmable processor, a computer program product (CPP) 941 may be provided. CPP 941 includes a computer readable medium (CRM) 942 storing a computer program (CP) 943 comprising computer readable instructions (CRI) 944. CRM 942 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 944 of computer program 943 is configured such that when executed by PC 902, the CRI causes apparatus 900 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus 900 may be configured to perform steps described herein without the need for code. That is, for example, PC 902 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[0144] 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.

[0145] 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: calculating (s702) a service allocation weight for a service governed by a service level agreement based at least in part on business information related to the service level agreement and a current performance of the service; translating (s704) the service allocation weight to a service prioritization value usable by an operations support system, OSS, (132) coupled to the BSS (130); and transmitting (s706) the service prioritization value towards the OSS (132).

2. The method of claim 1, wherein translating the service allocation weight to a service prioritization value comprises using range information for the service allocation weight.

3. The method of any one of claims 1-2, wherein transmitting the service prioritization value towards the OSS comprises transmitting range information for the service prioritization value.

4. The method of any one of claims 1-3, wherein the service allocation weight for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement.

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

6. The method of any one of claims 1-5, further comprising re-calculating the service allocation weight based on a current value of the service calculation weight and updated information regarding performance of the service.

7. The method of any one of claims 1-6, wherein calculating a service allocation weight for a service governed by a service level agreement comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

8. A method performed by an operations support system, OSS, (132) in a telecommunications network, the method comprising: receiving (s802) from a business support system, BSS, (130) coupled to the OSS (132) a service prioritization value for a service governed by a service level agreement; detecting (s804) a resource shortage in the telecommunications network; and causing (s806) resources to be re-allocated based at least in part on the service prioritization value.

9. The method of claim 8, wherein receiving from a business support system, BSS, (130) coupled to the OSS (132) a service prioritization value comprises receiving range information for the service prioritization value.

10. The method of any one of claims 8-9, wherein the service prioritization value for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement.

11. The method of any one of claims 8-10, wherein detecting a resource shortage in the telecommunications network comprises evaluating fulfillment of the service level agreement and additional service level agreements for additional services.

12. The method of any one of claims 8-11, wherein causing resources to be re-allocated comprises minimizing penalties for failing to fulfill service level agreements, wherein at least one of the penalties is adjusted based on the service prioritization value.

13. The method of claim 12, wherein at least one of the penalties is further adjusted based on a range associated with the service prioritization value.

14. A business support system, BSS, (130) comprising: processing circuitry (902); and a memory, the memory containing instructions (944) executable by the processing circuitry (902), whereby when executed the processing circuitry (902) is configured to: calculate a service allocation weight for a service governed by a service level agreement based at least in part on business information related to the service level agreement and a current performance of the service; translate the service allocation weight to a service prioritization value usable by an operations support system, OSS, (132) coupled to the BSS (130); and transmit the service prioritization value towards the OSS (132).

15. The BSS of claim 14, wherein translating the service allocation weight to a service prioritization value comprises using range information for the service allocation weight.

16. The BSS of any one of claims 14-15, wherein transmitting the service prioritization value towards the OSS comprises transmitting range information for the service prioritization value.

17. The BSS of any one of claims 14-16, wherein the service allocation weight for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement.

18. The BSS of any one of claims 14-17, wherein the business information related to the service level agreement includes financial and legal information related to the service level agreement.

19. The BSS of any one of claims 14-18, wherein the processing circuitry is further configured to re-calculate the service allocation weight based on a current value of the service calculation weight and updated information regarding performance of the service.

20. The method of any one of claims 14-19, wherein calculating a service allocation weight for a service governed by a service level agreement comprises using one of linear regression, graph-based execution flow, and fuzzy logic.

21. An operations support system, OSS, (132) comprising: processing circuitry (902); and a memory, the memory containing instructions (944) executable by the processing circuitry (902), whereby when executed the processing circuitry (902) is configured to: receive from a business support system, BSS, (130) coupled to the OSS (132) a service prioritization value for a service governed by a service level agreement; detect a resource shortage in the telecommunications network; and cause resources to be re-allocated based at least in part on the service prioritization value.

22. The OSS of claim 21, wherein receiving from a business support system, BSS, (130) coupled to the OSS (132) a service prioritization value comprises receiving range information for the service prioritization value.

23. The OSS of any one of claims 21-22, wherein the service prioritization value for a service comprises a vector having a plurality of components associated with one or more characteristics of the service level agreement.

24. The OSS of any one of claims 21-23, wherein detecting a resource shortage in the telecommunications network comprises evaluating fulfillment of the service level agreement and additional service level agreements for additional services.

25. The OSS of any one of claims 21-24, wherein causing resources to be re-allocated comprises minimizing penalties for failing to fulfill service level agreements, wherein at least one of the penalties is adjusted based on the service prioritization value.

26. The OSS of claim 25, wherein at least one of the penalties is further adjusted based on a range associated with the service prioritization value.

27. A computer program (943) comprising instructions which when executed by processing circuitry (902) of a node (900), causes the node (900) to perform the method of any one of claims 1-13.

28. A carrier containing the computer program (943) of claim 27, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (942).