8 Service Capability features

22.1053GPPRelease 17Services and service capabilitiesTS

Services Capability Features are open, technology independent building blocks accessible via a standardised application interface. This interface shall be applicable for a number of different business and applications domains (including besides the telecommunication network operators also service provider, third party service providers acting as HE-VASPs, etc.).

All of these businesses have different requirements, ranging from simple telephony and call routing, virtual private networks, fully interactive multimedia to using UE based applications.

The service capability features shall enable applications to make use of the service capabilities (e.g. CAMEL, MExE, etc) of the underlying network in an open and secure way.

Application/Clients access the service capability features via the standardised application interface. This means that a single service capability feature is accessible and visible to application/clients via the method/operation invocations in the interface.

Two different types of service capability features can be distinguished:

– Framework service capability features: these shall provide commonly used utilities, necessary for the non-framework service capability features to be accessible, secure, resilient and manageable.

– Non-Framework service capability features: these shall enable the applications to make use of the functionality of the underlying network capabilities (e.g. User Location service capability features).

For further information see OMA Parlay Service Access Requirements [15].

8.1 Framework service capability features

Framework service capability features will be used e.g. for authentication, registration, notification, etc. and provide functionality that is independent of any particular type of service. Other commonly used service capability features may be added later.

Examples of Framework Service Capability features are (OMA Parlay Service Access Requirements [15]):

– Authentication

– User-Network Authentication

– Application-Network Authentication

– User-Application Authentication

– Authorisation

– Application-Network Authorisation

– User-Application Authorisation

– Registration

– Discovery

– Notification.

8.2 Non-Framework service capability features

The Non-Framework service capability features represent the total collection of service capability features that are not included in the Framework. These non-framework service capability features enable the application to make use of the functionality provided by the network and service capabilities.

Service capability features shall be defined as much as possible in a generic way to hide the network specific implementation. To achieve this, it is necessary to identify the functionality that is provided by more than one service capabilities. For example, User Location can be produced in several underlying ways. This functionality can be captured once when defined the service capability features in a generic way. It is important that the generic part becomes as large as possible.

When applications use the generic service capability features, these applications become independent of (portable over) underlying service capabilities. Applications shall however still be able to request service capability features specific to a service capability (e.g. Call Setup from CAMEL). This will increase dependency of the used service capability.

Examples of Non-Framework service capability features are (OMA Parlay Service Access Requirements [15]):

– Session Control

– Security/Privacy

– Address Translation

– Location

The precision of the location shall be network design dependent, i.e. an operator choice. This precision may vary from one part of a network to another. It may be chosen to be as low as hundreds of meters in some place and as accurate as 5 meters in other place. It is required that a minimum precision of around 50 meters can be achieved in all types of terrestrial radio environment. Technical issues may constrain the precision to be mobile state dependent as well (mobile idle / mobile in communication). Several design optional features (e.g. size of the cell, adaptive antenna technique, path loss estimation technique…) shall allow the network operator to reach cost effectively the target precision.

Because there may be very different uses of the location information;

– It shall be possible to make the information available to the user, HE/SN and value added service providers. The user shall be able to restrict access to the location information (permanently or on a per call basis). The restriction can be overridden by the network operator when appropriate (e.g. emergency calls).

– It shall be possible to set the delay to get the location information (the situation is quite different whether the information is needed for call routing or if it is needed by a user application).

– It shall be possible to select the frequency of the location information update.

– to identify and report when the user’s terminal enters or leaves a specified geographic area.

– It shall be possible to specify the area as a circular zone (centre and radius) to a resolution that will be limited by the accuracy capability of the part of the serving network where the user is registered.

– User Status

– Terminal Capabilities

– Messaging

– Data Download

– User Profile Management

– Charging