The present invention generally relates to the inter-working and compatibility between services offered by a core network and applications residing at a service network. In particular, the invention relates to the development of an open standard interface between a core network and a service network, as well as between a number of core networks.
Today, big players in the telecommunication market have several types of access and core networks technologies distributed along the countries were they operate for providing the users with access to telecom networks and to Internet. Exemplary technologies of the types commented above, such as GPRS, EDGE, CDMA, TDMA, D-AMPS, PDC, CDMA-2000, WCDMA, etc., as well as combinations thereof derive in different scenarios where different heterogeneous environments turn up. Thus, apart from the complexity introduced by such heterogeneous environments, the administrative divisions among these networks into several local companies adds even more heterogeneity to the environment and makes the provisioning of unified services and service application accesses to users roaming through different core networks or different network domains more complex.
New competitors are emerging now to operate networks out of the traditional telecom premises. These new competitors nowadays are a part of the telecommunications market, especially in all issues related to data transmission, while allowing roaming, wider broadband access than conventional PLMN networks, and adding other value added services to users. These companies may operate several types of networks as well, such as small WLAN local operators, Satellite operators, cable operators, etc.
In such a market scenario for telecommunication network, old and new network operators have their own customer base, and therefore the efforts to develop applications and services are more complex than before due to the great diversity of technology and administrative environments. In facing this complexity, telecommunication networks are currently perceived as comprising a service layer, a control layer, and a connectivity layer. The service layer is generally understood as a network environment intended for the development and operation of high level application and, more particularly, end-users service applications. The connectivity layer provides the necessary infrastructure, or network resources, required for establishing an end-to-end connection. The control layer provides the required infrastructure, network control entities, for controlling those network resources in the connectivity layer while providing the service layer with the necessary network support for running end-users service applications. A next step has been introduced in order to develop personalized service quickly and easily by suggesting a network architecture such that the service application layer is realized as a separate network, the Service Network, whereas the control and connectivity layer remain in a Core Network inter-working with an Access Network.
The interaction and compatibility among service layers and control layers in heterogeneous environments have to be solved in order to provide a user with a true Virtual Home Environment (VHE) for allowing a personalized service portability across network boundaries and between terminals. The concept of VHE is such that users are consistently presented with the same personalized features, user interface customization and services in whatever network and whatever terminal, wherever the user may be located, that is, independently of the access and core networks where such users currently hold a subscription and where they are presently roaming. In this respect, remote service invocation and service network roaming appear as key factors for allowing the users to have a true Virtual Home Environment.
One exemplary instance of the efforts made nowadays to standardize an Open Service Access (OSA) interface between the service network layer and the core network layer are the Parlay/OSA specifications, which are based on a number of Application Programming Interfaces (APIs). These APIs allow developers to access the services offered by the core network in an easy way.
A set of initial Application Programming Interfaces (APIs) were defined within the so-called Parlay group, and their standardization goes on under the 3rd Generation Partnership Project (3GPP) and European Telecommunication Standard Institute (ETSI) standardization bodies. In this context, the service network concept along with the above APIs are traditionally referred to as “Parlay” within the Parlay group whereas 3GPP and ETSI usually refer them as “Open Service Access” (OSA). For the sake of clarity, the term OSA/PARLAY is currently used throughout this instant specification for referring the interface layer between the core and the service networks shown in
Thus, OSA/PARLAY allows users and developers to access and to offer applications using services offered by the operator's core home network. The aim is that the above APIs are network independent, thus enabling the evolution of core networks technologies without impacts on the applications, as well as allowing applications to work with different types of core networks.
Therefore and shown in
Client Applications access OSA/PARLAY functions in terms of service capability features via a standardized application interface. This means that service capability features are accessible and visible to client applications via invocation of operations in the OSA/PARLAY API interface.
The above OSA/PARLAY functions have been generally grouped on three different types to distinguish:
In particular, the Framework provides the essential capabilities that allow OSA/PARLAY applications to make use of the service capabilities in the Home network, and more specifically Security Management including Authentication and Authorization, Service Registration and Discovery functions, and Integrity Management.
Regarding the operations in the OSA/PARLAY API interface commented above, three types of interface classes have been distinguished:
interface classes (S-30) between the Framework and the Service Capability Features that provide mechanisms for supporting multi-vendor environment.
Nevertheless, and as
The OSA/PARLAY model commented above can be variably distributed among different players in such manners that different administrative and business domains turn up. Some exemplary models are presented in
Certain operators are organized in such a way that there is an organization responsible for the core network as well as for in-house developed end-user services and applications, whereas another separate organization is responsible for providing end-user services through partners as well as for offering service capabilities to said partners as
Nevertheless, there are no means nowadays for a Network Domain Operator to offer Service Enablers of another domain to those application providers with which said network domain operator has a service agreement. As shown in
In this respect, an object of the present invention is to provide means and methods for enabling the execution of an application in a user's home network that makes use of network services from a network in another domain, such as a visited network, through the OSA/PARLAY interface, wherein said user's home network and said visited network belong to different domain operators, and said network services are not registered in the user's home network.
Another object of the present invention is to enable a domain offering service capabilities from another domain in addition to those offered by each domain itself.
The above objects, among others, are accomplished in accordance with the invention by the provision of a telecommunication system and a method for providing client service applications with access to service capability features via a standardized interface. In particular, the telecommunication system and the method are applicable in scenarios where a standardized interface, like the one provided by OSA/PARLAY API, exists between a service network and a core network under a number of different network domains.
The telecommunication system thus comprises a number of application servers where client service applications run, a number of first service enablers, namely first service capability servers where first service capability features are specified in a first (receiver) network domain, a first Framework for providing a controlled access to said first service capability features, and a number of core network elements inter-working with entities of the service network.
Generally speaking, a framework may be regarded as a functional Framework entity intended for carrying out the Framework functions described above in respect of the OSA/PARLAY standards, as well as new framework functions provided in accordance with the present invention and further described. On the other hand, for the purpose of the present invention a service enabler can be regarded as a service capability server (SCS) where service capability features (SCF) are specified in a certain network domain. For the sake of simplicity, references are made throughout this document to service capability features, or to service enablers or to service capability servers depending on the particular context without always relating to each other.
Thus, in accordance with the present invention, said first Framework in this telecommunications system is arranged for communicating with at least one second Framework, the latter intended for accessing second service capability features specified in a number of second service enablers of a second (donor) network domain.
For the sake of clarity, the invention often refers to a Donor domain as the network domain that offers its service enablers to another domain, or rather those service capability features specified in said service enablers. In this respect, the invention often refers to a Receiver domain as the network domain enabled to use service enablers provided by a Donor Domain.
The frameworks in this telecommunication system are given protocol means for allowing a framework-to-framework communication. Such protocol means include means for advertising toward a first framework in a first network domain the existence of a second framework in a second network domain with which service capability features can be shared. The protocol means also include means for advertising from a second framework in a second network domain toward a first framework in a first network domain that service capability features can be offered from service enablers of said second network domain to client applications of said first network domain.
Moreover, the means for advertising the existence of other frameworks in other domains includes means for each framework registering by itself in another framework. Apart from this self registration, or alternatively, the means for advertising toward a first framework in a first domain the existence of a second framework in a second domain includes means for the operator of said first domain registering the second framework in the first framework as well as means for the operator of said second domain registering the first framework in the second framework.
Further, the means for advertising service capability features that can be offered from service enablers of a second network domain includes means for notifying from a second framework in said second network domain toward a first framework in a first network domain service information about at least one element of service information selected from a group of elements that comprises: service identifier, service type, service availability, service properties and service interface.
Moreover, the means for advertising the existence of available service capability features in a second network domain includes means for creating, from a first framework in the first network domain toward a second framework in a second network domain, criteria for notification of such element of service information.
The telecommunication system further comprises means for carrying out security management mechanisms between the first framework in said first network domain and the second framework in said second network domain. Said means for carrying out security management mechanisms includes means for capturing service agreements between first and second domains. These service agreements specify the conditions on which the first domain can let its receiver client applications make use of the service capabilities in the second domain, and specify the obligations on which the second domain can supply the service capabilities to the first domain. These service agreements may be thus considered a policy applied between said first and second domains. In addition, or alternatively, to the above means for capturing service agreements, means for handing over service assertions and signatures may be also included within the means for carrying out security management mechanisms between the first framework and the second framework.
More specifically, this telecommunications system also comprises means for discovering service capability features available at service enablers of a second network domain between a first framework in a first network domain and a second framework in said second network domain. This includes means for negotiating specific capabilities as required by a client application in said first domain. Once these specific capabilities have been successfully negotiated, the telecommunication system includes means for returning from the second framework toward the first framework a reference to a service instance created at a service enabler of the second network domain for allowing the client application in the first network domain make use of corresponding service of the second network domain.
Still further, the telecommunications system also comprises a Service Enabler Proxy interposed between the first (Receiver) domain and the second (Donor) domain, said Service Enabler Proxy intended for acting as a Proxy for service requests from those applications in the first domain toward service enablers of the second domain, as well as communications in the opposite direction. The Service Enabler Proxy is preferably provided in the first (Receiver) domain and may comprise a number of dedicated service capability features of said first domain for storing references of corresponding service capability features of a second (Donor) domain. Therefore, the telecommunications system may comprise further means for creating a Service Enabler Proxy automatically in the first (Receiver) domain based on information received from a framework (Donor Framework) in a second (Donor) domain, said information including at least one element of service information selected from a group of elements that comprises: service identifier, service type, service availability, service properties and service interface. Alternatively, the telecommunications system may comprise further means for creating a Service Enabler Proxy by downloading code, for example source code or run-time code, from the second (Donor) domain. The telecommunications system may comprise alternative means for creating a Service Enabler Proxy by registering a particular service enabler of the second (Donor) domain in the first framework of the first (Receiver) domain, said particular service enabler for acting as Service Enabler Proxy towards the second (Donor) domain.
The telecommunications system presented herein accomplishes the objects of the invention stated above and, in particular, the first (Receiver) network domain may include the Home core network of a user whereas the second (Donor) network domain may comprise a Visited core network where the user is roaming.
A method is also provided by the present invention for providing client service applications with access to service capability features via a standardized interface (OSA/PARLAY API), the method comprising the steps of:
The method also including in accordance with the invention the steps of:
The method, in order to determine that second service capability features are available at a second network domain, further includes a step of requesting to the first Framework in the first (Receiver) network domain for access to the second service capability features available in the second (Donor) network domain. The determination may include an additional step of receiving such information from a first service capability feature selected in the first (Receiver) network domain.
Moreover, the step of discovering second service capability features that are available in the second (Donor) network domain in this method may also comprise a step of negotiating capabilities from the first Framework of the first (Receiver) network domain with the second Framework of the second (Donor) network domain. More particularly, the step of negotiating capabilities includes a step of creating an instance of a selected second service capability feature at a service enabler of the second (Donor) domain, and a step of returning back a reference to such instance from the second Framework to the first Framework.
An advantageous behavior is achieved when the method also comprises a step of registering a second Framework of a second (Donor) network domain with a first Framework of a first (Receiver) network domain. This registration includes a first step of registering the second Framework itself in the first Framework, and a second step of registering the first Framework itself in the second Framework. Apart from this self registration, or alternatively, the method may also comprise a first step where the operator of the second (Donor) network domain registers the first Framework of the first (Receiver) network domain in the second Framework, and a second step where the operator of the first (Receiver) network domain registers the second Framework of the second (Donor) network domain in the first Framework. Independently of using the self registration or the operator initiated registration, the method further comprises a step of publishing at least one interface that allows said first and said second Frameworks to access the service capability features respectively controlled by each other.
Service enablers at any particular domain may be upgraded with new or amended service capability features from time to time. There is indeed a need for updating corresponding service information throughout all domains where said service capability features are registered. Therefore, the method further comprises a step of exchanging information between a first and a second Framework about available service capability features in a first and a second network domain respectively, with or without explicit indication of the interface required to access such service capability features. In particular, when dedicated service capability features in a first network domain are responsible for determining that second service capability features are available in a second network domain, the method includes a step of indicating to at least one first service capability feature in the first network domain the at least one second service capability feature available in the second network domain, and likely a step of storing corresponding information in such dedicated service capability feature in the first network domain.
Additional advantages can be obtained by including in this method a step of capturing Service Level Agreements between the network operator of a network domain and a service provider of a requester application. Aligned with this, the method also comprises a step of capturing Service Level Agreements between a first and a second network domains through corresponding first and second Frameworks.
Thereby, said Service Level Agreements are extended between second (Donor) domains and first (Receiver) domains in such a manner that the method may further comprise the steps of:
A more advantageous security management mechanism can be achieved by including a step of handing out and handing over an Assertion that gives a practitioner the right to use a service in a federated framework setup. Therefore, the method further comprises the steps of:
requesting an Assertion; and
An additional advantage can be achieved when the method also comprises a step of creating in the first (Receiver) domain a Service Enabler Proxy arranged to act as a proxy for communicating with an instance of a selected second service capability feature at a service enabler of the second (Donor) domain. An additional advantage of such a Service Enabler Proxy is to enforce local policies, in this case in the first (Receiver) domain.
In this method, a step of creating a Service Enabler Proxy automatically in a first Framework of a first (Receiver) network domain may include a step of obtaining service information at the first (Receiver) network domain from a second (Donor) network domain for at least one element of service information selected from a group of elements that comprises: service type, service properties and service interface.
Alternatively in this method, the step of creating a Service Enabler Proxy in a first (Receiver) network domain may include a step of downloading source code or run-time code from a second (Donor) domain. The downloaded code may include local policy enforcement rules, for example by allowing the first (Receiver) domain to add source code containing the local policy, or by having in the run-time code downloaded from the second (Donor) domain references to policies stored in a local policy server. In the latter case the first (Receiver) domain just has to make sure the downloaded code is configured such that it can consult the local policy server.
In addition, one can also register a Service Enabler of the second (Donor) domain to the framework of the first (Receiver) domain and allow both domains to setup policies and have these policies enforced by the Service Enabler. The method allows that Service Enabler Proxies are created by the first (Receiver) Framework for each client application or that one main Service Enabler Proxy exists in the first (Receiver) domain that spawns off instances for each client application when requested by the first (Receiver) Framework.
The features, objects and advantages of the invention will become apparent by reading this description in conjunction with the accompanying drawings, in which:
In accordance with a first aspect of the present invention, there is provided a number of currently preferred embodiments of a system and method for supporting the execution of a service application in a user's home network that makes use of network services from an heterogeneous visited network through an extended and improved OSA/PARLAY interface, wherein said user's home network and said heterogeneous visited network belong to different domain operators, and said network services are thus not explicitly registered in the user's home network.
Generally speaking and accordingly with a second aspect of the present invention, there is also provided a number of currently preferred embodiments of said system and method for allowing a second network domain, namely a Donor domain, to offer its own service capabilities toward a first domain, namely a Receiver domain, that in turn can offer these service capabilities to its own partners or service providers.
There are provided as well particular embodiments, that, in accordance with the present invention, are shared by the above two previous aspects to allow the capture of agreements and the exchange of security assertions between different networks and domains; as well as to enforce them on run-time.
A particular architecture overview, in accordance with another aspect of the invention, is shown in
A Virtual Global Framework (VGF) is thus built up by including a number of local Frameworks (FW-1; FW-2; FW-3; FW-N) and a Framework-to-Framework interface (S-60), each local Framework locally serving a particular network domain for controlling access to service capability features (SCF) in service capability servers (SCS-1; SCS-2; SCS-3; SCS-N) of such network domain.
This VGF, and rather the new Framework-to-Framework interface (S-60) provided in accordance with the invention, generally allows remote service invocation and, more particularly, sharing services among different network domains and offering service network roaming under an OSA/PARLAY coverage. For example,
In accordance with another aspect of the present invention, the Framework-to-Framework interface (S-60) presents two main operation modes, on-line and off-line modes. An on-line mode is preferably carried out for those procedures where a first framework in a first domain serving a client application prepares the access to, and effectively access to, a second framework in a second domain where a service is invoked. Exemplary embodiments preferably carried out in an on-line mode might be those presented in
For the sake of simplicity, a preferred and quite simplified exemplary embodiment for the on-line mode operation can be better described with regard to
On the other hand, another simplified exemplary embodiment for the off-line mode operation can be better described with regard to
First of all, the register phase among different Frameworks, as
The new Remote or Donor Framework references, as well as the available services on a per remote framework basis, are preferably stored in the Local or Receiver Framework as
However, other additional advantages may be obtained when a particular service capability feature (SCF), dedicated or not, is used to this end. In accordance with another embodiment of the present invention further explained in an exemplary use case illustrated in
More particularly, an alternative further detailed embodiment is presented in view of
Proxy, in a receiver domain for selecting appropriate service capability features (SCF-2) of a donor domain to deal with the client application for a particular service.
Independently of whether the available services, or references thereof, on a per remote framework basis are stored in the local framework, or in a particular service capability feature (SCF) under control of said local framework, or in an Proxy Service Enabler interposed between donor and receiver domains, when a framework (Local; Remote; Donor) adds or changes services, said framework sends an update of such services to associate frameworks (Remote; Local; Receiver), as
Different use cases may be described following this for some of the above embodiments. Nevertheless, a use case of particular relevance is a localization service, which in accordance with some embodiments of the present invention is suitable for solving an exemplary problem commented above. Thus,
During the above security management mechanisms, the local framework (FW-1) checks whether the application (Appl-1) is allowed to use the SCF and under what policy criteria. This may be captured in the so-called Service Level Agreement (SLA) between the domain network operator and service provider. In case the application is allowed to use an SCF, the local framework (FW-1) returns identities of all the service capability features, all SCF_ID's, that might fulfill the needs of the client application (Appl-1). Next, the application selects one of these SCF_ID's, and the SCS then creates and SCF instance that is to be used by this application and is also able to check the conditions. The reference of this SCF instance is returned to the framework (FW-1), and the framework returns such reference to the application (Appl-1). From this moment on the application is able to use this SCF (SCF-1).
The application (Appl-1) asks to the SCF instance resulting Discovery interface (SCF-1) for localization of the mobile terminal “Z” (MT Z). Said SCF instance (SCF-1) detects that the MT Z is localized at network R. In other words, the first domain determines that service capability features at a second network domain, namely at network R, are available for the requester application. This response is sent back to the application (Appl-1). The application requests to the local framework (FW-1) about the possible access to remote service capability features at said remote network domain. In particular, by using the alternative embodiment of an SCS Proxy anticipated above and further described in detail, service capability features (SCF-1) in a receiver domain may be contacted for selecting appropriate service capability features (SCF-2) of a donor domain to deal with the client application for a particular service.
At this stage, the local framework (FW-1) initiates corresponding security management mechanisms with a remote framework (FW-2) in a second domain of reference where appropriate service agreements exist. Upon successful result of an applicable security management mechanism under service agreement premises a remote process can be initiated from the local framework (FW-1) toward the remote framework (FW-2) for the latter (FW-2) discovering service capability features (SCF-2) that are available for use by the requester application (Appl-1) in said second network domain. Such security management mechanism can be carried out in terms of Service Level Agreement partitions as shown in
Therefore, the local framework (FW-1) requests to the remote framework (FW-2) about service capability features (SCF-2), which may be located in a service capability server or service enabler (SCS-2) at the second domain, for the localization service. The local framework (FW-1) selects one of the available visited service capability features (SCF-2) as requested by the application (Appl-1) and negotiates specific capabilities through the remote framework (FW-2), since the local framework knows about the application needs, and the remote framework is the one having such capabilities registered. The visited service capability server (SCS-2) then creates an instance of the visited service that is going to be used by the client application (Appl-1) in the first domain. A reference to this instance is returned from the remote framework (FW-2) to the local framework (FW-1), and the local framework returns it to the application (Appl-1).
From this moment on the client application (Appl-1) is able to use the visited service capability features (SCF-2), and the process has been managed between the local and remote frameworks.
A main advantage of this aspect in accordance with the invention is that a client application only contacts with its local framework each time it wants to access a service, whilst the framework manages the following process and the relationship with other federated OSA/PARALAY environments. The client application is thus only registered in one framework and does not need be registered in all the federated domains.
Complementarily, there is provided a number of embodiments in accordance with an above second aspect of the present invention, and still accomplishing other objects of the invention. In this respect, three detailed embodiments are intended for allowing a second network domain, namely a donor domain, to offer its own service capabilities toward a first network domain, namely a receiver domain, that in turn can offer these service capabilities to its own partners or service providers, whilst allowing every domain to install and enforce its policies. Each of these three detailed embodiments offers particular embodiments for other specific aspects depending on specific advantages that might be sought.
A first detailed embodiment is presented in
Under the Service Agreement Partitioning embodiment an OSA/PARLAY Framework in the Donor Domain (hereinafter the Donor Framework) can advertise Service Enablers (SCS-2) to applications that subscribed for notifications thereof in said donor domain, using existing mechanisms as shown in
A Donor Framework in a Federation setup under this Service Agreement Partitioning embodiment is thus responsible for:
The terms of the Receiver Application Service Agreement are constructed by the Receiver Framework whereas the Donor Framework ensures that the requested Receiver Application Service Agreement is within the limits set by the terms of the Federation Service Agreement. The Receiver Application Service Agreement can be seen as a partition of the Federation Service Agreement given to a specific application. When a Receiver Application Service Agreement is given out to the Receiver Framework a new service instance is created and a reference is given to the Receiver Framework, as appearing in
On the other hand, a Receiver Framework in a Federation setup under this Service Agreement Partitioning embodiment is responsible for registering Service Enablers of the Donor Domain, which were advertised by a Donor Framework and can be also referred to as Donor Services, and make them available for own applications, as shown in
In addition to these several embodiments within the detailed Service Agreement Partitioning embodiment, dedicated Service Profiles can be created for the Donor Services as for any other service in the receiver's domain as presented in
Further, when a Receiver Application selects such a Donor Service and signs a Service Agreement with the Receiver Framework within the applicable security management mechanism in the receiver domain, said Receiver Framework requests the Donor Framework for a Receiver Application Service Agreement as a part of the corresponding security management mechanisms between donor and receiver domains. The Receiver Framework provides in this request the terms and/or restrictions that are defined in the Service Profile assigned to said Receiver Application. Then, the Donor Framework makes use these terms and/or restrictions to construct a Receiver Application Service Agreement, as the sequence diagram in
Moreover,
Under the Proxy embodiment there is provided a so-called Proxy Service Enabler (Proxy SCS) interposed between a Receiver Domain and a Donor Domain for accessing those Service Enablers (SCS-2) in the Donor Domain. More specifically, an actual first Service Enabler (Proxy SCS) is present to act within the Receiver Domain as a proxy for requests from applications in the Receiver domain to a second Service Enabler (SCS-2) in the Donor Domain, and likewise in the other direction from said second Service Enabler to the applications. From the viewpoint of such second Service Enabler in the Donor Domain, the first Service Enabler (Proxy SCS) is regarded as an application.
Moreover, as shown in
A Donor Framework in a Proxy setup is responsible for advertising new registered services to registered Receiver Frameworks. In this respect, the aforementioned methods already commented under the Service Agreement Partitioning embodiment for mutual registrations between donor and receiver frameworks, as illustrated in
On the other hand, a Receiver Framework in a Proxy setup is responsible for registering Proxy Service Enablers (Proxy SCS) and for making them available for own client applications in the Receiver Domain. Therefore, a number of alternatives are suggested in accordance with this Proxy embodiment to create a Proxy Service Enabler.
In a first alternative embodiment for creating a proxy, a Proxy Service Enabler is created in the first (Receiver) domain for communicating with an instance of a selected second service capability feature at a service enabler of the second (Donor) domain. The main advantage of such a Service Enabler Proxy is to enforce local policies, in this case in the first (Receiver) domain. The Proxy Service Enabler can be created automatically in the first (Receiver) domain based on information received from the second (Donor) domain about at least one element selected from a group of elements that comprises: service identifier, service type, service availability, service properties and service interface.
In a second alternative embodiment for creating a proxy, a Proxy Service Enabler is created in the first (Receiver) domain by downloading source code or run-time code from the second (Donor) domain. This code can be such that it is tuned to include local policy enforcement rules.
For example by allowing the first (Receiver) domain to add source code containing the local policy, or by having in the run-time code downloaded from the second (Donor) domain references to policies stored in a local policy server. In the latter case the first (Receiver) domain just has to make sure the downloaded code is configured such that the local policy server can be consulted.
In a third alternative embodiment for creating a proxy, a Proxy Service Enabler is created in the first (Receiver) domain by selecting a Service Enabler (SCS) in the second (Donor) domain, by registering this Service Enabler (SCS) to the framework of the first (Receiver) domain for acting as Proxy Service Enabler, and by allowing the Service Enabler (SCS) to setup policies for both domains and have these policies enforced. The Proxy Service Enabler may be constructed based on Service Type and property values of the real Service Enabler (SCS) in the second (Donor) domain. In this respect, construction of a Proxy Service Enabler may be a responsibility of a dedicated component such as represented in
Still addressing features under the Proxy embodiment,
A third detailed embodiment, the aforementioned Service Assertion embodiment, is found to offer additional advantages over the two previous ones. This Service Assertion embodiment is based on exchanging and practising service Assertions between a Donor and a Receiver Domain.
Under this Service Assertion embodiment, an OSA/PARLAY Framework in the Donor Domain (Donor Framework) can advertise services (Donor Services) to applications that had subscribed for notifications thereof in said Donor Domain and, according to
Therefore,
Thus, in accordance with
Conceptually, a service Assertion describes an Agreement between an application and a specific service. An Assertion can be sent to the service from a certain entity and then the service becomes available for such entity having sent the Assertion. Such Assertion ‘sending’ may be regarded in this context as ‘practicing’ the Assertion. When the Assertion is issued, it is not known yet which application or entity is going to practice that Assertion.
The Receiver Framework can advertise its obtainable Capabilities, which are represented by an Assertion, and hand over the Assertion to an application inside or outside the Receiver Domain. This application can then either practice the Assertion, or hand the Assertion over to another application. This way, Agreements accompanied with authorization rights, which are set forth to use a service according to said Agreements, can be exchanged in a very flexible manner.
Additionally, an entity handing over an Assertion, such as an application for example, can add authentication, authorization, or attribute data to the Assertion. This way, such application can customize the Assertion. Each domain handing over an Assertion can hand out additional data and associate said additional data to the Assertion. For example, the stated Capabilities can be extended or restricted with own Capabilities, thus resulting a sort of layered Assertion.
A Donor Framework in a Federation setup under this Service Assertion embodiment is thus responsible for:
In accordance with a general principle supported by the present invention, an Assertion can only be practiced once. The Donor Framework indicates to a service manager entity, which is preferably located in the service enabler (SCS-2), whether the Assertion is still valid or not. Nevertheless, the service enabler can have its own mechanism to check the validity of the Assertion without involving the framework, as anyone skilled in the art may appreciate.
On the other hand, a Receiver Framework in a Federation setup under this Service Assertion embodiment is responsible for:
In this respect, when the Receiver Framework has handed over a service Assertion it is no longer allowed to practice the Assertion itself, but just the application having received the Assertion in the Receiver Domain can then practice such Assertion, or hand it over to an other application.
Eventually, a service enabler (SCS) in a Donor Domain is responsible for:
The invention is described above in respect of several embodiments in an illustrative and non-restrictive manner. Obviously, many modifications and variations of the present invention are possible in light of the above teachings. The scope of the invention is determined by the claims with due regard to the specification and drawings, and any modification of the embodiments that fall within the scope of these claims is intended to be included therein.
Number | Date | Country | Kind |
---|---|---|---|
0203297-7 | Nov 2002 | SE | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/SE03/00520 | 4/1/2003 | WO | 1/13/2006 |