5 Open Service Access

23.1983GPPOpen Service Access (OSA)Stage 2TS

In order to be able to implement future applications/end user services that are not yet known today, a highly flexible Framework for Services is required. The Open Service Access (OSA) enables applications implementing the services to make use of network functionality. Network functionality offered to applications is defined in terms of a set of Service Capability Features (SCFs). These SCFs provide functionality of network capabilities, which is accessible to applications through the standardized OSA interface for service development.

The aim of OSA is to provide a standardized, extensible and scalable interface that allows for inclusion of new functionality in the network in future releases with a minimum impact on the applications using the OSA interface.

Network functionality offered to applications is defined as a set of Service Capability Features (SCFs) in the OSA API, which are supported by different Service Capability Servers (SCS). These SCFs provide access to the network capabilities on which the application developers can rely when designing new applications (or enhancements/variants of already existing ones). The different features of the different SCSs can be combined as appropriate.
The exact addressing (parameters, type and error values) of these features is described in stage 3 descriptions.
These descriptions (defined using UML and in three realizations: OMG Interface Description LanguageTM, Java J2SETM and Java J2EETM are open and accessible to application developers, who can design services in any programming language, while the underlying core network functions use their specific protocols. The present document also contains a set of Web Services called Parlay X Web Services, specified in WSDL.

The standardized OSA APIs are secure, independent of vendor specific solutions and independent of programming languages, operating systems etc used in the service capabilities. The OSA APIs are independent of the location within the home environment where service capabilities are implemented, and independent of supported service capabilities in the network. Furthermore, an architecture with open interfaces allows for application developers to rapidly design new and innovative applications.

5.1 Overview of the Open Service Access

The Open Service Access consists of three parts:

  • Applications: e.g. VPN, conferencing, location based applications. These applications are implemented in one or more Application Servers.
  • Framework: providing applications with basic mechanisms that enable them to make use of the service capabilities in the network. Examples of framework functions are Authentication, and Registration and Discovery. Service Capability Features made available to applications are Registered in the Framework. Before an application can use the network functionality made available through Service Capability Features, authentication between the application and framework is needed. After authentication, the discovery function enables the application to find out which Service Capability Features are provided by the Service Capability Servers. The Service Capability Features are accessed by the methods defined in the OSA interfaces.
  • Service Capability Servers: providing the applications with Service Capability Features, which are abstractions from underlying network functionality. Examples of Service Capability Features offered by the Service Capability Servers are Call Control and User Location. Similar Service Capability Features may possibly be provided by more than one Service Capability Server. For example, Call Control functionality might be provided by SCSs on top of CAMEL and MExE.

Figure 5.1.1: Overview of Open Service Access

The present document, together with the associated stage 3 specification, defines the OSA APIs. OSA does not mandate any specific platform or programming language.

The Service Capability Servers that provide the OSA interfaces are functional entities that can be distributed across one or more physical nodes. For example, the User Location interfaces and Call Control interfaces might be implemented on a single physical entity or distributed across different physical entities. Furthermore, a service capability server can be implemented on the same physical node as a network functional entity or in a separate physical node. For example, Call Control interfaces might be implemented on the same physical entity as the CAMEL protocol stack (i.e. in the CSE) or on a different physical entity.

Several options exist:

Option 1

The OSA interfaces are implemented in one or more physical entity, but separate from the physical network entities. Figure 5.1.2 shows the case where the OSA interfaces are implemented in one physical entity, called "gateway" in the figure. Figure 5.1.3 shows the case where the SCSs are distributed across several "gateways".

Figure 5.1.2: SCSs and network functional entities implemented in separate physical entities

Figure 5.1.3: SCSs and network functional entities implemented in separate physical entities,
SCSs distributed across several "gateways"

Option 2

The OSA interfaces are implemented in the same physical entities as the traditional network entities (e.g. HSS, CSE), see Figure 5.1.4.

Figure 5.1.4: SCSs and network functional entities implemented in same physical entities

Option 3

Option 3 is the combination of option 1 and option 2, i.e. a hybrid solution.

Figure 5.1.5: Hybrid implementation (combination of options 1 and 2)

It shall be noted that in all cases there is only one Framework. This framework may reside within one of the physical entities containing an SCS or in a separate physical entity.

From the application point of view, it shall make no difference which implementation option is chosen, i.e. in all cases the same network functionality is perceived by the application. The applications shall always be provided with the same set of interfaces and a common access to framework and Service Capability Feature interfaces. It is the framework that will provide the applications with an overview of available Service Capability Features and how to make use of them.

The implementation of applications that make use of the OSA interfaces is not constrained or limited to a particular programming language; middleware choice or physical architecture by the OSA interfaces themselves. Applications may be realized as functional entities that can be distributed across one or more physical entities, e.g. platforms, processes etc. For example, a logical application providing call routing capability may be realized as a number of discrete physical applications in order to support differentiated application behaviour; application scalability or application resilience. However, the logical relationship established between applications, framework and SCFs, must always be maintained such that the integrity, security and use of the OSA interfaces remains consistent.

A range of options exist that allows applications to be realized as a number of physical entities in a manner that maintains the integrity of the OSA architecture:

Option 1

The application is produced as a single physical entity.

Figure 5.1.6: Application function implemented as a single physical entity

Option 2

The functionality of the application is realized using multiple physical entities. Figure 5.1.7 and figure 5.1.8 represent alternative solutions where the same application obtains a reference to the same SCF interface. In figure 5.1.7, each physical application uses a unique set of interfaces supplied by the Framework for each application access session, whereas in figure 5.1.8 the Framework shares the same interfaces. In either case the Framework resolves the application sessions to a single FW-Svc session, and a single service manager is provided to the functional application.

Figure 5.1.7: Application function implemented in several physical entities
(unique Framework Interface References for each application entity)

Figure 5.1.8: Application function implemented in several physical entities
(sharing common Framework Interface References)

The application examples above depict an OSA Gateway with both Framework and SCF functions supported on a single physical entity. Further Gateway architectures in which the Framework and SCFs are supported in multiple discrete physical entities are also possible.

5.2 Basic mechanisms in the Open Service Access

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

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 function. The authentication model of OSA is a peer-to-peer model. The application must authenticate the framework and vice versa. The application must be authenticated before it is allowed to use any other OSA function.
  • Authorization: Authorization is distinguished from authentication in that authorization is the action of determining what a previously authenticated application is allowed to do. Authentication must precede authorization. Once authenticated, an application is authorized to access certain Service Capability Features.
  • Discovery of framework functions and Service Capability Features: After successful authentication, applications can obtain available framework functions and use the discovery function to obtain information on authorized Service Capability Features. The Discovery function can be used at any time after successful authentication.
  • Establishment of service agreement: Before any application can interact with a Service Capability Feature, a service agreement must 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 Service Capability Feature.
  • Access to Service Capability Features: The framework must provide access control functions to authorize the access to Service Capability Features 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:

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

Basic mechanisms between Application Server and Service Capability Server:

  • Request of event notifications. This mechanism is applied when a user has subscribed to an application and that application needs to be invoked upon receipt of events from the network related to the user. For example, when a user subscribes to an incoming call screening application, the application needs to be invoked when the user receives a call. It will therefore request to be notified when a call setup is performed, with the user number as Called Party Number.

5.3 Service Brokering

The service broker function enables the brokering of multiple services in a managed and controlled fashion.

Figure 5.3.1: Service Broker function implemented as separate physical entity

The diagram depicts the interfaces between the various entities requiring brokering of services within the OSA environment. In this diagram the service broker is identified as an independent physical entity to that which supports the SCF. This is not mandated, but is depicted to indicate that such an architecture is possible.

The OSA Service Broker API includes the ability to specify provisioning and configuration data required to control the service brokering.

The messaging interfaces between Service Broker and OSA SCSs or other service delivery nodes/elements is based upon the network interfaces supported by each system. Note that the above architecture does not preclude the OSA SCS communicating directly with network entities where service interaction is not required.