WO2024005681A1 - Procédé et système d'optimisation de système à l'aide de facteurs de pondération d'attribution de service - Google Patents

Procédé et système d'optimisation de système à l'aide de facteurs de pondération d'attribution de service Download PDF

Info

Publication number
WO2024005681A1
WO2024005681A1 PCT/SE2022/050665 SE2022050665W WO2024005681A1 WO 2024005681 A1 WO2024005681 A1 WO 2024005681A1 SE 2022050665 W SE2022050665 W SE 2022050665W WO 2024005681 A1 WO2024005681 A1 WO 2024005681A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
oss
bss
prioritization value
level agreement
Prior art date
Application number
PCT/SE2022/050665
Other languages
English (en)
Inventor
Ulf Eriksson
Johan Silvander
Peter ÖHLÉN
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/SE2022/050665 priority Critical patent/WO2024005681A1/fr
Priority to PCT/EP2023/057062 priority patent/WO2024002535A1/fr
Publication of WO2024005681A1 publication Critical patent/WO2024005681A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/0826—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for reduction of network costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5048—Automatic or semi-automatic definitions, e.g. definition templates

Definitions

  • SLAs binding service-level agreements
  • 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.
  • 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/
  • KPIs Key Performance Indicators
  • 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.
  • the penalties of breaking such an SLA might be visible on the bottom line in an annual report.
  • 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.
  • 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.
  • Embodiments herein focus on what happens when there is resource shortage in the network.
  • 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.
  • Customer A has high demanding SLAs but low service allocation weight, while it is the opposite for Customer B.
  • 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).
  • CSP content service provider
  • embodiments can guard the business relationship and make sure the resource optimization is based on this relationship, in real time.
  • 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.
  • breaking an SLA might not render any consequences since the customer might not have fulfilled their obligations of the contract.
  • an initial/actual service allocation weight based on a value range (within the BSS) of a specific service can be calculated.
  • 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.
  • the weight can be used as a scaling factor in the techniques used for resource allocation in the network.
  • 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 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.
  • a method performed by a business support system (BSS) in a telecommunications network 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.
  • OSS operations support system
  • translating the service allocation weight to a service prioritization value comprises using range information for the service allocation weight.
  • transmitting the service prioritization value towards the OSS comprises transmitting range information for the service prioritization value.
  • 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.
  • the business information related to the service level agreement includes financial and legal information related to the service level agreement.
  • 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.
  • 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.
  • a method performed by an operations support system (OSS) in a telecommunications network 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.
  • BSS business support system
  • receiving from a business support system (BSS) coupled to the OSS a service prioritization value comprises receiving range information for the service prioritization value.
  • 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.
  • detecting a resource shortage in the telecommunications network comprises evaluating fulfillment of the service level agreement and additional service level agreements for additional services.
  • 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.
  • a business support system includes processing circuitry; and a memory, the memory containing instructions executable by the processing circuitry.
  • 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.
  • the processing circuitry 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.
  • OSS operations support system
  • an operations support system includes processing circuitry; and a memory, the memory containing instructions executable by the processing circuitry.
  • 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.
  • BSS business support system
  • the processing circuitry When executed the processing circuitry is configured to detect a resource shortage in the telecommunications network.
  • the processing circuitry is configured to cause resources to be re-allocated based at least in part on the service prioritization value.
  • 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.
  • a carrier 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.
  • FIG. 1 illustrates an overview of the BSS 130 and OSS 132 interactions according to an embodiment.
  • FIG. 2 illustrates penalties associated with individual KPIs calculated and added to form a global penalty, according to an embodiment.
  • FIG. 3 illustrates a block diagram of the BSS 130 and OSS 132 interacting in a telecommunications network, according to an embodiment.
  • FIG. 4 illustrates a sequence diagram according to some embodiments.
  • FIGS. 5A and 5B illustrate the BSS and SMO interaction according to an embodiment.
  • FIG. 6 illustrates an execution pipeline according to an embodiment.
  • FIG. 7 illustrates a flowchart according to an embodiment.
  • FIG. 8 illustrates a flowchart according to an embodiment.
  • FIG. 9 is a block diagram of an apparatus according to an embodiment.
  • 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.
  • market perceptions and the like 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 illustrates an overview of the BSS 130 and OSS 132 interactions according to an embodiment.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 The key shown in FIG. 1 indicates which aspects are defined for service, created on the BSS level, or are operator configuration and policy.
  • 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).
  • 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).
  • intents e.g., the expected functionality of the service
  • legal requirements e.g., 112c
  • performance/KPI requirements e.g., 112b
  • financial provisions e.g., 104
  • 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 (
  • 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.
  • 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)
  • cost limits e.g., 112d
  • service priorities e.g., 112e
  • Services assigned to priority in groups e.g., highest, high, medium, low, lowest.
  • 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.
  • FIG. 2 illustrates penalties associated with individual KPIs calculated and added to form a global penalty, according to an embodiment.
  • 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.
  • 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.
  • FIG. 3 illustrates a block diagram of the BSS 130 and OSS 132 interacting in a telecommunications network, according to an embodiment.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Service Allocation Weight Creation (Block 3 (“B3”))
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the intent status reports may also be received by this block 312.
  • FIG. 4 illustrates a sequence diagram according to some embodiments.
  • FIG. 4 The functionality disclosed in FIG. 4 is shown in five layers, labeled as layers 1-5.
  • these layers indicate the time frame of the functionality.
  • 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.
  • 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.
  • a contract template is created which is aimed at a specific business model.
  • a business information template is created to retrieve information regarded as vital to measure financial aspects regarding costumers of a specific type of contracts.
  • 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.
  • a contract is created and signed for a specific customer. This contains, among other things, SLAs and their consequences.
  • 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.
  • the updated information is used together with the rules to calculate service allocation weight values.
  • 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.
  • 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.
  • the network evaluates the information from layer 4 and at 422, optimizes the network based on this information.
  • reports of service performance are sent according to measurement settings and event rules.
  • 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.
  • 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.
  • 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.
  • Layer 1 - B2 (“Create rules for service allocation weight calculation, based on business information template”)
  • the functions used to calculate service allocation weights can be implemented with different techniques, e.g., a graph-based execution flow, or fuzzy logic.
  • Layer 3 - B3 (“Calculate service allocation weights using service allocation weight rules, based on customer business information”)
  • 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.
  • 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.
  • FIGS. 5A and 5B illustrate the BSS and SMO interaction according to an embodiment.
  • 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.
  • SMO Service Management and Orchestration
  • 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.
  • 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
  • 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.
  • 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.
  • the information for each parameter used in the scope may be structured as:
  • Bl - Level 2 (“Create a customer business information instance regarding financial data according to the template (includes contract info and SLA violation consequences)”)
  • Bl - Level 3 (“Update customer business information instance with financial data and estimated SLA fulfillment information”)
  • 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.
  • 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).
  • the execution pipeline is illustrated in FIG. 6.
  • the scaling function for each parameter is separately applied to the parameters.
  • 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.
  • the scaled importance weight is then aggregated (here passed to a summation function) to produce the service allocation weight.
  • other methods may be used to aggregate the scaled importance parameters, e.g., a weighted sum, average, minimum, maximum, etc.
  • IW refers to “importance weight”
  • PW refers to “parameter weight.”
  • 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.
  • 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.
  • 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.
  • the weight definition 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.
  • the service priority definition sent from B4 - Level 3 may need transformation into values and intents adapted to the level 5 contexts.
  • the service allocation weight may be translated into a service prioritization value usable by the OSS.
  • 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:
  • 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.
  • 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.
  • Step s704 comprises translating the service allocation weight to a service prioritization value usable by an operations support system (OSS) coupled to the BSS.
  • OSS operations support system
  • Step s706 comprises transmitting the service prioritization value towards the OSS.
  • translating the service allocation weight to a service prioritization value comprises using range information for the service allocation weight.
  • transmitting the service prioritization value towards the OSS comprises transmitting range information for the service prioritization value.
  • 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.
  • the business information related to the service level agreement includes financial and legal information related to the service level agreement.
  • 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.
  • 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.
  • FIG. 8 is a flowchart illustrating a process 800, according to an embodiment, performed by an operations support system (OSS) in a telecommunications network.
  • OSS operations support system
  • Process 800 may begin in step s802.
  • 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.
  • BSS business support system
  • Step 804 comprises detecting a resource shortage in the telecommunications network.
  • Step 806 comprises causing resources to be re-allocated based at least in part on the service prioritization value.
  • receiving from a business support system (BSS) coupled to the OSS a service prioritization value comprises receiving range information for the service prioritization value.
  • 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.
  • detecting a resource shortage in the telecommunications network comprises evaluating fulfillment of the service level agreement and additional service level agreements for additional services.
  • 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.
  • 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.
  • 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”)
  • 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.
  • PC 902 includes a programmable processor
  • 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.
  • 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).
  • 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.
  • the features of the embodiments described herein may be implemented in hardware and/or software.

Abstract

L'invention concerne un procédé mis en œuvre par un système de support commercial (BSS) dans un réseau de télécommunications. Le procédé comprend le calcul d'une pondération d'attribution de service pour un service régi par un accord de niveau de service sur la base, au moins en partie, d'informations commerciales relatives à l'accord de niveau de service et d'une performance actuelle du service. Le procédé comprend la traduction de la pondération d'attribution de service en une valeur de priorisation de service utilisable par un système de support d'opérations (OSS) couplé au BSS. Le procédé comprend la transmission de la valeur de priorisation de service à l'OSS.
PCT/SE2022/050665 2022-07-01 2022-07-01 Procédé et système d'optimisation de système à l'aide de facteurs de pondération d'attribution de service WO2024005681A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/SE2022/050665 WO2024005681A1 (fr) 2022-07-01 2022-07-01 Procédé et système d'optimisation de système à l'aide de facteurs de pondération d'attribution de service
PCT/EP2023/057062 WO2024002535A1 (fr) 2022-07-01 2023-03-20 Procédé et système pour ajuster une attribution de ressources d'après un risque commercial

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2022/050665 WO2024005681A1 (fr) 2022-07-01 2022-07-01 Procédé et système d'optimisation de système à l'aide de facteurs de pondération d'attribution de service

Publications (1)

Publication Number Publication Date
WO2024005681A1 true WO2024005681A1 (fr) 2024-01-04

Family

ID=85776196

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/SE2022/050665 WO2024005681A1 (fr) 2022-07-01 2022-07-01 Procédé et système d'optimisation de système à l'aide de facteurs de pondération d'attribution de service
PCT/EP2023/057062 WO2024002535A1 (fr) 2022-07-01 2023-03-20 Procédé et système pour ajuster une attribution de ressources d'après un risque commercial

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/057062 WO2024002535A1 (fr) 2022-07-01 2023-03-20 Procédé et système pour ajuster une attribution de ressources d'après un risque commercial

Country Status (1)

Country Link
WO (2) WO2024005681A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045337A1 (fr) * 2004-10-28 2006-05-04 Telecom Italia S.P.A. Procede de gestion de ressources dans une plate-forme de gestion de services et / ou de reseaux de telecommunication, plate-forme correspondante et programme informatique associe
WO2013085437A1 (fr) * 2011-12-05 2013-06-13 Telefonaktiebolaget L M Ericsson (Publ) Procédé et systèmes de planification de ressources sans fil sur un réseau sans fil
US20180316799A1 (en) * 2017-04-27 2018-11-01 At&T Intellectual Property I, L.P. Method and apparatus for managing resources in a software defined network
US20200351718A1 (en) * 2019-05-02 2020-11-05 Verizon Patent And Licensing Inc. Systems and methods for allocating network resources utilizing bearer information
US20210160153A1 (en) * 2019-11-27 2021-05-27 Netsia, Inc. Slice assurance within a mobile network
US20210194771A1 (en) * 2019-12-19 2021-06-24 Sandvine Corporation System and method for intent based network slice assignment

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8041797B2 (en) * 2004-03-31 2011-10-18 International Business Machines Corporation Apparatus and method for allocating resources based on service level agreement predictions and associated costs
CN104079503B (zh) * 2013-03-27 2018-07-20 华为技术有限公司 一种资源分配方法及装置
EP3327990B1 (fr) * 2016-11-28 2019-08-14 Deutsche Telekom AG Réseau de communication radio avec surveillance basée sur seuils multiples pour la gestion de ressources radio

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045337A1 (fr) * 2004-10-28 2006-05-04 Telecom Italia S.P.A. Procede de gestion de ressources dans une plate-forme de gestion de services et / ou de reseaux de telecommunication, plate-forme correspondante et programme informatique associe
WO2013085437A1 (fr) * 2011-12-05 2013-06-13 Telefonaktiebolaget L M Ericsson (Publ) Procédé et systèmes de planification de ressources sans fil sur un réseau sans fil
US20180316799A1 (en) * 2017-04-27 2018-11-01 At&T Intellectual Property I, L.P. Method and apparatus for managing resources in a software defined network
US20200351718A1 (en) * 2019-05-02 2020-11-05 Verizon Patent And Licensing Inc. Systems and methods for allocating network resources utilizing bearer information
US20210160153A1 (en) * 2019-11-27 2021-05-27 Netsia, Inc. Slice assurance within a mobile network
US20210194771A1 (en) * 2019-12-19 2021-06-24 Sandvine Corporation System and method for intent based network slice assignment

Also Published As

Publication number Publication date
WO2024002535A1 (fr) 2024-01-04

Similar Documents

Publication Publication Date Title
US11349726B2 (en) Systems and methods for real-time service assurance
Dan et al. Web service differentiation with service level agreements
US8346591B2 (en) Automating responses by grid providers to bid requests indicating criteria for a grid job
US20170208016A1 (en) Systems, Devices and Methods of Decomposing Service Requests into Domain-Specific Service Requests
Whaiduzzaman et al. A study on strategic provisioning of cloud computing services
Moser et al. Domain-specific service selection for composite services
US20070226116A1 (en) Automated service level management in financial terms
US20200404051A1 (en) Application placing and scaling
US20100131650A1 (en) Methods and Apparatus to Support Network Policy Managers
Erradi et al. WS-Policy based monitoring of composite web services
EP1709537A2 (fr) Procede et appareil de modelisation unifiee de performances avec controle et analyse de systemes complexes
Sciancalepore et al. A future-proof architecture for management and orchestration of multi-domain NextGen networks
Kokash et al. Evaluating quality of web services: A risk-driven approach
Maarouf et al. Practical modeling of the SLA life cycle in cloud computing
Zo et al. Security and performance in service-oriented applications: Trading off competing objectives
WO2024005681A1 (fr) Procédé et système d'optimisation de système à l'aide de facteurs de pondération d'attribution de service
Farha et al. Blueprint for an autonomic service architecture
Kasap et al. Provider selection and task allocation in telecommunications with QoS degradation policy
Nurmela et al. Service level agreement management in federated virtual organizations
Turan et al. Volume discount strategies for the provider selection problem in telecommunications under uncertainty
Hussain et al. Semantic similarity model for risk assessment in forming cloud computing SLAs
Lieto et al. Dynamic Pricing for Tenants in an Automated Slicing Marketplace
Asfoura et al. FERP mall role in FERP Web Services marketing
Khimani et al. SLA-An Asset for Better Cloud Services
Abushaban Assessing and improving SLAs for IT service providers, linking theory with business

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22949589

Country of ref document: EP

Kind code of ref document: A1