23.1273GPPRelease 6TSVirtual Home Environment (VHE) / Open Service Access (OSA)
6.1 Trust and Security Management Functions
The Trust and Security Management functions provide:
– the first point of contact for an application to access a Home Environment;
– the authentication methods for the application and Home Environment to perform an authentication protocol;
– the application with the ability to select a network service capability feature to make use of;
– the application with a portal to access other framework functions.
The process by which the application accesses the Home Environment has been separated into 3 stages, each supported by a different framework function:
1) Initial Contact with the framework;
2) Authentication to the framework;
3) Access to framework functions and network service capability features.
6.1.1 Initial Contact
The application gains a reference to the Initial Contact function for the Home Environment that they wish to access. This may be gained through a URL, a Naming or Trading Service or an equivalent service, a stringified object reference, etc. At this stage, the application has no guarantee that this is a reference to the Home Environment.
The application uses this reference to initiate the authentication process with the Home Environment.
Initial Contact supports a particular method to allow the authentication process to take place (using the Authentication SCF defined in subclause 6.1.2). This method must be the first invoked by the application. Invocations of other methods will fail until authentication has been successfully completed.
Once the application has authenticated with the provider, it can gain access to other framework functions and network service capability features. This is done by invoking a method, by which the application requests a certain type of access service capability feature. The OSA Access function is defined in subclause 6.1.3.
Once the application has made initial contact with the Home Environment, authentication of the application and Home Environment may be required.
The API supports multiple authentication techniques. The procedure used to select an appropriate technique for a given situation is described below. The authentication mechanisms may be supported by cryptographic processes to provide confidentiality, and by digital signatures to ensure integrity. The inclusion of cryptographic processes and digital signatures in the authentication procedure depends on the type of authentication technique selected. In some cases strong authentication may need to be enforced by the Home Environment to prevent misuse of resources. In addition it may be necessary to define the minimum encryption key length that can be used to ensure a high degree of confidentiality.
The application must authenticate with the framework before it is able to use any of the other interfaces supported by the framework. Invocations on other interfaces will fail until authentication has been successfully completed.
6.1.3 OSA Access
This function supports stage 1 requirements related to authorization and service registration.
During an authenticated session accessing the Framework, the application will be able to select and access an instance of a framework function or network service capability feature.
In order to use network SCFs, the application must first be authorised to do so by establishing a service agreement with the Home Environment. The application uses the discovery SCF to retrieve the ID of the network SCF they wish to use.They may then check that they are authorised to use the SCF. The Home Environment is informed that the application wishes to use the SCF. Finally, a service agreement is signed digitally between the two parties.
Establishing a service agreement is a business level transaction, which requires the HE-VASP that owns the application to agree terms for the use of an SCF with the Home Environment. Service agreements can be reached using either off-line or on-line mechanisms. Off-line agreements will be reached outside of the scope of OSA interactions, and so are not described here. However, applications can make use of service agreements that are made off-line. Some Home Environments may only offer off-line mechanisms to reach service agreements.
After a service agreement has been established between the application and the Home Environment domains, the application will be able to make use of this agreement to access the SCF.
Before a network SCF can be discovered, the application must know what "types" of SCFs are supported by the Framework and what "properties" are applicable to each SCF type. Once the HE-VASP finds out the desired set of SCFs supported by the network, it subscribes (a sub-set of) these SCFs using the Subscription framework function. The HE-VASP (or the applications in its domain) can find out the set of SCFs available to it (i.e., the SCFs that it can use).
6.3 Integrity Management functions
6.3.1 Load Manager
The Load Manager function permits to manage the load on both the application and network sides.
The framework API should allow the load to be distributed across multiple machines and across multiple component processes, according to a load balancing policy. The separation of the load balancing mechanism and load balancing policy ensures the flexibility of the load balancing functionality. The load balancing policy identifies what load balancing rules the framework should follow for the specific application. It might specify what action the framework should take as the congestion level changes. For example, some real-time critical applications will want to make sure continuous service is maintained, below a given congestion level, at all costs, whereas other applications will be satisfied with disconnecting and trying again later if the congestion level rises. Clearly, the load balancing policy is related to the QoS level to which the application is subscribed.
6.3.2 Fault Manager
The Fault Manager function is used by the application to inform the framework of events which affect the integrity of the framework and SCFs, and to request information about the integrity of the system.
6.3.3 Heartbeat Management
The Heartbeat Management function allows the initialisation of a heartbeat supervision of the client application. In case of SCF supervision, it is the framework’s responsibility to check the health status of the respective SCF.
Since the OSA API is inherently synchronous, the heartbeats themselves are synchronous for efficiency reasons.
The OAM function is used to query the system date and time. The application and the framework can synchronise the date and time to a certain extent. Accurate time synchronisation is outside the scope of the OSA API.
6.5 Policy Management
Applications shall have the ability to interact with policy-enabled Service Capability Features in a secure manner. Policy Management allows applications to:
– manage the application’s policy-related information;
– manage policy event notification;
– collect policy statistics.
Editor’s note: Architectural aspects may concern the storage of policies in the network in order to be shared between different SCSs.