4 Overview of the Framework

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

This clause explains which basic mechanisms are executed in the OSA Framework prior to offering and activating applications.

The Framework API contains interfaces between the Application Server and the Framework, between Network Service Capability Server (SCS) and the Framework, and between the Enterprise Operator and the Framework (these interfaces are represented by the yellow circles in the figure below). The description of the Framework in the present document separates the interfaces into three distinct sets: Framework to Application interfaces, Framework to Enterprise Operator interfaces and Framework to Service interfaces.

Some of the mechanisms are applied only once (e.g. establishment of service agreement), others are applied each time a user subscription is made to an application (e.g. enabling the call attempt event for a new user).

Basic mechanisms between Application and Framework:

– Authentication: Once an off-line service agreement exists, the application can access the authentication interface. The authentication model of OSA is a peer-to-peer model, but authentication does not have to be mutual. The application must be authenticated before it is allowed to use any other OSA interface. It is a policy decision for the application whether it must authenticate the framework or not. It is a policy decision for the framework whether it allows an application to authenticate it before it has completed its authentication of the application.

– Authorisation: Authorisation is distinguished from authentication in that authorisation is the action of determining what a previously authenticated application is allowed to do. Authentication shall precede authorisation. Once authenticated, an application is authorised to access certain SCFs.

– Discovery of Framework and network SCFs: After successful authentication, applications can obtain available Framework interfaces and use the discovery interface to obtain information on authorised network SCFs.
The Discovery interface can be used at any time after successful authentication.

– Establishment of service agreement: Before any application can interact with a network SCF, a service agreement shall be established. A service agreement may consist of an off-line (e.g. by physically exchanging documents) and an on-line part. The application has to sign the on-line part of the service agreement before it is allowed to access any network SCF.

Access to network SCFs: The Framework shall provide access control functions to authorise the access to SCFs or service data for any API method from an application, with the specified security level, context, domain, etc.

Basic mechanism between Framework and Service Capability Server (SCS):

  • Registering of network SCFs:. SCFs offered by a SCS can be registered at the Framework. In this way the Framework can inform the Applications upon request about available SCFs (Discovery). For example, this mechanism is applied when installing or upgrading an SCS.

Basic mechanism between Framework and Enterprise Operator:

Service Subscription function: This function represents a contractual agreement between the Enterprise Operator and the Framework. In this subscription business model, the enterprise operators act in the role of subscriber/customer of services and the client applications act in the role of users or consumers of services.
The framework itself acts in the role of retailer of services.

The following clauses describe each aspect of the Framework in the following order:

  • The sequence diagrams give the reader a practical idea of how the Framework is implemented.
  • The class diagrams clause shows how each of the interfaces applicable to the Framework relate to one another.
  • The interface specification clause describes in detail each of the interfaces shown within the class diagram part.
  • The State Transition Diagrams (STD) show the transition between states in the Framework. The states and transitions are well-defined; either methods specified in the Interface specification or events occurring in the underlying networks cause state transitions.
  • The data definitions clause shows a detailed expansion of each of the data types associated with the methods within the classes. Note that some data types are used in other methods and classes and are therefore defined within the common data types part of the present document (29.198-2).

An implementation of this API which supports or implements a method described in the present document, shall support or implement the functionality described for that method, for at least one valid set of values for the parameters of that method. Where a method is not supported by an implementation of a Framework or Service interface, the exception P_METHOD_NOT_SUPPORTED shall be returned to any call of that method. Where a method is not supported by an implementation of an Application interface, a call to that method shall be possible, and no exception shall be returned.