WO2008136713A1 - Dynamic sla negotiation - Google Patents
Dynamic sla negotiation Download PDFInfo
- Publication number
- WO2008136713A1 WO2008136713A1 PCT/SE2007/000447 SE2007000447W WO2008136713A1 WO 2008136713 A1 WO2008136713 A1 WO 2008136713A1 SE 2007000447 W SE2007000447 W SE 2007000447W WO 2008136713 A1 WO2008136713 A1 WO 2008136713A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- sla
- negotiation
- manager
- terminating
- provider
- Prior art date
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/5006—Creating or negotiating SLA contracts, guarantees or penalties
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
-
- 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/04—Network management architectures or arrangements
- H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
Definitions
- the present invention relates generally to the field of resource handling between providers, and, more particularly, a more efficient handling of resource negotiations between different providers from a QoS perspective.
- IP Internet protocol
- GPRS General Packet Radio Service
- WCDMA Wideband Code Division Multiple Access
- IMS IP Multimedia Subsystem
- An IMS network can be used to initiate and control multimedia sessions for IP enabled terminals being connected to any type of access networks.
- a signalling protocol denoted “SIP” Session Initiation Protocol, according to the standard IETF RFC 3261
- SIP Session Initiation Protocol, according to the standard IETF RFC 3261
- a "SIP-enabled” terminal can thus use this standard to initiate and terminate multimedia communications by means of its home IMS network.
- Fig. 1 schematically illustrates a conventional process where an end-user having a mobile terminal A may access multimedia services from an IMS-based mobile network 100. It is to be understood that the described signalling procedure is only presented in general terms, without focusing on all necessary signalling steps in detail. Thus, each illustrated step in the figure is implemented as one or more individual messages according to the protocols used.
- a schematic control plane for control signalling over an IMS network comprising conventional IMS nodes accessing one or more application servers, is represented by an application function 101.
- GW gateway node
- GGSN Gateway GPRS Switching Node
- the application function 101 and the GW 102 are both connected to an associated policy unit 103, here denoted Policy Decision Point (PDP), which is responsible for authorising communication sessions to end-users in the associated IMS network.
- PDP Policy Decision Point
- the GW 102 and PDP 103 typically communicate over a Gx interface, while the application function 101 communicates with the PDP 103 over an Rx- interface.
- terminal A obtains an initial connection with the mobile network 100, typically involving the activation of a PDP context and a Radio Access Bearer (RAB) , as established by GW 102.
- RAB Radio Access Bearer
- the established access bearer is primarily used for carrying occasional control messages of minor size such as service requests, allowing for relatively low bandwidth and fairly long delays.
- GW 102 sends relevant access information to PDP 103, including a subscription identifier and the bearer information established in step 1:1.
- a "state" is created in PDP 103 for a "bearer session", meaning that the received access information for terminal A is retained in PDP 103.
- PDP 103 also responds to GW 102 by sending a so-called “basic charging rule” that has been selected or created based on the received access information.
- the basic charging rule includes a charging key, a charging identity and any service data flow filters that should be applied on communicated data according to that rule.
- a SIP-based user agent in terminal A performs a session negotiation in a following step 1:3.
- service information is sent from the application function 101 to PDP 103, in a next step 1:4.
- PDP 103 determines whether the requested session should be allowed or not by applying a suitable policy.
- an OK message is sent to the application function 101 which also sends an OK message to the terminal A, in a step 1:5.
- the application activated in terminal A requests a bearer from a bearer part in terminal A, in a following step 1:6, in order to satisfy QoS requirements for communication according to the application.
- Terminal A then issues a bearer request for service data transport to GW 102 in the mobile network, in a next step 1:7.
- the establishment of a bearer may also be initiated by the mobile network.
- GW 102 now establishes a new bearer for the forthcoming data transport, as required by the service, and sends relevant QoS information on the established service bearer to PDP 103 where the bearer session state is updated accordingly.
- PDP 103 also responds to GW 102 by sending an updated charging rule, based on the received service, and QoS information.
- the updated charging rule includes a service identity, a charging identity and any service data flow filters according to that rule.
- PCC Policy and Charging Control
- a PCC rule is used for detecting packets belonging to a service data flow, identifying the service, and for providing relevant charging parameters and QoS policy control for a data flow.
- a PCC rule may be predefined or created dynamically, and includes basically a rule name, a service identifier, service data flow filters, QoS parameters and charging parameters.
- the new service bearer or RAB established in step 1:8 should be more stable and reliable than the access bearer established for control messages in step 1:2, to provide a "guaranteed" level of QoS according to the service involved as controlled by the updated charging rule.
- different levels of QoS may also be expected depending on the subscription and/or selected level of service.
- the example according to the prior-art described above represents a scenario where one provider owns the resources as well as the services necessary for providing its customers with high-quality services.
- Such an architecture may however raise problems with how to provide an efficient utilisation of resources and services and/or how to enable a provider to be able to provide a range of services that is broad and competitive enough.
- Service Level Agreements are formal contracts negotiated between different providers, comprising general terms and conditions for co-operation between different types of providers.
- An SLA typically includes SLA templates, which are predefined contract templates, SLA parameters defining what can be measured for a particular service, for maintenance purposes, and Service Level Objectives (SLOs), which are particular values, such as e.g. validity periods, or target values of
- SLA parameters given to Quality of Service (QoS) parameters in a given SLA.
- QoS Quality of Service
- Classes of Service may bundle different parameters and associated thresholds to provide a limited number of choices to choose from during a negotiation.
- Fig. 2 illustrates schematically an exemplary overview of a multi-vendor system 200 according to the prior-art, comprising a plurality of providers being connected to each other, enabling co-operation between the providers.
- Each inter-connected provider may have agreements stipulating the terms and conditions for co-operation between the respective providers in an associated SLA.
- providers include one or more service providers (SP) 201, located in a service network domain, one or more core network providers (CP) 203, located in a core network domain, as well as one or more access network providers (AP) 204, located in an access network domain.
- the service network domain also comprises one or more Application Servers (AS) 202, providing services to the service provider (s) of the domain.
- AS Application Servers
- An SP typically provides a variety of services to subscribing end-users, but instead of owning a network infrastructure of its own, the capacity necessary for providing the services to the end-users is provided from one or more other providers.
- a CP typically owns and administrates core network elements, such as e.g. the public switched telephone network (PSTN) and/or mobile switches and routers of a Public Land Mobile Network (PLMN) and offers core network capacity to other oproviders, such as SPs, while an AP provides network access to providers which do not have the facilities necessary for providing network access on their own.
- PSTN public switched telephone network
- PLMN Public Land Mobile Network
- any provider of one domain is adapted to perform negotiations with any other provider of any other domain.
- the object of the present invention is to address at least some of the problems outlined above.
- it is an object to provide a solution which enables more efficient negotiations of resources between different providers.
- a method of managing an automated Service Level Agreement (SLA) negotiation between a first initiating provider of a first network domain and a second terminating provider of a second network domain is provided.
- the network domains may host any of a service network, a core network and/or an access network.
- a negotiation of at least one resource or service is initiated with the execution of a registration phase between a first initiating SLA negotiation manager of a first provider and a second terminating SLA negotiation manager of a second provider.
- the negotiation is continued with the execution of a realization phase between both SLA negotiation managers.
- the realization phase results in the settling of a new or an updated SLA, which is stored in an SLA database (SLA DB) of the initiating SLA negotiation manager and in a corresponding SLA DB of the terminating SLA negotiation manager.
- the registration phase may comprise the forwarding of one or more of the following parameters from the initiating to the terminating SLA negotiation manager: provider identity, provider address, billing information, service type, expected number of end-users, supported access type(s) or terminal capabilities.
- configuration information necessary for interpreting the information exchanged during the negotiation procedure is mutually exchanged between both SLA negotiation managers.
- the registration phase comprises an authentication and/or authorization procedure followed by a checking procedure. During the checking procedure it is verified whether any restriction related to the initiating provider is registered with the terminating provider.
- the registration phase may also comprise a policy checking procedure, verifying if any restriction policy related to the negotiated service, service type or resource exists.
- the policy checking procedure is executed by way of interrogating a Policy Decision Point (PDP) associated with the terminating SLA negotiation manager.
- PDP Policy Decision Point
- the realization phase comprises the forwarding of parameters from the initiating to the terminating SLA negotiation manager, specifying conditions relevant for the negotiation.
- Theses parameters may comprise at least one of the following parameters: An agreement identity, a service description, a resource description, duration for the availability of a requested resource/service, requested availability of a resource, requested bandwidth range for each subscriber, a subscriber validity group, a minimum required QoS profile, breaching constraints, terminal capabilities, measurement issues, type(s) of service (s) or allowed access type(s).
- the realization phase also comprises it is also determined whether an SLA associated with the respective first and second providers already exists. If this is the case this SLA is re-negotiated. If, however, no SLA exist a new SLA is negotiated.
- the intention with this second checking procedure is to verify whether any restriction related to the negotiation relevant data forwarded in the realization phase is registered with the terminating provider.
- the realization phase also comprises an admission control procedure.
- SLS Service Level Specification
- a system adapted to provide an automated SLA negotiation between providers of different network domains comprises a first initiating SLA negotiation manager of a first provider of a first network domain adapted to initiate and execute a negotiation with a second, terminating SLA negotiation manager of a second provider of a second network domain.
- the system also comprises a Policy Decision Point (PDP) , associated with the terminating SLA negotiation manager adapted to verify that SLA negotiation conditions agreed upon comply with all associated pre-configured rules and/or policies.
- PDP Policy Decision Point
- an initiating Service Level Agreement (SLA) negotiation manager of a first provider is provided.
- the initiating SLA negotiation manager is adapted to operate as the initiating part in a negotiation with a terminating SLA negotiation manager of a second provider and comprises a request handler adapted to initiate and execute a negotiation with a corresponding request handler of the terminating SLA negotiation manager.
- the request handler is also adapted to store an SLA resulting from a successful SLA negotiation in an SLA database (SLA DB) .
- a terminating Service Level Agreement (SLA) negotiation manager of a second provider adapted to operate as the terminating part in a negotiation with an initiating SLA negotiation manager of the first provider.
- the terminating SLA negotiation manager comprises a request handler adapted to handle the negotiation with the corresponding request handler of the initiating SLA negotiation manager.
- the terminating manager is also adapted to store an SLA resulting from a successful SLA negotiation in an SLA DB.
- the terminating SLA negotiation manager also comprises a registry controller adapted to execute a registration procedure associated with the negotiation, and a resource handler adapted to handle an interaction with a PDP rule creation procedure in association with the negotiation.
- the request handler is adapted to create a new SLA if no SLA associated with the negotiating parties already exists. If, however, an SLA already exist, the request handler is adapted to modify this SLA.
- - Fig. 1 illustrates a conventional signalling flow during the establishment of a session between a terminal A , and an application function using a Policy Decision Function (PDP), according to the prior art.
- Fig. 2 illustrates schematically an overview of an exemplary multi-vendor system according to the prior-art.
- Fig. 3 illustrates schematically an overview of an exemplary generic architecture of a multi-vendor system according to one embodiment of the invention.
- Fig. 4 illustrates a signalling flow between functional blocks of an SLA negotiation manager and a PDP according to another embodiment.
- Fig. 5 is a signalling diagram, illustrating an exemplified negotiation scenario between providers or operators of a service network domain and a core network domain in accordance with yet another embodiment.
- - Fig. 6 is a block diagram, illustrating a negotiation procedure according to one embodiment.
- the present invention introduces a function referred to as a Service Level
- SLA negotiation manager which provides an automated and dynamic mechanism for managing SLA negotiations between different types of providers or operators.
- SLA negotiation manager is used in this application to generally indicate its main function, although other similar terms could also be used, such as "SLA negotiation function” or "SLA negotiation unit”. More specifically, the SLA negotiation manager is adapted to secure the QoS of aggregated requested resources between providers.
- the SLA negotiation manager is, thus, equipped with means for improving the interaction between different service, resource and access providers by way of providing a mechanism for executing semi-static negotiations between the respective providers.
- end-users should be able to select different providers for different occasions and services. Such a selection may depend on what different interconnected providers can offer in aspects of e.g.
- bandwidth or different pre-packaged services such as messaging, telephony, news, sport events, weather reports, music, games etc.
- Another major aspect to take into consideration during the provider selection is the overall network performance.
- scarce network resources need to be managed in a way enabling better utilization and optimization of available services and resources.
- Appropriate mechanisms allowing negotiations between providers in different network domains to be executed automatically and dynamically are therefore provided according to the claimed invention.
- the introduced SLA negotiation manager When implementing the present invention extensive interfacing may be necessary between different network domains hosting the respective inter-connected providers.
- the introduced SLA negotiation manager preferably provides a first single point to facilitate inter-working between the respective service-, resource- and/or access provider.
- Each SLA negotiation manager support an automatic negotiation process, which will reduce the time required for SLA negotiations between two entities.
- the introduction of the SLA negotiation manager will also allow providers in different domains to quickly adapt to changes associated with negotiable resources, without having to involve any human interaction.
- a provider of one network domain may negotiate with another provider of another network domain, using a mechanism which offers co- operation through automated Service Level Agreement (SLA) negotiations between the respective providers.
- SLA Service Level Agreement
- Such a mechanism is realised by way of introducing the new function, referred to as an SLA negotiation manager.
- FIG. 3 illustrates schematically an overview of an exemplary generic architecture 300 according to one embodiment of the invention, comprising a plurality of inter-connected operators/providers adapted to share available resources and/or services according to one embodiment.
- a service network domain comprises an SP 301, providing different types of services to end-users, by way of interacting with one or more ASs 302.
- a core network domain comprises a CP 303, and an access network domain comprises an AP 304. It is to be understood that each domain could comprise more inter-connected providers and that also SP could be inter-connected with AP in an alternative embodiment .
- Each provider comprise a dedicated Service Level
- SLA negotiation manager 305a,b,c each of which is adapted to administrate negotiation management between two negotiating providers, inter-connected via an introduced A-interface.
- the A-interface may be any of, typically, SOAP, XML or DIAMETER, which are all well known in this technical field.
- the proposed SLA negotiation manager is adapted to support different access technologies, including wireless networks, such as e.g. GPRS or WCDMA, as well as fixed ones, including packet-based networks such as e.g. the Internet.
- wireless networks such as e.g. GPRS or WCDMA
- fixed ones including packet-based networks such as e.g. the Internet.
- SLA negotiations to be managed by the SLA negotiation manager may comprise e.g. bandwidth reservations, access types to be used for a specific service vs. available QoS models or other QoS related aspects.
- SLA negotiation managers 305b, c of the SLA negotiation manager may comprise e.g. bandwidth reservations, access types to be used for a specific service vs. available QoS models or other QoS related aspects.
- CP and AP are also connected to a respective Policy Decision Point (PDP) 306a,b, via an introduced B- interface.
- the B-interface may be any of, typically, SOAP, XML or DIAMETER.
- the PDP is a generic entity capable of making policy decisions based on a set of policies defined and stored in a database, referred to as a Service Profile Repository (SPR) (not shown) of the respective PDP 306a, b and may be e.g. a Policy and Charging Rules Function (PCRF).
- SPR Service Profile Repository
- PCRF Policy and Charging Rules Function
- Each of the SLA negotiation managers 305b, c are adapted to provide its corresponding PDP 306a, b with policies associated with an approved negotiation.
- SLA Service Level Specification
- SLS Service Level Specification
- Each PDP 306a, b may also provide its associated SLA negotiation manager 305b, c with network usage reports upon request. The reception of such a usage report at an SLA negotiation manager may result in the triggering of adaptations or corrections of relevant policies in order to adapt to a current situation where e.g. breaching of an SLA may be about to occur.
- the PDP 306a located in the core network domain is also connected to a Policy Enforcement Point (PEP) 307, typically via a conventional Gx-interface .
- PEP 307 is the logical entity that enforces policy decisions in response to a request from an end-user wanting to access a resource from a network server, and may be e.g. a Gateway GPRS Support Node (GGSN) .
- GGSN Gateway GPRS Support Node
- the PEP Upon receiving a request from an end-user, the PEP will instruct the PDP 306a to decide whether a pre-configured policy is conformed to before approving the request.
- the PDP 306b In the access network domain, the PDP 306b is connected to an Access Node (AN) , providing access resources to end-users.
- AN Access Node
- AN is represented by the generic entity 308.
- the figure illustrates an exemplary negotiation between a Service Provider (SP) 400a and a Core Provider (CP) 400b, each comprising SLA negotiation manager, 401a and 401b, respectively.
- SP Service Provider
- CP Core Provider
- both SLA negotiation managers each being associated with a different provider, preferably have an identical architecture and functionality, enabling both entities to initiate a negotiation, and to participate in a negotiation as the terminating part.
- the SP SLA negotiation manager 401a is the initiating part, initiating a negotiation with CP SLA negotiation manager 401b, which is the terminating part.
- Functional blocks of the SP SLA negotiation manager 401a not participating in the described negotiating procedure when representing the initiating part are illustrated with dotted lines and will not be involved in the process discussed in this example.
- CP is initiated with a registration phase, wherein a request handler 402a of SP SLA negotiation manager 401a is adapted to initiate a communication with a request handler 402b of CP SLA negotiation manager 401b.
- a negotiation between the two SLA negotiation managers may be triggered by e.g. an active announcement indicating that a provider has resources and/or services to offer to other providers, an active discovery of a neighbouring provider, an initial connection of a new access point to a provider, an initial connection of different networks managed by different providers or the discovery of a link to a network of a provider in a registry database or a portal.
- This information may comprise at least some of the following parameters :
- Service type i.e. category of services. • Expected number of end-users.
- the two negotiating parties establish basic security and inter-working connectivity by authentication and/or authorization in order to establish a trusted relationship.
- the authentication and/or authorization may be executed using a trusted third party.
- the required trusted relationship may be based on a pre-established shared secret, or may even be opportunistic, such that each provider simply makes sure that it always communicates with the same provider.
- a registry control entity 403b connected to a registry database (Registry DB) 404b is adapted to execute a registration checking and authorization of required resources, by involving identities of the neighbouring, and potential negotiating providers.
- the Registry DB may be integrated with the SLA negotiation manager, as illustrated in the figure, or distributed as a stand-alone database.
- the request handler 402b of CP SLA negotiation manager 401b is adapted to check with the associated PDP 407, for any pre-configured rules and/or policies, such as e.g. a restriction for a requested service type.
- Successful steps 4:2 and 4:3 provide for an SLA negotiation, which may be executed in a subsequent realization phase, illustrated by a next step 4:4.
- the request handler 402a of the initiating party is adapted to forward information relevant for the negotiation to the terminating party.
- the information sent in the realization phase will comprise information needed for the settling of rules and/or policies, specifying the conditions for the negotiation.
- Such information may e.g. comprise at least some of the following parameters: • Agreement identity, which uniquely identifies an agreement, using a unique notation, such as e.g. a combination of numbers and letters, including the identity of both providers, as well as the identity of an offered service. • A service description, describing an offered service.
- a subscriber validity group e.g. a negotiation is valid for all users or gold users only.
- the minimum required QoS profile i.e. a number of QoS parameters associated with a session.
- the request handler 402b is adapted to store a settled SLA agreement in an SLA database (SLA DB) 405b of CP SLA negotiation manager 401b, wherein each SLA will comprise several KPIs, each of which is derived from the information forwarded from the initiating request handler 402a of SLA negotiation manager 401b.
- the KPIs indicates different aspects of the current network performance and may be given different priorities.
- the request handler 402b is also adapted to give each SLA, a unique identity, which may comprise a digital signature.
- the SLAs may be given different priorities.
- the storing procedure which is illustrated by a step 4:5b, also triggers the request handler 402a of SP SLA negotiation manager 401a to initiate a storing procedure, wherein request handler 402a is adapted to store a corresponding SLA in SLA DB 405a, as illustrated by a step 4:5a. It is to be understood that the storing of the SLA in SP involves additional signalling (not shown) between the request handlers of both SLA negotiation managers.
- all SLAs associated with a specific provider may be, e.g., cashed in a specified database or linked to from the respective registry DB for later usage.
- the request handler of an SLA negotiation manager may, thus, be adapted to recognise a re-negotiation scenario which may occur a second time a provider wants to initiate negotiations of similar resources from a provider. In such a situation the request handler is adapted to retrieve an existing SLA from the associated SLA DB. Thereby the signalling necessary between the two SLA negotiation managers is reduced and a faster processing can be achieved.
- a next step 4:6 information associated with the SLA, including translated SLOs, may be either pushed to or requested for by the SLA rule engine 408 of PDP 407.
- the SLOs which are stored in the database (DP) 409 of PDP 407, may be used later on during a policy creating procedure associated with a subscribers request for a service provided by the respective provider.
- An SLO may also be used when checking for SLA fulfilment for each upcoming service session request initiated from the rule engine 410.
- the SLA rule engine 408 of PDP 407 is adapted to operate in parallel with the rule engine 410, where the rule engine 410 set up session admission rules (PCC rules), focusing on conditions associated with single users, while the SLA rule engine set up network performance rules (SLA rules) , which are focused on how a service performs or how a resource is used in a network. In other words, the SLA rules are focused on how well a service performance or resource utilisation match an SLA between two providers .
- PCC rules session admission rules
- SLA rules network performance rules
- the SLA Rule engine 408 is adapted to detect any SLA breaching which may occur. Upon detecting an SLA breaching, the SLA rule engine 408 is adapted to forward reports to the request handler 402b.
- the resource handler 406b is adapted to participate in this procedure by forwarding the report as illustrated by a step 4:7, followed by another step 4:8.
- request handler 402b is adapted to change or modify the respective existing SLA established between SP and CP in real time in order to fulfil the requirements agreed upon between both parties. This procedure, indicated by a step 4:9b, will result in the updating of the respective SLA stored in CP.
- SLA DB 405a of SP SLA negotiation manager 401a will be updated via request handler 402a, which is adapted to initiate a corresponding procedure, which is illustrated by a step 4:9a. Also this step comprises additional signalling (not shown) between the request handlers 402a, b of both SLA negotiation managers 401a, b.
- An exemplified scenario also including a negotiation of available resources between an SP and a CP more clearly explaining the associated signalling according to one alternative embodiment, will now be described with reference to the signalling diagram of figure 5.
- SP may be an provider offering e.g. a variety of streaming services to its subscribing end-users.
- SP may set up certain requirements, such as e.g. an expected requirement for 100 Mbits/s 24 h/day for the next six months.
- certain requirements such as e.g. an expected requirement for 100 Mbits/s 24 h/day for the next six months.
- subsequent negotiations may be executed in a dynamic manner.
- a registration phase is initiated by a first step 5:1, where information, registering the SP as the initiating party- participating in a negotiation, is provided to a SP SLA negotiation manager 500 dedicated to SP.
- the information necessary for the registration may comprise one or more parameters, as described earlier in this document. This information may be provided by a conventional traffic dimensioning tool (not shown) , adapted to estimate the aggregated resources necessary for running the available services for all expected end-users in a conventional way.
- a registration request comprising the registration information is sent to a terminating CP SLA negotiation manager 502 dedicated to CP.
- the initial registration request also comprises an overall description of the interaction between the SLA negotiation managers 500,502, represented by configuration data.
- the configuration data allows CP SLA negotiation manager 502 to correctly interpret the information forwarded during the negotiation procedure.
- the CN SLA negotiation manager 502 parses the received information, by checking in a registry database 503 if there are any restrictions related to the SP stored. This process is expressed by a step 5:3.
- a registry database 503 if there are any restrictions related to the SP stored. This process is expressed by a step 5:3.
- an authentication and/or authorization procedure is initiated by CP.
- the policy repository in the PDP 504 may be checked for other restrictions, like for example the services to be run. This may be done in an optional step 5:6.
- CP returns a registration response to SP.
- the registration response may comprise the address of the PDP associated with CP SLA negotiation manager and any information retrieved from the previous checking procedure (s) , such as e.g. a negative response, indicating that none of the indicated services can be delivered from SP at present due to capacity reasons.
- the registration response comprises configuration data, associated with CP.
- the respective AS 501 adapted to provide one or more services involved in a negotiation may be informed of the relevant PDP address.
- the next phase of the negotiation procedure is where the actual SLA negotiation is established.
- the parameters relevant for the negotiation which were exemplified earlier in this document, are forwarded to CP.
- a step 5:10 another check against the registry database associated with CP is executed. This time, however, the checking is done against the parameters relevant for the negotiation, initiated with step 5:9.
- an admission control confirming that the requested resources are available, is executed by the CP SLA negotiation manager 502 in a step 5:11.
- CP SLA negotiation manager stores an approved SLA in the SLA database (SLA DB) . This procedure is illustrated by a step 5:12.
- An approved negotiation then results in the pushing of an associated SLS from CP SLA negotiation manager to the PDP 504 in a step 5:13.
- the SLS may be requested for by the PDP.
- the SLS is used for updating or settling rules and/or policies in accordance with the negotiated SLA.
- An approved negotiation results in an SLA confirmation being forwarded to SP in a step 5:14, and in the saving of the resulting SLA also in the SLA database of the SP SLA negotiation manager 500 in a final step 5:15. All final SLA' s are stored in the respective SLA DBs of both providers involved in the negotiation.
- the signalling associated with the registration phase, i.e. steps 5:1-5:8 will, however, be needed in all cases.
- the negotiation procedure previously described with reference to figures 4 and 5 will now be described as a block diagram seen from a terminating SLA negotiation managers perspective.
- the negotiation procedure starts with step 600. After registration, executed in step 601, authentication and authorization of the terminating SLA negotiation manager is done in step 602. By identifying the respective providers involved in the negotiation procedure in step 603, it is determined whether there already exists any SLA associated with the respective providers, addressing the same resources and/or services. If such an SLA exists, a re-negotiation of this SLA is executed in step 604. If, however, no earlier SLA can be 1 identified, a negotiation of a new SLA is initiated and terminated in step 605.
- a general purpose with the proposed SLA negotiation manager is to enable end-users with better possibilities to dynamically choose services and/or resources which are offered or requested by a provider.
- Negotiations are handled automatically between any neighbouring core providers, access providers and/or service providers, adapted to operate in association with a fixed, or a mobile network, each being provided with interfaced SLA negotiation managers.
- a successful negotiation, resulting in a new or an updated SLA imply that one provider permits another provider to use resources or services up to the level agreed upon in the respective SLA agreement.
- the fulfilment of this agreement may be accomplished by way of the triggering of an interaction between the terminating SLA negotiation manager and its associated PDP.
- the SLA negotiation manager allows the involved parties to dynamically establish SLA agreements that are legally binding in the same manner as the earlier static agreements. Re-use of already established SLA agreements are supported and providers may establish SLA agreements with a plurality of different other providers enabling simultaneous two-way traffic between the involved parties.
- the proposed SLA negotiation manager may be assembled with entities integrated as described in the presented embodiments, or with distributed entities.
- the information handled by the proposed request handler may also comprise various alternative data associated with certain services and/or resources and/or data associated with the initiating party.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/SE2007/000447 WO2008136713A1 (en) | 2007-05-08 | 2007-05-08 | Dynamic sla negotiation |
GB0920493A GB2462752A (en) | 2007-05-08 | 2009-11-24 | Dynamic SLA Negotiation |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/SE2007/000447 WO2008136713A1 (en) | 2007-05-08 | 2007-05-08 | Dynamic sla negotiation |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2008136713A1 true WO2008136713A1 (en) | 2008-11-13 |
Family
ID=39943726
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/SE2007/000447 WO2008136713A1 (en) | 2007-05-08 | 2007-05-08 | Dynamic sla negotiation |
Country Status (2)
Country | Link |
---|---|
GB (1) | GB2462752A (en) |
WO (1) | WO2008136713A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012173528A1 (en) * | 2011-06-15 | 2012-12-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Handling of operator connection offers in a communication network |
EP2660766A1 (en) * | 2012-05-02 | 2013-11-06 | ST-Ericsson SA | A service provider node, a method therein, and a computer program product |
WO2015199592A1 (en) * | 2014-06-26 | 2015-12-30 | Telefonaktiebolaget L M Ericsson (Publ) | Handling of service level agreement |
WO2020049212A1 (en) | 2018-09-06 | 2020-03-12 | Nokia Technologies Oy | Automated roaming service level agreements between network operators via security edge protection proxies in a communication system environment |
US10755220B2 (en) | 2014-03-17 | 2020-08-25 | International Business Machines Corporation | Service level agreement impact modeling for service engagement |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5893905A (en) * | 1996-12-24 | 1999-04-13 | Mci Communications Corporation | Automated SLA performance analysis monitor with impact alerts on downstream jobs |
WO2002044832A2 (en) * | 2000-11-17 | 2002-06-06 | Oblicore Ltd. | A system and method for analyzing and coordinating service-level-agreements (sla) for application-service-providers (asp) |
EP1250021A1 (en) * | 2001-04-09 | 2002-10-16 | Lucent Technologies Inc. | Providing quality of service in telecommunications systems such as UMTS or other third generation systems |
US20030117954A1 (en) * | 2001-12-20 | 2003-06-26 | Alcatel | Telecommunications system employing virtual service network architecture |
US20040064557A1 (en) * | 2002-09-30 | 2004-04-01 | Karnik Neeran M. | Automatic enforcement of service-level agreements for providing services over a network |
-
2007
- 2007-05-08 WO PCT/SE2007/000447 patent/WO2008136713A1/en active Application Filing
-
2009
- 2009-11-24 GB GB0920493A patent/GB2462752A/en not_active Withdrawn
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5893905A (en) * | 1996-12-24 | 1999-04-13 | Mci Communications Corporation | Automated SLA performance analysis monitor with impact alerts on downstream jobs |
WO2002044832A2 (en) * | 2000-11-17 | 2002-06-06 | Oblicore Ltd. | A system and method for analyzing and coordinating service-level-agreements (sla) for application-service-providers (asp) |
EP1250021A1 (en) * | 2001-04-09 | 2002-10-16 | Lucent Technologies Inc. | Providing quality of service in telecommunications systems such as UMTS or other third generation systems |
US20030117954A1 (en) * | 2001-12-20 | 2003-06-26 | Alcatel | Telecommunications system employing virtual service network architecture |
US20040064557A1 (en) * | 2002-09-30 | 2004-04-01 | Karnik Neeran M. | Automatic enforcement of service-level agreements for providing services over a network |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012173528A1 (en) * | 2011-06-15 | 2012-12-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Handling of operator connection offers in a communication network |
EP2660766A1 (en) * | 2012-05-02 | 2013-11-06 | ST-Ericsson SA | A service provider node, a method therein, and a computer program product |
WO2013164215A1 (en) * | 2012-05-02 | 2013-11-07 | St-Ericsson Sa | A service provider node, a method therein, and a computer program product |
US10755220B2 (en) | 2014-03-17 | 2020-08-25 | International Business Machines Corporation | Service level agreement impact modeling for service engagement |
WO2015199592A1 (en) * | 2014-06-26 | 2015-12-30 | Telefonaktiebolaget L M Ericsson (Publ) | Handling of service level agreement |
WO2020049212A1 (en) | 2018-09-06 | 2020-03-12 | Nokia Technologies Oy | Automated roaming service level agreements between network operators via security edge protection proxies in a communication system environment |
EP3847782A4 (en) * | 2018-09-06 | 2022-05-04 | Nokia Technologies Oy | Automated roaming service level agreements between network operators via security edge protection proxies in a communication system environment |
US11483741B2 (en) | 2018-09-06 | 2022-10-25 | Nokia Technologies Oy | Automated roaming service level agreements between network operators via security edge protection proxies in a communication system environment |
Also Published As
Publication number | Publication date |
---|---|
GB0920493D0 (en) | 2010-01-06 |
GB2462752A (en) | 2010-02-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9450887B2 (en) | Methods and apparatuses for notifying an application function of resource restrictions relating to a communication session | |
US7483989B2 (en) | Method and apparatus for establishing a protocol proxy for a mobile host terminal in a multimedia session | |
CA2572281C (en) | Binding mechanism for quality of service management in a communication network | |
EP1992156B1 (en) | System and method for generating a unified accounting record for a communication session | |
JP6108625B2 (en) | Carrier grade peer-to-peer (P2P) network system and method | |
US7546376B2 (en) | Media binding to coordinate quality of service requirements for media flows in a multimedia session with IP bearer resources | |
US20070118881A1 (en) | Application control at a policy server | |
JP5054699B2 (en) | Policy enforcement point interface system and method | |
US20070226775A1 (en) | System and Method for Enforcing Policy in a Communication Network | |
Zhuang et al. | Policy-based QoS architecture in the IP multimedia subsystem of UMTS | |
TW201114226A (en) | Control of session parameter negotiation for communication connection | |
WO2008136713A1 (en) | Dynamic sla negotiation | |
US8554931B1 (en) | Method and system for coordinating network resources for blended services | |
EP1332631A2 (en) | Media binding to coordinate quality of service requirements for media flows in a multimedia session with ip bearer resources | |
WO2007045137A1 (en) | A method of qos authorization | |
de Gouveia et al. | A framework to improve QoS and mobility management for multimedia applications in the IMS | |
Bohm et al. | Policy based architecture for the UMTS multimedia domain | |
JP2011142385A (en) | Charging method and qos network system between network domains | |
KR100879164B1 (en) | Binding mechanism for quality of service management in a communication network | |
Hwang et al. | A framework for IMS interworking networks with quality of service guarantee | |
Alfano et al. | IMS service‐based bearer control | |
Gouveia et al. | Understanding the Issues of Providing IMS Capabilities on Different Access Networks–The Use of Policies for QoS Provision | |
Vallejo et al. | Optimizing the usage of COPS protocol in ITU-T NGN architecture | |
Mahmood et al. | A distributed policy approach in support of multimedia session establishment | |
Pencheva et al. | Cross layer design of Application-level Resource Management interfaces |
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: 07748111 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 7564/DELNP/2009 Country of ref document: IN |
|
ENP | Entry into the national phase |
Ref document number: 0920493 Country of ref document: GB Kind code of ref document: A Free format text: PCT FILING DATE = 20070508 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 0920493.4 Country of ref document: GB |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 07748111 Country of ref document: EP Kind code of ref document: A1 |