WO2008136713A1

WO2008136713A1 - Dynamic sla negotiation

Info

Publication number: WO2008136713A1
Application number: PCT/SE2007/000447
Authority: WO
Inventors: Mona Matti; Tony Larsson; Niklas BJÖRK; Tor Kvernvik; Mattias LIDSTRÖM; Justus Petersson
Original assignee: Telefonaktiebolaget Lm Ericson (Publ)
Priority date: 2007-05-08
Filing date: 2007-05-08
Publication date: 2008-11-13
Also published as: GB0920493D0; GB2462752A

Abstract

A method for managing an automated service level agreement (SLA) negotiation between two providers (400a, 400b) belonging to different network domains, an initiating SLA negotiation manager (401a), a terminating SLA negotiation manager (401b), and a system for managing the negotiation. A negotiation is executed between two request handlers (40a, 402b) of the respective SLA negotiation managers. The request handler of the terminating SLA negotiation handler manages a policy checking procedure by interrogating an associated Policy Decision Point (PDP, 407) associated with the terminating SLA negotiation handler, via a resource handler (406b). A new or updated SLA, resulting from a successful negotiation is stored in an SLA database (SLA DB, 405a, 405,), in the initiating, as well as in the terminating SLA negotiation manager.

Description

DYNAMIC SLA NEGOTIATION

TECHNICAL FIELD

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.

BACKGROUND

With the emergence of 3G mobile telephony, new packet-based communication technologies using IP (Internet protocol) have been developed to support wireless communication of multimedia. For example, communication protocols used by GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) support packet-switched multimedia services, as well as traditional circuit-switched voice calls.

In the future, the telecommunication world will offer the end-users access through many different types of networks .

To provide users with the services they require irrespective of their location, these networks will have to co-operate. In a highly mobile environment, it will also be a requirement for such a network co-operation to be established "on the fly".

One network architecture that has been developed by the 3^rd Generation Partnership Project (3GPP) as a platform for handling multimedia services and sessions in a packet domain, is the IP-based "IP Multimedia Subsystem" (IMS) . 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) has been defined for handling sessions in IMS networks. 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. In the figure, 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. Further, a gateway node (GW) 102, typically a Gateway GPRS Switching Node (GGSN) , is shown in a schematic bearer plane used for data transport. 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. 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. In a first step 1:1 of the illustrated procedure, 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. 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.

In a next step 1:2, GW 102 sends relevant access information to PDP 103, including a subscription identifier and the bearer information established in step 1:1. Thereby, 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. In this stage, 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.

When a user activates a selected application in terminal A in order to access some service, a SIP-based user agent ("SIP UA") in terminal A performs a session negotiation in a following step 1:3. After the session negotiation, as the session parameters have been settled, service information is sent from the application function 101 to PDP 103, in a next step 1:4. Thereby, another state is created in PDP 103 for a "service session", meaning that the received service information for the session of terminal A is retained in PDP 103. Moreover, PDP 103 determines whether the requested session should be allowed or not by applying a suitable policy.

If PDP 103 can allow the requested session according to the applied policy for the given user and service, 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 then 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. Alternatively, the establishment of a bearer may also be initiated by the mobile network.

In a further step 1:8, 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. At this stage, 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.

The above-mentioned basic charging rule and updated charging rule established for terminal A in steps 1:2 and

1:8, respectively, are often referred to as "PCC (Policy and Charging Control) rules", in effect being rules for session admission. In general, 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. Finally, terminal A can start the session involving the communication of data between terminal A and the respective application function 101, as illustrated by a final step 1:9. 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. As mentioned above, 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.

Operators or providers wanting to provide a greater flexibility, an efficient utilisation of its own resources and a broader range of services to their customers preferably co-operate with one or more other provider in the matter of sharing communication resources and/or services in accordance with predetermined agreements. Service Level Agreements (SLAs) 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. As an alternative to SLOs, Classes of Service (CoS) 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. In this context 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. 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. As is illustrated in the figure, any provider of one domain is adapted to perform negotiations with any other provider of any other domain. Today these types of agreements are static and configured manually by each provider covered by the respective agreement. Each provider negotiates with their respective partner (s) included in an SLA, wherein templates are completed by the partner (s) involved in the negotiation upon completion of the negotiation. Each time conditions are changed, amendments in the corresponding SLA (s) may have to be considered, whereby a new SLA has to be drafted. Apart from being inflexible and time consuming these procedures may lead to inefficient utilization of available resources. In order to support a multi-vendor scenario, which can diminish the deficiencies mentioned above, a more flexible mechanism for executing negotiations between the providers of services and resources is required.

SUMMARY

The object of the present invention is to address at least some of the problems outlined above. In particular, it is an object to provide a solution which enables more efficient negotiations of resources between different providers. These objects and others can be achieved primarily by a solution according to the appended independent claims.

According to one aspect, 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. Upon having executed a successful registration phase, 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. During the registration phase, 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.

In one alternative embodiment 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.

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).

During 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.

Also during the realization phase a checking procedure is executed. 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.

Upon having saved the updated or created SLA, an associated Service Level Specification (SLS) is pushed to or requested from an associated PDP. Next relevant policies and control functions of the PDP associated with the terminating SLA negotiation manager are settled or updated on the basis of the SLS.

Upon having confirmed a successful SLA negotiation at the initiating SLA negotiation manager, also the SLA database of this manager is updated. According to another aspect, a system adapted to provide an automated SLA negotiation between providers of different network domains is also provided. The system 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.

According to yet another aspect, 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) .

According to another aspect, 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, is also provided. 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.

Further features and benefits of the present invention will become apparent from the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:

- 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.

DETAILED DESCRIPTION

Briefly described, the present invention introduces a function referred to as a Service Level

Agreement (SLA) negotiation manager, which provides an automated and dynamic mechanism for managing SLA negotiations between different types of providers or operators. The term "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. In a flexible multi-vendor scenario, 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. access to 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. In order to provide and guarantee service delivery from an end-to-end perspective, 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.

When implementing the present invention extensive interfacing may be necessary between different network domains hosting the respective inter-connected providers. In such a scenario, 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.

As will be illustrated in figures 3-5, 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. 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

Agreement (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.

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. Each of the SLA negotiation managers 305b, c of the

CP and AP, respectively, are also connected to a respective Policy Decision Point (PDP) 306a,b, via an introduced B- interface. Also 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). Each of the SLA negotiation managers 305b, c are adapted to provide its corresponding PDP 306a, b with policies associated with an approved negotiation. An approved negotiation will result in an SLA, which is stored by both negotiating SLA negotiation managers for later retrieval. Each SLA will comprise parameters, referred to as Key Performance Indicators (KPIs) . The KPIs are used for specifying an SLO of the respective SLA. The resulting SLO will define the requirements to be achieved with respect to the respective SLA and may be based on e.g. a specified validation time, a providers profile, QoS, bandwidth or cost . In order to prepare for communications between an SLA negotiation manager and the associated PDP, a Service Level Specification (SLS) , including a translated specification of the respective SLO, is derived from the SLA and sent to the PDP.

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. In figure 3, 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 . The 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) . 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. In the access network domain, the PDP 306b is connected to an Access Node (AN) , providing access resources to end-users. In the figure, AN is represented by the generic entity 308.

In order to enable a more thorough understanding of the functionality of the SLA negotiation manager, the operation of the functional blocks of this entity and the associated signalling flow according to one embodiment of the invention will now be described in more detail with reference to figure 4.

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.

It is assumed that each provider has a pre-defined high level agreement, settling different important legal aspects between the two trusted partners/providers. It is also assumed that that the addresses of the respective SLA negotiation managers are known in advance or retrievable through any conventional discovery mechanism. This mechanism is, however, out of scope of this application, and will therefore not be discussed any further in this document. Furthermore, it is to be understood that 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. In this example 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. In a first step 4:1, a negotiation between SP and

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.

To be able to set an agreement for availability of resources and/or services, the initiating party needs to forward certain information in the registration phase. This information may comprise at least some of the following parameters :

• Provider identity, identifying the negotiation initiating provider. • Provider address, i.e. the address of the SP SLA negotiation manager of the negotiation initiating provider.

• Billing information.

• Service type, i.e. category of services. • Expected number of end-users.

• Supported access type(s). • Terminal capabilities.

During the registration phase, 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. Alternatively, 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.

In a next step 4:2, followed by a subsequent step 4:3, 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. As a result of a successful registry procedure, an inter- working connectivity between the two providers is established. Optionally (not shown) , 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. In the realization phase, 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 resource description, describing a requested/offered resource.

• Duration for the availability of a requested resource/service, e.g. the next 24 h, 2 months. • Requested availability of a link, e.g. 95 %, 99,9 %, 99,999 %.

• Requested bandwidth range for each subscriber, e.g. user ID 11 requests for 75-100 Mbits/s.

• 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.

• Breaching constraints.

• Terminal capabilities. • Measurement issues.

• Type(s) of service (s) to be offered.

• Allowed access type(s) for the respective service.

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. For identification purposes, the request handler 402b is also adapted to give each SLA, a unique identity, which may comprise a digital signature. In addition, also 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.

For optimisation purposes 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.

In 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 .

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. Upon receiving such a report, 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. Accordingly, 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. In order to provide those services with adequate quality, 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. To meet the different requirements as they occur, subsequent negotiations may be executed in a dynamic manner.

When a negotiation procedure is triggered, 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. In a next step 5:2, 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. Upon receiving the registration request, 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. In a following step 5:4 and a subsequent step 5:5 an authentication and/or authorization procedure is initiated by CP. Next, 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. The purpose of this check is to determine whether there are any pre-configured restriction policies related to any of the services in question. In a next step 5:7, 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. In resemblance with the registration request, also the registration response comprises configuration data, associated with CP. In another step 5:8, 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, the realization phase, executed by a step 5:9, is where the actual SLA negotiation is established. At this phase the parameters relevant for the negotiation, which were exemplified earlier in this document, are forwarded to CP. In 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. Next an admission control, confirming that the requested resources are available, is executed by the CP SLA negotiation manager 502 in a step 5:11. Following a successful admission control, 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. Alternatively, the SLS may be requested for by the PDP. In 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. A second time SP addresses a similar request or offer to CP the respective SLA may be reused, thereby reducing the signalling between the two SLA negotiation managers. 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¹ identified, a negotiation of a new SLA is initiated and terminated in step 605. The resulting SLA is saved in the SLA database associated with the SLA negotiation manager in step 606, and in step 607 SLS associated with the newly negotiated SLA is pushed to the PDP associated with the terminating SLA negotiation manager, before, the procedure is finally finished in step 608. To sum up, 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. Furthermore, 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. While the invention has been described with reference to specific exemplary embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention, which is defined by the appended claims. The proposed SLA negotiation manager may be assembled with entities integrated as described in the presented embodiments, or with distributed entities. By way of example, 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.

Claims

1. A method of managing an automated Service Level Agreement (SLA) negotiation between a first initiating provider

(400a) of a first network domain and a second terminating provider (400b) of a second network domain, comprising the following steps: -executing a registration phase (step 5:2) between a first initiating SLA negotiation manager (401a) of the first provider and a second terminating SLA negotiation manager (401b) of the second provider, and -executing a realization phase (step 5:9) between both SLA negotiation managers, wherein an executed negotiation results in a new or an updated SLA between the two providers .

2. A method according to claim 1, wherein the SLA negotiation refers to a negotiation of at least one resource or service.

3. A method according to claim 1 or 2, wherein the network domains may host any of a service network, a core network and/or an access network.

4. A method according to any of claims 1-3, wherein the registration phase comprises 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.

5. A method according to any of claims 1-4, wherein during the registration phase, configuration information necessary for interpretation of the information exchanged during the negotiation procedure is mutually exchanged between both SLA negotiation managers.

6. A method according to any of the preceding claims, wherein the registration phase comprises an authentication and/or authorization procedure (step 5:4, step 5:5) .

7. A method according to any of the preceding claims, wherein the registration phase comprises a checking procedure (step 5:3), verifying if any restriction related to the initiating provider is registered with the terminating provider.

8. A method according to any of the preceding claims, wherein the registration phase comprises a policy checking procedure (step 5:6) verifying if any restriction policy related to the negotiated service, service type or resource exists.

9. A method according to claim 8, wherein the policy checking procedure is executed by way of interrogating a Policy Decision Point (PDP, 407), associated with the terminating SLA negotiation manager.

10. A method according to any of the preceding claims, wherein the realization phase comprises the forwarding of at least one of the following parameters from the initiating to the terminating SLA negotiation manager: 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) .

11.A method according to any of the preceding claims, wherein the realization phase comprises the determining of whether an SLA associated with the respective first and second providers already exists.

12.A method according to claim 11, wherein if an SLA associated with the respective first and second providers already exists this SLA is re-negotiated.

13.A method according to any of the preceding claims, wherein the realization phase comprises a checking procedure (step 5:10) wherein it is verified whether any restriction related to the negotiation relevant data forwarded in the realization phase is registered with the terminating provider.

14. A method according to claim 13 wherein the realization phase further comprises an admission control procedure (step 5:11) .

15. A method according to any of claims 11-14 wherein, upon having saved the updated or created SLA, an associated Service Level Specification (SLS) is pushed to or requested from an associated PDP.

16.A method according to claim 15 wherein, relevant policies and control functions of the PDP associated with the terminating SLA negotiation manager are settled or updated on the basis of the SLS.

17. A method according to any of the preceding claims wherein, upon having confirmed a successful SLA negotiation at the terminating SLA negotiation manager, an SLA database (SLA DB, 405b) of this manager is updated.

18.A method according to any of the preceding claims wherein, upon having confirmed a successful SLA negotiation at the initiating SLA negotiation manager, also the SLA DB (405a) of this manager is updated.

19. A system adapted to provide an automated SLA negotiation between providers of different network domains comprising:

-a first initiating SLA negotiation manager (401a) of a first provider (400a) of a first network domain adapted to initiate and execute a negotiation with a second, terminating SLA negotiation manager (401b) of a second provider (400b) of a second network domain, and, -a Policy Decision Point (PDP, 407) associated with the terminating SLA negotiation manager adapted to verify that SLA negotiation conditions agreed upon comply with the associated pre-configured rules and/or policies.

20. A system according to claim 19, wherein the PDP is a Policy and Charging Rules Function (PCRF) .

21. A system according to claim 19 or 20, further comprising a Policy Enforcement Point (PEP, 307) connected to the PDP (306a, 407), wherein the PEP is adapted to enforce policy decisions in response to a request from an end-user wanting to access a service or a resource.

22.A system according to claim 21, wherein the PEP is a Gateway GPRS Switching Node (GGSN) .

23.A system according to claim 19 or 20, further comprising an Access Node (AN, 308) connected to the PDP (306b, 407), wherein the AN is adapted to enforce policy decisions in response to a request from an end-user wanting to gain access to an access resource.

24.An initiating Service Level Agreement (SLA) negotiation manager (401a) of a first provider (400a), operating as the initiating part in a negotiation with a terminating

SLA negotiation manager (401b) of a second provider

(400b) comprising:

-a request handler (402a) adapted to initiate and execute a negotiation with a corresponding request handler (402b) of the terminating SLA negotiation manager, and, to store an SLA resulting from a successful SLA negotiation in an

SLA database (SLA DB, 405a).

25.A terminating Service Level Agreement (SLA) negotiation manager (401b) of a second provider (400b) adapted to operate as the terminating part in a negotiation with an initiating . SLA negotiation manager (401a) of a first provider (400a) comprising:

-a request handler (402b) adapted to handle the negotiation with the corresponding request handler (402a) of the initiating SLA negotiation manager, and to store an SLA resulting from a successful SLA negotiation in an SLA database (SLA DB, 405b),

-a registry controller (403b) adapted to execute a registration procedure associated with the negotiation, and,

-a resource handler (406b) adapted to initiate an interaction with a PDP rule creation procedure of an associated PDP (407) in association with the negotiation.

26.A terminating Service Level Agreement (SLA) negotiation manager according to claim 25, wherein said request handler is adapted to create a new SLA if no SLA associated with the negotiating parties already exists.