23.1273GPPRelease 6TSVirtual Home Environment (VHE) / Open Service Access (OSA)
Network service capability features are provided to the applications by service capability servers to enable access to network resources.
7.1 Call Control
The Call Control SCF supports stage 1 requirements related to CS call control, IMS session control and call/session charging.
The Call Control network service capability feature supports the following functionality:
1) management function for call/session-related issues, e.g. enable or disable call/session-related event notifications.
2) call/session control, e.g. route, disconnect.
7.1.1 Mapping of OSA APIs in CS domain
In the CS domain the OSA Call Control SCF may be mapped to CAP and MAP protocols.
7.1.2 Mapping of OSA APIs in IMS
OSA SCS is one of the three types of "application servers" communicating with S-CSCF in the IMS . OSA Application Server is connected by OSA API to OSA Service Capability Server (SCS) that is connected through ISC interface to S-CSCF and through Sh interface to HSS. ISC interface is based on the use of SIP protocol, see TS 23.218 . The details and functionality of the Sh interface are for further study in TS 23.228 .
OSA functions for IMS session control are supported by the following entities:
– The Serving-CSCF (S-CSCF), which performs session control services for an originating or terminating party.
– The Media Resource Function (MRF), which performs conference control and media control functions for multiparty multimedia sessions.
Figure 6: Mapping of OSA IMS session control on the IMS
The stage 3 specification of OSA for IMS session control shall take into account this distribution of responsibilities between the S-CSCF and the MRF, by specifying specific OSA SCF(s) or interface(s) for the S-CSCF, and specific OSA SCF(s) or interface(s) for the MRF. This is to permit clear mapping of OSA on the corresponding entities’ functionality, as well as allowing multivendorship.
IMS session control SCF(s) or interface(s) applicable to the S-CSCF shall be mapped onto the IMS Service Control (ISC).
The MRF is either controlled by the OSA SCS by (1) using SIP 3rd party call control via the S-CSCF or (2) using a direct interface to the MRF. These two options are still under investigation.
TS 22.127  classifies IMS session control functions as follows:
– session control requirements;
– media control requirements;
– information requirements.
IMS session control SCF(s) or interface(s) applicable to the S-CSCF shall support session control and information requirements applicable to the originating or terminating party of 2-party session.
These OSA SCF(s) or interface(s) and their implementation shall take into account that the S-CSCF:
– Is an entity that is dynamically associated to the user when she registers to the IMS;
– May behave as a SIP registrar, proxy server, and user agent;
– May receive the request from a session party to initiate an ad-hoc conference (to be associated to an MRF);
– May generate CDRs.
IMS session control SCF(s) or interface(s) applicable to the MRF shall support all session control, media control, and information requirements.
These OSA SCF(s) or interface(s) and their implementations shall take into account that the MRF:
– May support both ad-hoc and pre-arranged conferences;
– Controls media stream resources associated to the conference;
– Behaves as a SIP user agent with regard to each party of the conference;
– Supports conference booking and floor control;
– Is divided into Media Resource Function Controller (MRFC) and Media Resource Function Protocol (MRFP), which interface via an H.248 fully compliant interface.
7.2 Data Session Control
The Data Session Control SCF supports stage 1 requirements related to PS call control.
The Data Session Control network service capability feature supports the following functionality:
1) management functions for data session related issues, e.g. enable or disable data session-related event notifications
2) session control, e.g. route, disconnect.
The Mobility SCF addresses stage 1 requirements for user location and user statusbased on network-related information.
The Mobility SCF provides terminal location information and general terminal status monitoring. The following information is reported when requested provided that the network is able to support the corresponding capability:
– user whom the report concerns;
– VLR number;
– Cell Global Identification or Location Area Identification;
– location number (network specific, refer to ITU-T Q.763);
– geographical location (e.g. in terms of universal latitude and longitude co-ordinates);
– accuracy (value depending on local regulatory requirements and level of support in serving/home networks; note that the accuracy of the serving network might differ from that in the home environment);
– age of location information (last known date/time made available in GMT);
– status of the user’s terminal.
Connection of an external LCS client by means of OSA API to GMLC is shown in TS 23.271 , figure 6.1: General arrangement of LCS.
An application uses the Mobility SCF to perform the following:
– user location requests;
– requests for starting (or stopping) the generation by the network of periodic user location reports;
– requests for starting (or stopping) the generation by the network of user location reports based on location changes;
– report of location information;
– notification of location update.
The application can also for each user start/stop receipt of notifications and modify the required accuracy by selecting another option from the network provided options.
7.4 Terminal Capabilities
The Terminal Capabilities SCF provides applications information about the terminal capabilities of the user. It shall be possible for an application to request Terminal Capabilities as defined by MExE (MExE User Profile) . The terminal capabilities are provided by a MExE compliant terminal to the MExE Service Environment either on request or by the terminal itself.
Terminal Capabilities are available only after a capability negotiation has previously taken place between the user´s MExE terminal and the MExE Service environment as specified in .
NOTE: For Release 5 only WAP and MExE devices can supply terminal capabilities.
7.5 User Interaction
The User Interaction SCFs support stage 1 requirements for information transfer.
There are two user interaction SCFs:
– Generic User Interaction: used by applications to interact with end users;
– Call User Interaction: used by applications to interact with end users participating to a call.
The Charging SCF addresses stage 1 requirements for charging related to service usage (and not call/session control).
This SCF permits an application to access subscriber accounts maintained by the network and charge subscribers for service usage.
Provided, that these functions are supported by the underlying network an application providing a service to the subscriber can use the Charging SCF to:
– Check, if – for the service to be provided by the application – the charge is covered by the subscribers account or credit limit.
– Reserve – for the service to be provided by the application – a charge in the subscribers account, that can be deduced from the account after service delivery.
– Deduct an amount from the subscriber’s account.
– Release a reservation acquired earlier.
– Add non-monetary units to a subscriber’s account.
– Deduct non-monetary units from a subscriber’s account.
Reverse a completed charge transaction, e.g. after repudiation.
7.8 Account Management
The Account Management SCF addresses stage 1 requirements related to the features to monitor subscriber’s account:
– retrieval of transaction history for a certain subscriber’s account;
– query of the balance of the account of one or several subscriber’s;
– request of notifications on certain criteria for one or several subscribers.
The Presence SCF addresses stage 1 requirements on presence related capability functions.
OSA shall allow an application access to presence capabilities within the network. Presence related information may be requested or supplied by an OSA application and may include, but not be limited to presence information pertaining to the presence service or user availability. Presence information, i.e. a set of attributes characterising current properties of a presentity, is described in TS 22.141 .
An OSA application shall be able:
– to register as a watcher, to request a presentity’s presence information and to be notified of changes in the presence information.
– to register as a presentity, to publish presence information, to retrieve watcher information and to manage related parameters (e.g. access rules). Presence management may include the setting of user preferences, the update of access rules…etc.
7.9.1 Mapping of OSA APIs
The Presence OSA APIs can be mapped to reference points Peu and Pw of the Presence Server.
Figure 7: Mapping of OSA Presence APIs
Reference points Peu (i.e. between a Presence User Agent and the Presence Server) and Pw (i.e. between Watcher Applications and the Presence Server) are described in TS 23.141 .