Content for TS 22.105 Word version: 18.0.1

6.1 Definition of teleservices 6.2 Description of teleservices 6.3 Support of teleservices 6.4 Existing Teleservices supported by PLMN 6.5 Internet Access 8.1 Framework service capability features 8.2 Non-Framework service capability features 9.1 Access protocols 9.2 Execution Environment

6 Teleservices p. 18

6.1 Definition of teleservices p. 18

Teleservices provide the full capabilities for communications by means of terminal equipment, network functions and possibly functions provided by dedicated centres.

6.2 Description of teleservices p. 18

The basic reference for the description of teleservices is the ITU-T Recommendation F.700 [12]. It provides a generic, network independent, description of multimedia services. The methodology used covers both single media and multimedia services, the single media services being a particular type of multimedia services. Multimedia services are classified into categories with similar functional characteristics. The six categories are multimedia conference services, multimedia conversational services, multimedia distribution services, multimedia retrieval services, multimedia messaging services and multimedia collection services.

The rest of clause 6 describes the teleservices and options that shall be provided.

A teleservice can be viewed as set of upper layer capabilities utilising the lower layer capabilities described by the set of attributes in clause 5.

Multimedia teleservices support the transfer (and in some case retrieval, messaging, distribution) of several types of information (service components). For this reason, there are service attributes (relating to all the components of a teleservice) and service component attributes (relating to only one service component).

6.3 Support of teleservices p. 19

The realisation of teleservices requires the association of terminal and network capabilities. In the terminals and in the network, both upper layer capabilities and lower layer capabilities are necessary. The term upper layer capabilities is used because it relates to the OSI upper layers. Decoupling between upper layers and lower layers (transfer) is required. Even if this de-coupling may impact radio interface optimisation, it is nevertheless the only way of designing a system that is not outdated;

Each time the information rate associated with an already supported teleservice is decreased by more efficient source coding techniques.
Each time a new service is introduced that requires transfer capabilities not used by currently available teleservices.

Taking the example of two application that exchange information through a teleservice, the upper layer capabilities can be located in various places;

In the two terminals if the two applications are connected to a PLMN.

Reproduction of 3GPP TS 22.105, Fig. 6.3-1: PLMN teleservice

Figure 6.3-1: PLMN teleservice

In the terminal of the application connected to a PLMN and in the upper layer interworking unit that is at the border of the PLMN and the target network if one application is connected to a PLMN and the other one is connected to another type of system. The upper layer interworking unit makes the adaptation between the PLMN and the target network at a service level.

Reproduction of 3GPP TS 22.105, Fig. 6.3-2: Teleservice with upper layer interworking

Figure 6.3-2: Teleservice with upper layer interworking

In the terminal of the application connected to a PLMN and in the terminal of the application connected to a target network if one application is connected to a PLMN and the other one is connected to another type of system, but only lower layer interconnecting unit is used at the border of the two networks. In this case, the interconnecting unit makes the adaptation between the PLMN and the target network at the transmission level.

Reproduction of 3GPP TS 22.105, Fig. 6.3-3: Teleservice with lower layer interworking

Figure 6.3-3: Teleservice with lower layer interworking

6.4 Existing Teleservices supported by PLMN p. 20

The subset of standardised teleservices shall be supported for interworking with teleservices provided on other networks. The means to support the following set of teleservices will be standardised:

Speech;
Emergency call;
Short message service;

3GPP TS 22.003 describes the circuit teleservices.

6.4.1 Speech p. 20

The speech service as defined in international standards should be supported. The international reference for the speech is ITU-T Recommendation E.105 [17]. Networks should contain interworking units which allow calls to be received from or destined to users of existing networks like PSTN or ISDN. This will include interworking units for generation of DTMF or other tones (the entire DTMF tone set would at minimum be available) and detection of DTMF tones.

A default speech codec shall be specified to provide speech service. The selected speech codec shall be capable of operating with minimum discernible loss of speech on handover between the GERAN and UTRAN.

6.4.2 Emergency Call p. 20

This service will use a speech component and may additionally include a data component. There are however compared to telephony reduced authentication requirements and a requirement for specific routing. Additionally Emergency Calls may have higher priority than normal calls. See TS 22.101 for further details.

6.4.3 Short Message Service - Point to Point (SMS-PP) p. 20

A short message service point to point shall be supported. The short message service shall be provided seamlessly (as far as the user or the users terminal equipment is concerned) across the UTRAN and GERAN. A UE may, and the network shall, support the transport of SMS over WLAN and other IP Connectivity Access Networks (IP-CANs).

When short message services are transported over a generic IP-CAN:

appropriate security mechanisms shall be supported;
users registered from an SMS-capable UE will receive the SMS service over a generic IP-CAN while maintaining the format and functionality of SMS messages;
the UE shall indicate its ability to send/receive SMS messages at registration;
existing services that use SMS functionality shall not be degraded;
the user experience shall be the same as across UTRAN and GERAN access.

Users registered from a UE capable of using another messaging service such as Immediate Messaging but not registered to receive the SMS service over a generic IP-CAN, will receive the SMS service using the other messaging service when service-level interworking is provided and if operator policy allows it. In case operator policy does not allow service-level interworking, then the message may be transported over CS or PS.

When the sender's identity is verified by the network operator, it shall be possible to convey this information as well as the verified identity of the sender (e.g. sender name), together with the SMS message, to the recipient.

6.4.4 Short Message Service - Cell Broadcast (SMS-CB) p. 21

A short message service cell broadcast shall be provided seamlessly (as far as the user or the users terminal equipment is concerned) across the UTRAN and GERAN.

6.5 Internet Access p. 21

3GPP specifications shall provide the means to interwork with external data networks. This interworking shall satisfy, within the constraints introduced by the mobile radio environment, the QoS requirements of the interworked-with network. The Internet is seen as the most important interworked-with network, therefore the specification of an optimised access to Internet will be part of the 3GPP specifications. The most important benefits achieved by the definition of Internet Access would be:

Optimised transmission of IP traffic over the radio interface to minimise the amount of information transmitted.
Optimised usage of encryption protocols/algorithms over the radio interface.
Inter-operation of QoS mechanisms.

For the purposes of optimised access to Internet one or more of the generic bearers will be used. The QoS mechanisms defined for packet access mode will be harmonised with those defined for Internet (e.g. Differentiated Services).

7 Supplementary Services p. 21

Supplementary services are used to complement and personalise the usage of basic telecommunication services (bearer services and teleservices). The capabilities standardised shall enable all the supplementary services specified in TS 22.004 to be provided.

8 Service Capability features p. 21

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 p. 22

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 p. 22

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

9 Standardised Protocols and Capabilities p. 23

This clause introduces a list of standardised protocols and capabilities that shall be supported for the control and creation of services. The access protocols and the execution environment described below are essential.

9.1 Access protocols p. 24

The access protocols shall allow the support of multimedia services. These services are characterised by the ability to dynamically change the number of participants and the number of connections during a call. The characteristics of the connections (confer the list of attributes used to describe a connection) may differ from one connection to another. They are negotiated during call set-up. They may be independently and dynamically re-negotiated on application (the telecommunication requirements of the application changes) or network initiative (change of network load conditions, during a handover procedure) during the call.

The application may require synchronisation between some of the connections. Later, this synchronisation shall not be lost during handover procedures.

Whenever a call is terminated in other types of networks, the negotiation shall take into account the limitations of these networks. Interworking shall be possible with PLMN, PSTN, ISDN and Internet networks. The access protocols shall allow a user equipment to have several calls active simultaneously.

9.2 Execution Environment p. 24

The execution environment is a set of standardised capabilities that shall allow the support of HE/SN specific services (i.e. both applications, teleservices and supplementary services). The execution environment shall be distributed between the IC card, terminal and network nodes. The terminal and the serving network capabilities shall be the only limiting factor for the support of the services designed to run on the execution environment. The execution environment is composed of the following building blocks;

A standardised content description language for support of HE/SN specific user interfaces (both for information output and user input). This is intended only for platforms which are terminals.
A standardised procedural language for support of HE/SN specific scripts. This language shall be common to all types of platforms. The scripts could be used for e.g. improving the user interface, adding new features to the terminal like the latest version of a codec, controlling the execution of a service.
Standardised application programming interfaces for opening platform resources and capabilities to the scripts written with the standardised procedural language. These interfaces would be platform type dependent. The interfaces shall include primitives for accessing to the basic control functions, as illustrated on the figures 5 and 6 below.

Reproduction of 3GPP TS 22.105, Fig. 9.2-1: Execution Environment in the User Equipment

Figure 9.2-1: Execution Environment in the User Equipment

Reproduction of 3GPP TS 22.105, Fig. 9.2-2: Execution Environment in the Network

Figure 9.2-2: Execution Environment in the Network

Call states, messages, information elements, values of information elements shall serve as triggers for subsequent interaction with service logic. The list of triggers shall incorporate those provided by CAMEL, SIM Toolkit, MExE.
Means to turn triggers on and off, and associate them with service logic will be standardised.
A standardised certification scheme and security model with several levels of trusts in order to control the scripts access rights to the platform resources and capabilities. This would be used to allow e.g. the SP and the HE only to access to SIM/USIM data.
Standardised protocols for allowing the download of content description pages and scripts in the platform.

10 Access dependent services and features p. 25

This section describes the features that will be dependent on the mode of radio access.

In general different access networks provide different capabilities with different QoS.

Multicall, as specified in TS 22.135, is supported only via UTRAN.
Packet switched traffic using GPRS over GERAN will have a maximum rate in the order of 384kb/sec.
Packet switched traffic using UTRAN will have a maximum rate in the order of 2Mb/sec.
Packet switched traffic using HSDPA provides very high speed downlink packet access over the air interface supporting streaming, interactive and background packet data services etc. HSDPA will support packet data services in urban environments and indoor environments. However HSDPA service support is not be limited to these environments. HSDPA will be optimised at speeds typical of urban environments but shall apply at other speeds also. Full mobility will be supported, i.e., mobility should be supported for high-speed cases also, but optimisation should be for low-speed to medium-speed scenarios.
ASCI teleservices, TS 22.003 are only available in GERAN A/Gb mode of operation.
SoLSA feature is only available in GERAN A/Gb mode of operation.
The accuracy of the determination of location may differ between the various access technologies.
At GERAN reception of CBS messages for a UE is not supported if it is connected in the CS domain or in the PS domain when data is currently transmitted.
Transparent (T) mode of facsimile , as specified in TS 22.003, is only supported by GERAN A/Gb mode of operation.
Non-transparent (NT) mode of facsimile, as specified in TS 22.003, is only supported by UTRAN.
There are some differences at data rates and interworking scenarios between GERAN and UTRAN support of circuit bearer services . For further details see TS 22.002.

11 Certificates p. 26

Certificates may be used for a global scale authorization infrastructure for various applications and services based on the 3GPP system security architecture. Services may be provided by parties that are not necessarily trusted by the cellular operators nor by cellular subscribers. Therefore technical means to securely deliver and authenticate services from other parties are necessary. For 3GPP, only the certificates issued by operators are relevant. There are two types of such certificates: subscriber certificates are issued to cellular subscribers and operator CA certificates are self-signed or issued to other operators. Issuing subscriber certificates allows operators to offer authorization and accounting of other services. Operator CA certificates obtained via a trusted channel can be used as root certificates.

In addition to these certificates, there are other types of certificates. For example, service provider certificates (provided by service providers), and third party certificates (provided by third parties, e.g. Value Added Service Providers) etc. These certificates are described and standardized by other fora such as IETF PKIX working group and WAP forum.

Authorization of such services may be based on credentials like digital signatures. The service provider and the network operator shall use subscriber certificates to verify these credentials. The UE may also use operator CA certificates and other certificates to verify the credentials supplied by service providers and third parties. Operator-issued certificates in 3GPP must be such that they are compatible with other systems that allow the storage, selection, and use of certificates (e.g., WAP, LCS).

Example usage scenarios of the subscriber certificate feature are payment via subscriber phone bill and location information offered by the operator to other service providers. It should be noted that the service using this feature may be outside of scope of 3GPP or implemented using existing 3GPP toolkits.

The 3GPP system shall provide support for issuing certificates to the UE over the authenticated network connection. This feature shall be based on existing 3GPP system security principles and mechanisms as far as possible. The certificate management procedures must be authenticated and integrity-protected. It shall be possible to issue certificates for service usage both in the home and visited networks. It should be possible for the home operator to exercise control over service usage in the visited network.

For further information on certificates see TS 33.102.