7.1.4 Service Agreement Management Sequence Diagrams

29.198-033GPPOpen Service Access (OSA) Application Programming Interface (API)Part 3: FrameworkTS Service Selection

The following figure shows the process of selecting an SCF.

After discovery the Application gets a list of one or more SCF versions that match its required description. It now needs to decide which service it is going to use; it also needs to actually get a way to use it.

This is achieved by the following two steps:

1: Service Selection: first step – selectService

In this first step the Application identifies the SCF version it has finally decided to use. This is done by means of the serviceID, which is the agreed identifier for SCF versions. The Framework acknowledges this selection by returning to the Application an identifier for the service chosen: a service token, that is a private identifier for this service between this Application and this network, and is used for the process of signing the service agreement.

Input is:

· in serviceID.

This identifies the SCF required.

And output:

· out serviceToken.

This is a free format text token returned by the framework, which can be signed as part of a service agreement. It contains operator specific information relating to the service level agreement. An application (identifiable by a given TpClientAppID) may select the same service on more than one occasion in which case the same serviceToken, that identifies the relationship between the Application and the network, and the service agreement that applies, shall be returned.

2: Service Selection: second step – signServiceAgreement

In this second step an agreement is signed that allows the Application to use the chosen SCF version. And once these contractual details have been agreed, then the Application can be given the means to actually use it. The means are a reference to the manager interface of the SCF version (remember that a manager is an entry point to any SCF). By calling the createServiceManager operation on the lifecycle manager the Framework retrieves this interface and returns it to the Application. The service properties suitable for this application are also fed to the SCF (via the lifecycle manager interface) in order for the SCS to instantiate an SCF version that is suitable for this application.

The sequence of events indicated above, where the application initiates the signature process by calling initiateSignServiceAgreement, and where the framework calls signServiceAgreement on the application’s IpAppServiceAgreementManagement interface before the application calls signServiceAgreement on the frameworks’s IpServiceAgreementManagement, is the only sequence permitted.


· in serviceToken.

This is the identifier that the network and Application have agreed to privately use for a certain version of SCF.

· in agreementText.

This is the agreement text that is to be signed by the Framework using the private key of the Framework.

· in signingAlgorithm.

This is the algorithm used to compute the digital signature.


· out signatureAndServiceMgr.

This is a reference to a structure containing the digital signature of the Framework for the service agreement, and a reference to the manager interface of the SCF.

There must be only one service instance per client application. Therefore, in case an application (identifiable by a given TpClientAppID) attempts to select a service for which it has already signed a service agreement and this service agreement has not been terminated, the Framework may return a reference to the already existing service, or may raise an exception to the client indicating that this request is denied.