TS 22.057
MExE —
Mobile Execution Environment –
Stage 1

3GPP‑Page ETSI‑search CONTENT_↓

V18.0.1 (PDF) 2024/03 … p.

V17.0.0 2022/03 25 p.

V16.0.0 2020/06 25 p.

V15.0.0 2018/06 25 p.

V14.0.0 2017/03 25 p.

V13.0.0 2016/01 25 p.

V12.0.0 2014/10 24 p.

V11.0.0 2012/09 24 p.

V10.0.0 2011/04 25 p.

V9.0.0 2009/12 24 p.

V8.0.0 2009/01 24 p.

V7.0.0 2007/06 24 p.

V6.0.0 2004/12 24 p.

V5.4.0 2002/07 24 p.

V4.1.0 2002/03 26 p.

V3.0.1 1999/10 21 p.

GSM Rel-98 v7.1.0 1999/06 21 p.

Rapporteur:: Dr. Scarrone, Enrico
TELECOM ITALIA S.p.A.

Content for TS 22.057 Word version: 18.0.1

1 Scope p. 5

This TS defines the stage one description of the Mobile Execution Environment (MExE). Stage one is an overall service description, primarily from the subscriber's and service providers' points of view, and does not deal with the details of the human interface itself.

This 3GPP TS includes information applicable to network operators, service providers and terminal, switch and database manufacturers.

This 3GPP TS contains the core requirements for a Mobile Execution Environment (MExE) which are sufficient to provide a complete service.

It is highly desirable however, that technical solutions for a Mobile Execution Environment (MExE) should be sufficiently flexible to allow for possible enhancements. Additional functionalities not documented in this 3GPP TS may implement requirements which are considered outside the scope of this 3GPP TS. This additional functionality may be on a network-wide basis, nation-wide basis or particular to a group of users. Such additional functionality shall not compromise conformance to the core requirements of the service.

Reproduction of 3GPP TS 22.057, Fig. 1: Scope of this 3GPP TS

Figure 1: Scope of this 3GPP TS

As indicated in Figure 1, the scope of this 3GPP TS encompasses the MExE functionality in the UE, interaction with the MExE service environment. The MExE service environment is not necessarily restricted to the PLMN, and nodes providing MExE services (i.e. MExE servers) may also exist outside the PLMN. Aspects of the support provided by MExE servers within the MExE service environment (such as charging aspects, security level classification etc.) are covered by this specification, but not the MExE servers themselves.

2 References p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

3 Definitions and abbreviations p. 6

3.1 Definitions p. 6

For the purposes of this 3GPP TS the following definitions apply:

applet:

a small programme that is intended not to be run on its own, but rather to be embedded inside another application

application:

MExE information in the form of software, scripts, applications, associated resources (e.g. libraries) and/or data

content:

data and/or information associated with, or independent of, a particular application which may be presented to or collected from a user

MExE Classmark:

a MExE Classmark identifies a category of MExE UE supporting MExE functionality with a minimum level of processing, memory, display and interactive capabilities. Several MExE Classmarks may be defined to differentiate between the functionalities offered by different MExE UE's. A MExE executable defined as being of a specific MExE Classmark indicates that it is supportable by a MExE UE of that Classmark.

MExE server:

a node supporting MExE services in the MExE service environment

MExE service:

a service enhanced (or made possible) by MExE technology

MExE service environment:

Depending on the configuration of the PLMN, the operator may be able to offer support to MExE services in various ways. Examples of possible sources are from traditional 3GPP network nodes, IN nodes, operator-specific nodes, operator-franchised nodes and services provider nodes, together with access to nodes external (i.e. vendor-specific) to the PLMN depending on the nature of the MExE service. These nodes are considered to constitute the MExE service environment. The MExE service environment shall support direct MExE UE to MExE UE interaction of MExE services.

MExE service provider:

an organisation which delivers MExE services to the subscriber. This is normally the PLMN operator, but could be an organisation with MExE responsibility (which may have been delegated by the PLMN operator).

MExE subscriber:

the owner of a subscription who has entered into an agreement with a MExE service provider for MExE services. Access to MExE services though other types of networks is out of scope of this specification.

subscriber:

the term subscriber in the context of this 3GPP TS refers to a MExE subscriber

user:

the user of an MExE UE , who may or may not be the subscriber.

3.2 Abbreviations p. 6

For the purposes of this 3GPP TS the following abbreviations apply:

API

Application Programming Interface

Circuit Switched

FFS

For Further Study

Intelligent Network

Mobile Equipment

MExE

Mobile Execution Environment

MMI

Man Machine Interface

UENO

Network Operator

PLMN

Public Land Mobile Network

SIM

Subscriber Identity Module

User Equipment

USIM

Universal Subscriber Identity Module

Service Provider

Further related abbreviations are given in TR 21.905.

4 Description p. 7

MExE provides a standardised execution environment in an UE, and an ability to negotiate its supported capabilities with a MExE service provider, allowing applications to be developed independently of any UE platform. The UE (consisting of the ME and SIM/USIM) can then be targeted at a range of implementations for MExE from small devices with low bandwidth, limited displays, low processor speeds, limited memory, MMI etc., to sophisticated with a complete MExE execution environment.

The introduction of MExE execution environment into UE's is a significant step forward in their evolution. The ability of UE's to support MExE executables represents an extension of UE's capabilities. In order to allow current and future technologies to exploit and benefit from this, a standardised means of negotiating the UE's and network's capabilities is supported. This negotiation will permit the mutual exchange of capabilities between the UE and the MExE server, and possibly include the service profile of the user and capabilities of the network. The negotiation may take place at service initiation, or on a dynamic basis.

A network can be a transport bearer for the negotiation, interaction and transferring of applications, applets and content with the UE, however it need not necessarily be the provider of the MExE services with which the UE's execution environment is interacting with. The network may also be the intermediary between two UE's which are engaged in a MExE service with each other, with the network effectively supplying the "pipe" and not playing a MExE role in the connection.

Network nodes, nodes external to the network, or even UE's may be the entities which interact with the UE's execution environment.

5 Compatibility of MExE UE's and applications p. 7

5.1 MExE classmarks p. 7

Given the wide ranging hardware capabilities of MExE UE's, together with the development of MExE executables, a MExE classification shall be supported to determine their respective capability and compatibility. The MExE classification shall apply both to UE's, and MExE executables.

The objective is to:

classify the capabilities of a MExE UE to support MExE executables; and
identify the class of MExE UE on which a MExE executable may be supported.

The concept of a MExE Classmark is introduced to manage the MExE UE and MExE executable classification and compatibility. The MExE Classmark is distinct and unrelated to the existing UE Classmark. The use of MExE Classmarks shall be supported during the capability negotiation between the MExE service provider and the MExE UE.

5.2 UE MExE classmarks p. 7

A given MExE Classmark shall identify a category of MExE UE supporting MExE functionality with a minimum level of processing, memory, display and interactive capabilities.

Specification of different MExE Classmarks enables use of a variety of technologies to support MExE functionality.

A given MExE Classmark identifies support by a MExE UE for a defined level of MExE functionality. This does not necessarily imply support of other MExE Classmarks. A MExE UE may support multiple MExE Classmarks.

The minimum level of capabilities for each MExE Classmark is beyond the scope of this Stage 1 service description. As UE development evolves and more sophisticated devices (or indeed simpler devices) become available, further UE MExE Classmarks shall be definable to identify UE's capable of supporting improved (or additional) MExE functionality.

A given MExE UE Classmark identifies support by a MExE UE for a defined level of MExE functionality, but does not necessarily imply support of other levels of MExE Classmark. A MExE UE may also support multiple MExE Classmarks.

5.3 MExE executables and MExE classmarks p. 8

MExE executables will be developed to execute in one or more classes of MExE UE's. In order for MExE executables to be properly supported by a MExE UE, the MExE executable shall identify the minimum functional capabilities required of a MExE UE, as defined by the UE's MExE Classmark.

MExE executables shall be designated by the same classes of MExE UE's on which they may be executed. Examples of the classification of MExE executables are as follows:-

a MExE executable can be defined as a MExE Classmark 1 application;
the application is identified as suitable for execution on MExE Classmark 1 UE's only.
a MExE executable can be defined as a MExE Classmark 2 application;
the application is identified as suitable for execution on MExE Classmark 2 MS's only.
a MExE executable can be defined as a MExE Classmark 1 and Classmark 2 application;
the application is identified as suitable for execution on MExE Classmark 1 and Classmark 2 UE's only.

The above example list is neither complete nor exhaustive.

If a MExE executable is capable of being supported by other classes of MExE UE's (with reduced or enhanced capabilities), it is the responsibility of the MExE service provider to re-classify the MExE executable accordingly.

MExE executables defined by a MExE service provider to a given class of MExE UE, shall be supportable by all MExE UE's of that class regardless of MExE UE manufacturer. MExE executables shall operate on differing MExE UE of the same MExE UE class without modification.

It shall be possible for MExE service providers to make the same MExE executables available in the network for different classes of MExE UE. It is desirable that MexE executables are backward compatible within a given technology and for a given UE Classmark; however such backward compatibility is out of scope of this specification.

6 General MExE requirements p. 8

6.1 High level MExE requirements p. 8

The high level requirements of MExE are as follows:

the means for MExE service provider specific services to be supported by all UE's of a particular class (i.e. the need for a common set of APIs and development tools), and accessible across a range of networks;
provide the user with a more sophisticated user interfaces (e.g. browser-like) with a rich variety of MMI concepts to control and invoke services (i.e. softkeys, icons, voice recognition etc.);
the user's and MExE service providers capability to control the "look and feel" of applications and applets;
the ability of the user to personalise the user interface;
the ability of the user to personalise services and individual media components of a multimedia service;
provide support of a wide variety of applications and applets;
provide the means for MExE service providers to authenticate MExE subscribers;
provide the user access to Internet and Intranet based applications and applets (via both standard Internet and Wireless optimised protocols);
the means to transfer applications, applets and content automatically or on demand to a MExE UE from a MExE service provider, and upgrade existing applications across the network;
the means to support direct MExE UE to MExE UE interaction of MExE services;
the need for an inherent security architecture such that both the MExE UE and MExE server sides of a connection are authenticated (possibly by a brokerage server), and have access to a range of encryption and security functions in order to maintain the security and integrity of the network. The MExE service provider shall maintain security of subscribers personal data and network data, with all aspects relating to network security being centred on the SIM/USIM;
the ability for the MExE service provider to charge subscribers for MExE service provider provided MExE services, at connect time, when downloading, or on usage;
the means for MExE service provider specific applications and applets on the MExE UE to communicate with applications in the MExE service environment using industry standard protocols (e.g. a MExE server etc);
the ability to provide information to MExE service providers (e.g. location information of UE for use with location dependent services);
the means for MExE service providers and their applications and applets to determine MExE UE capabilities (i.e. MExE Classmark, technology, supported bearers according to network capabilities and network subscription etc.). (This shall be used by MExE servers to adapt application and applet transfer to MExE UE capabilities, and shall be used by applications and applets whilst running to adapt their behaviour to the UE's capabilities.);
the opportunity for MExE service providers to apply expertise and software developed for other platforms;
provision of APIs and tools to develop MExE services which are applicable for MExE UE;
the means for the user to manage (i.e. identify version, delete, modify, save etc.) the applications, applets and content on the MExE UE;
the means for the user to control acceptance (i.e. by Security Level, level of trust etc.) of applications, applets and content transferred to the MExE UE. (It shall be possible for the user to finely control a trusted application or applet's access rights on the MExE UE, such as reading/writing/deletion of files stored on the MExE UE);
the means for MExE executables to perform some AT command functionality without compromise to security of MExE as defined in clause 8;
the means for authentication certificates associated with applications to be managed and stored in the SIM/USIM;
the ability for a MExE executable to negotiate the QoS, and the ability to indicate to a MExE executable changes in the QoS;
the ability of MExE executables to be notified that handover is about to occur, is occurring or has occurred;
the means for MExE UE manufacturers to download and upgrade their existing codec in a MExE UE. A generic mechanism to download other proprietary software into the execution environment of the UE shall be available to the manufacturer. The downloading of platform independent MExE executables, such as streaming audio, that support multimedia capabilities shall also be possible;
the means for data to be synchronised between the MExE UE and the MExE service environment;
the ability to support IP multimedia services;
the ability to discover services offered by the Home Environment, valued added service providers with associated with the Home Environment, and third parties.

Some of the above requirements are subsequently elaborated.

6.2 Requirements description from the user's standpoint p. 10

MExE provides an improvement in the capabilities of a UE, as well as an extended range of services available to the user from, or via, the network. The user shall have

user interface configuration management; and
service management;

of the services offered to him by MExE.

6.2.1 User interface configuration management p. 10

User interface configuration management refers to the behaviour of the MExE UE, and the ability of the user to modify the MExE UE to behave in the manner he is accustomed to, or wishes the MExE UE to, present itself to the user. It does not refer to the services which interact with the network, but the way in which the MExE UE interacts with the user.

Users expect MExE UE's to offer an increasing range of capabilities which need not be ubiquitously present on each MExE UE, depending on the technological limitations of the MExE UE. The user shall be able to manage the user interface configuration of the MExE UE. For example, some user's may require a voice-controlled MMI, whilst others may have the need for a specialised presentation on the MExE UE display or preset function keys regardless of the application or applet which is running. Management of the user interface configuration will permit a user to move from MExE UE to MExE UE and exploit the technological capabilities of each class of MExE UE, with the use of varying services downloaded from the network, as required.

The user shall be able to identify (either directly or indirectly) the user interface configuration he wishes to add, modify or delete on his MExE UE, and shall be offered the means of doing this. This management may be performed, for example, by a configuration capability profile.

In taking this action, it shall be possible to determine whether the user interface configuration is already resident on the ME, or whether it requires to be obtained from the SIM/USIM or the network. The modifications which may be requested by the user could result in, for example, differing display characteristics being employed, redefinition of keys, modification of the "look and feel" of the user interface, touch screen facility, extensions to existing functions or the capability to automate some functions.

The control of the "look and feel" of MExE executables to customise their level of functionality and appearance may be possible by the MExE service provider, network operator (where the MExE service provider is not the network operator) and the user. The aspects of the application or applet which may be customisable are determined by the MExE service provider as an integral part of the MExE executable.

The user interface configuration management which is specific to the ME shall be stored on the ME, and user interface configuration management which is generic to ME's may be stored in the network or on the SIM/USIM.

The definition of the user interface configuration management which may be offered to the user is outside the scope of this service description.

6.2.2 Service management p. 10

MExE shall provide the ability to customise the range of services offered to the subscriber. The subscriber's ability to configure the services available on the MExE UE shall be dynamic, as the range of services required may differ depending on the network, time and location that the user finds himself in. For example, a subscriber may require access to services offering financial support when attending a business meeting, however later in the day he may need access to travel information and booking facilities when re-arranging his travel home.

MExE shall be able to support the handling of individual media components of an IP multimedia service in a user profile, and not necessarily handle all media components of a multimedia session in the same way.

A common address across all PLMN supporting MExE shall be available, from which the user shall be able to request the range of MExE services available he is registered in, if the PLMN supports MExE. The downloading of services may be autonomously controlled by the MExE UE to update existing service access on the MExE UE, or to download new services. The management of these services may be defined by the subscriber directly or under the control of the MExE UE's capabilities organised on the MExE UE (i.e. a user may be particularly interested in unified messaging services, and require the availability of such services to be made available to him).

The user shall be able to determine and manage which MExE executables and content may be transferred to the MExE UE (i.e. in terms of their security level, source of the applications etc.), determine and manage which MExE executables and content are currently resident and usable on the MExE UE (e.g. when roaming some services may not be available to the user), and delete MExE executables and content on the MExE UE.

The definition of the applications, applets and content which may be offered to the user is outside the scope of this specification.

6.3 Requirements description from the MExE service provider's standpoint p. 11

6.3.1 Transfer of applications, applets and content p. 11

A common mechanism shall be available to perform the transfer of applications, applets and content between MExE UE's' and the MExE service provider.

The common transfer mechanism shall permit applications, applets and content (according to the appropriate MExE Security Level) to be transferred to the MExE UE.

It shall be possible for the MExE service provider to:

transfer applications, applets and content between the MExE UE and the MExE service provider (which may be initiated by either party);
request the version of applications, applets and content on the MExE UE;
identify the MExE UE' capabilities;
support a request from the MExE UE for information on the (local) services which may be transferred from the network.

Some of these functions may be used by the MExE service provider either individually, or together to automatically update previously transferred services.

6.3.2 Node types p. 11

The introduction of MExE shall enable an expansion of services available to the user from various network node types.

The MExE UE shall be able to communicate with the various network node types in the MExE service environment, allowing access to intelligent nodes to process service requests from the MExE UE.

Applications in the MExE service environment may interact with, or execute as agents of, an MExE UE application using industry standard protocols. Such interaction does not fall within the scope of MExE, however any MExE UE application that does interact with applications in the MExE service environment must respect the privacy of user data.

6.3.3 Subscriber data p. 11

Subscription to MExE services shall be logically separate to subscription of network services. A subscriber may have a MExE subscription to multiple MExE service providers. It may also be possible for the subscriber to interrogate such subscription registration (with a suitable means of authorisation), depending on PLMN support.

6.3.4 Roaming subscribers p. 12

Roaming MExE subscribers shall be able, as far as possible, to access their normal MExE services in their HPLMN.

As usual when roaming, it cannot be ensured that the VPLMN can provide the subscriber access to the same MExE services (e.g. applications, applets and content) as he is accustomed to. However, in the VPLMN additional MExE services may be available, depending on network capabilities. Service continuity when roaming is dependent on the availability of the services in the VPLMN, and is outside the scope of this specification.

The operation of the transferred applications, applets and content may be location dependent, and their behaviour when in an different location is outside the scope of this specification.

The following forms of MExE subscriber roaming are identified:-

roaming between networks (HPLMN to VPLMN);
roaming between visited networks (VPLMN to VPLMN);
regional roaming within a network (within the HPLMN or VPLMN).

There may be a need to distinguish between the above types of roaming from a MExE services management perspective, as the operation of location dependent MExE services may be affected when the MExE subscriber roams beyond the boundaries of a PLMN or region.

7 MExE bearer requirements p. 12

Bearers available to MExE executables depend on those supported by the MExE UE that are available.

Wherever available, MExE UE applications shall be supported by bearers from 3GPP system and other technologies (e.g. circuit switched, packet switched, high speed data links provided by digital broadcast infrastructure). MExE executables shall be able to use these bearers in an asymmetric fashion.

8 MExE protocols requirements p. 12

In order for MExE to be supported over the network, a set of standardised protocols is required to support interaction between the MExE UE and the MExE service environment.

As this specification is not required to propose a specific technology, it identifies the MExE protocols requirements from the service subscriber's and user's standpoint. The MExE protocols refers to any protocol layer above the 3GPP system bearers, which interfaces between the MExE service environment and the MExE UE.

The functional capabilities, information flows, signalling system protocols and switching functions needed to implement the service described in this Stage 1 specification will be identified by subsequent specifications at the Stage 2 and Stage 3 levels.

The high level MExE protocols requirements are identified in the subsequent subclauses.

8.1 Optimised Wireless Access p. 12

A primary goal of MExE is to provide access to Internet and Intranet services, the standard Internet applications, security and transport protocols shall be one possible set of MExE protocols which is supported. It is noted that these protocols may not cover all the requirements identified in this specification for all classes of ME's.

A set of application, security and transport protocols optimised for wireless access, and compliant to MExE requirements, shall be specified and form part of the MExE standards.

MExE UE's shall be able to support either or both of these sets of protocols.

8.2 Wireless network independence p. 13

The upper layers of the MExE protocols shall be independent of the type of underlying wireless network so that applications and applets do not need to take into account the specific nature of networks. In particular, lower layers shall provide a generic access API to network bearers so that application and applet developers do not have to cater for the supported underlying bearers. It shall be possible for applications and applets to request specific bearer services and be notified accordingly if they are not available.

The transport layer of the MExE protocols may however be adapted to support the specific features of the underlying bearers. The MExE protocols shall have the ability to use all the underlying bearer services which the MExE UE is capable of supporting.

8.3 Scaleable and extendible protocols p. 13

The MExE protocols shall support a scaleable and extendible environment for application and applet development in mobile communication devices. It shall provide a set of generic, non-UE or service-dependent, features. Saleability of the MExE protocols applies to both the MExE UE (e.g. where simple devices do not require the extensive protocols support possibly required by more sophisticated devices) and the network.

The MExE protocols shall support both low bandwidth bearers (e.g. SUE, USSD etc.) as well as medium bandwidth bearers (e.g. anything up to 64kb/s). The introduction of new bearers shall be supported, allowing applications and applets to automatically benefit from their capabilities.

The MExE protocols shall support existing servers and applications and applets, and provide a stable platform for future application development.

8.4 Service independence p. 13

The MExE protocols shall be independent of the services communicated over the protocols. The modification in the range of services, or addition of new services, offered over the network shall not be restricted by the MExE protocols.

8.5 Network node type independence p. 13

The MExE protocols shall be independent of the network node type(s) being communicated with over the protocols. The MExE protocols shall support the evolution of network node types in a PLMN.

8.6 Enquiry and notification of MExE capabilities p. 13

The MExE protocols shall support a generic technology-independent means for the notification by the MExE UE to a MExE server, or enquiry from the MExE server to the MExE UE, of the supported MExE capabilities consisting of:

MExE Classmark (mandatory, MExE server to MExE UE);
the supported class of MExE UE;
MExE technology (mandatory, MExE server to MExE UE);
the supported types of MExE UE technology to support MExE services;
terminal characteristics (optional, MExE UE from MExE server, following MExE server enquiry);
further details of the supportable characteristics (i.e. screen size, MMI capabilities, supportable bearer services, toolkits etc. as constrained by the network, terminal, subscription and user preferences).

In existing networks it may not be possible to determine the network capabilities (i.e. supported bearers) and subscription options of the subscriber.

The above notification by the MExE UE or the MExE server are supported at service initiation, dynamically during the provision of such a service, and following a change in the quality of service (i.e. following a handover, change of network, degradation of service, change in quality of service).

The notification mechanism shall flexibly support notification of the MExE UE, and be able to accommodate future evolution of MExE UE equipment.

8.7 UE request of services information p. 14

The MExE protocols shall support a notification from the PLMN or a request from the MExE UE to the PLMN, for information on the (local) services which may be transferred from the PLMN. The information from the PLMN may take the form of listing the services, or references to a PLMN entity (either internal or external to the PLMN) where the available services may be determined.

8.8 Support of transfer protocols p. 14

The MExE protocols shall support the capability to transfer new applications and applets to the MExE UE as required. The protocols shall support both user initiated and MExE server initiated transfer of several types of data (content description pages, procedural logic, images, libraries etc.), and be able to indicate the type of data being transferred.

Each specific MExE technology shall be support a standardised transfer mechanism for that MExE technology.

9 UE application execution environment requirements p. 14

9.1 UE platform independence p. 14

In order to support the objectives of MExE, the ME and SIM/USIM is required to have an architecture capable of supporting applications, applets and content in a standardised execution environment, independently of the MExE UE manufacturer.

As this specification is not required to propose a specific technology, it identifies the common platform requirements from the service subscriber's and user's standpoint.

The limitations of small devices may result in the provision of the full application execution environment only being available in sophisticated devices.

The high level execution environment requirements are identified in the subsequent subclauses.

9.2 Document mark-up language and other coding formats p. 14

In order to cater for a wide variety of ME's with different display and input capabilities, support for both the standard Internet mark-up language and a content description language optimised for small display devices of low bandwidth bearers shall be defined with the MExE specifications. Both languages may be implemented on any MExE UE. Standardised ways of coding content (i.e. images, phonebook, calendar etc.) shall be defined, however the support of such standardised content coding is optional.

In order to facilitate global use of MExE services, a standardised range of character sets for MExE services requires to be defined, and the capabilities of the user and applications to use them.

9.3 MExE APIs p. 14

MExE APIs may be defined covering aspects (e.g. Network APIs, Non-network API's, Terminal APIs etc.) within a given MExE Classmark of MExE UE (ME an/or SIM/USIM), and the MExE UE shall support a core API to support the execution of MExE executables. The core API is a the minimal set of API that is present on all MExE UE's, providing the MExE execution environment in which applications and applets can execute, and is known as the Core MExE API. The Core MExE API consists of generic and 3GPP specific aspects.

Applications and applets which have been designed to execute in this Core MExE API environment (and the optional MExE APIs subsequently identified), will provide additional functions to the MExE UE.

In addition to the Core MExE API on an MExE UE, standardised MExE API extensions such as Network API (e.g. access to session control services, SUE etc.), Non-network 3GPP-defined services API (e.g. security aspects, SIM/USIM phonebook etc.), Terminal API (e.g. power management, access to alerting function, phonebook, MMI, smartcard access etc.),shall be subsequently defined and may be supported by the MExE UE in order to further exploit the system capabilities.

The standardised MExE API extensions shall include access to mobility information.

10 Charging requirements p. 15

The use of MExE services shall, at MExE service provider determination, be subject to charging.

There are several forms of charging which shall be available to the MExE service provider. It shall be possible for the MExE service provider to charge in the following instances:

subscription;
the subscriber's registration to use MExE services may be subject to a charge;
service transfer;
the transfer of services and/or information to a subscriber's MExE UE may be subject to a charge;
service upgrading;
the upgrading of previously transferred services to a subscriber's MExE UE may be subject to a charge (automated upgrading of services may be subject to a different charge);
service usage;
the usage of transferred services by a subscriber's MExE UE may be subject to a charge (possibly use either internal to, or external to, the MExE UE);
roaming ;
the usage of MExE services by a subscriber's MExE UE when roaming may be subject to additional charges;

A standardised means of transferring (indicative and/or final) charging information (for the use of MExE services) from the MExE service provider to the MExE UE shall be defined.

The usage of the bearer service may be subject to a charge (i.e. possibly time-based, volume-based, event-based etc.) by the network operator.

Normal service charges may additionally apply when using MExE services and incurring the above charges.

Other charging requirements may be identified in due course.

11 Security requirements p. 15

This clause consists of:

a sub-clause giving the principles behind security for MExE. These are not requirements as such but the principles behind the requirements;
a sub clause specifying specific requirements that MExE implementations must adhere to;
a sub-clause specifying the security domain classifications for MExE executables.

11.1 Security Principles p. 16

The ME and the data therein are the property of the user. The user is also responsible for the payment of chargeable events involving her UE, and will be seen as the party responsible for any events (whether chargeable or not) involving her UE. Therefore the user shall have full control over all chargeable and non-chargeable events initiated by her UE ("event" includes responses made by the UE to external events, e.g. the acceptance by the UE of an incoming session). This control can be exercised either by the giving of explicit permission at the time of the event or by the giving of implicit permission to the events by the agreement to an event schedule listed clearly in a user profile.

The user shall be able to request the logging of specific network events initiated by MExE UE applications/applets.

The privacy of user data in the UE is of paramount importance.

The SIM/USIM and operator controlled areas within the terminal are the property of the network operator. The network operator shall therefore have full control over access to the SIM/USIM and operator controlled area The operator shall also have full control over data, excluding personal user data, transmitted to or from the SIM/USIM and the operator controlled terminal area and all events initiated by the SIM/USIM or operator controlled area ("event" includes responses made to external events, e.g. the response to a command sent from the ME).

As the user cannot know the capabilities of any MExE executables transferred from a MExE service environment before transfer, the UE MExE environment shall ensure that transferred MExE executables cannot compromise the above principles.

11.2 Security Requirements p. 16

For MExE executables of security operator, manufacturer and user trusted domains , as defined in clause 11.3, it shall be possible to authenticate the identity of the body that authorised the application, applet or content.

There shall be a secure, unforgable means for assigning the security domains defined in section 11.3 to the MExE executables transferable from the MExE service environment.

The certification of authorisation associated with MExE executables transferable from the MExE service environment shall be transferred with the certified material.

The MExE UE shall be able to verify the security domain, as defined in section 11.3, of MExE executables transferred from the MExE service environment.

The verification process in the UE itself shall not compromise the security of the functionality and content in the UE

Transferred material that fails verification shall not be installed and shall be deleted by the terminal as soon as possible.

MExE executables that cannot be verified due to the absence of required verification information in the UE, shall be considered as untrusted material, as defined in section 11.3.

The events that MExE executables are given permission by the user to initiate shall be securely recorded in the user profile.

There shall be mechanisms within the MExE UE for ensuring that applications cannot have access to UE functionality and content beyond that allowed by their security domain, as defined in section 11.3.

It shall be possible to for the user to downgrade MExE executables of operator, manufacturer or user trusted domain status to untrusted status, at installation or at any other time.

The MExE UE shall be able to detect if MExE executables transferred from the MExE service environment have been modified since they were assigned a security level.

MExE executables shall not be transferred to a MExE UE without the explicit permission of the UE user immediately prior to transfer or implicit permission via the user profile.

Applications and applets transferred to a MExE UE shall not be able to initiate events without the explicit permission of the UE user immediately prior to event initiation or implicit permission via the user profile.

The user profile data for transfer and event initiation cannot be changed without the explicit agreement of the user.

The user shall be able to abort or suspend any on-going session that has been set up automatically by an application.

The integrity of the SIM or USIM and other security mechanisms shall not be compromised by the introduction of MExE services.

The user shall be able to request the logging of specific network events initiated by MExE UE applications/applets.

MExE UE applications/applets shall not be able to send command RUN GSM ALGORITHM to the SIM.

11.3 Security domain classifications p. 17

The security domain of MExE executables shall be graded according to the measure of authorisation which they have been designated. The following 3 (the "sandbox" in which untrusted MExE executables runs is not considered to be a domain) domains shall be supported for MExE executables:

MExE Security Operator Domain (used by the HPLMN operator);
MExE executables designated at this security domain have been authorised by the network operator (i.e. HPLMN),
MExE Security Manufacturer Domain (system MExE executables);
MExE executables designated at this security domain have been authorised by the MExE UE manufacturer.
MExE Security User Trusted Domain (trusted applications, applets and content);
MExE executables MExE executables designated at this security domain have been written by user trusted software developers and verified as user trusted domain material (but not with regard to their content) via organisations such as certification authorities.
MExE Security Untrusted (untrusted applications, applets and content);
Untrusted MExE executables have not been supplied with an associated authorisation, or the authorisation cannot be verified due to the absence of required verification information in the MExE UE.

12 Interworking with other network features p. 17

All services available in the network shall continue to be offered in addition to MExE. This includes the basic services, supplementary services and network features.

It shall be network-determined whether specific MExE services supplement, co-operate with, or supersede the network available services, when a user is subscribed to MExE and has transferred the specific MExE service.

The interworking characteristics of individual MExE services with other network features is outside the scope of this specification.

13 Network interworking p. 17

All services offered in co-operation with other networks shall continue to be offered in combination with MExE. This includes the basic services, supplementary services and network features.

The interworking characteristics of individual MExE services with other networks is outside the scope of this specification.

A Example MExE services p. 18

Overview

In addition to the use of standardised network services (e.g. call forwarding, call barring, CCBS, call diversion etc.), MExE provides additional capabilities to control telephony events and manipulate standardised network services in a user-friendly manner.

A MExE handset provides the generic capability to negotiate and interact with services (in the form of applications and content) in servers, other handsets and internet/intranet WebPages etc. Further, MExE provides standardised execution environments to which 3rd party software developers may write services to execute directly in the MExE handsets.

MExE provides the user with a more sophisticated user interfaces (e.g. browsers) with a rich variety of MMI concepts to personalise, control and invoke services (e.g.. softkeys, icons, voice recognition etc.). Additionally downloaded services provide users with the capability to control the "look and feel" of services.

MExE also brings security to the support of 3rd party services in the wireless handset. With security domains reserved for network operators, handset manufacturers, and third parties , the source and content of downloaded services may be authenticated by the MExE client. The provision of such a security model enables the user to control whether services are installed, configure which functions may be performed by services, and to identify the extent of permissions granted to services. The protection of user data and resources help prevent attacks from potentially fraudulent services.

This annex gives an overview of how new 3rd generation services may be supported by MExE handsets, and gives some examples of possible services that may be supported on them. The ability to support some services may depend on the physical handset resources available to the MExE services, the classmark of the MExE client, and handset manufacturers may provide a range of handsets aimed at supporting different types of services.

Access to MExE services

There are several ways in which these new 3rd generation MExE services may be supported, and the following scenarios give an overview of the possible scenarios.

services execute on remote servers

The services are provisioned and execute on remote servers, WebPages etc., to which the MExE client establishes a connection. The MExE client uses the services as provided by those remote servers. The MExE client effectively receives content (i.e. secured personal financial information) from the remote application which is presented to the user in the MExE client.
application downloaded into the MExE client

The services are provisioned and execute on remote servers, to which the MExE client establishes a connection. The MExE client downloads an application which acts as a local browser to interact with the remotely provided service. The user interacts with and uses the remote servers via the downloaded application. An example of such a service would be access to an internet/intranet page.
service downloaded into the MExE handset

The services are available from remote servers, to which the MExE client establishes a connection. The MExE user downloads whichever services he desires from the remote servers, and installs, provisions and configures them on the MExE client. These services execute directly on the handset, without necessarily relying on servers to support the service. An example of such a service would be a game.
MExE handset to MExE handset services

MExE handsets may wish to establish connections with each other to provide, receive and use interactive services. This direct MExE client to MExE client interaction of MExE services and any combination of the preceding scenarios may have been used to download services to the MExE client. These services may execute directly on the handset, without necessarily relying on servers to support the service. An example of such a service would be interactive games, sharing of calendar information, etc..

Example MExE services

Once they have been downloaded, these MExE services may then be configured, personalised and executed on the MExE handset by the user. A MExE handset may support a diverse range of services, providing a dynamic and evolutionary set of facilities to users. The support of this unlimited range of new services, will convert a mobile handset from being a device which simply makes and receives calls and messages, into a multifunctional leisure and business device.

An analogy may be made with a personal computer, where the user can install and configure any type of application that he so chooses, establish multimedia call sessions, and convert the laptop into a multi-faceted device (e.g. slideshow presenter, video box, music jukebox, arcade games machine, protocol analyser, e-mail, messaging and information server etc.). In fact, MExE may simply be considered to be similar to a small computer supporting wireless telecommunications capabilities.

Manufacturers are expected to produce MExE devices with different levels of resources, memory and processing power to exploit the growing number of applications and market niches.

The list of possible services that may be supported by a MExE client is virtually unlimited, and the following are example services that could be supported by a MExE client.

Applications

Applications may be downloaded and installed on the MExE client to provide a wide range of standalone services.

The user downloads and installs the software into the MExE client, configuring and installing it as required. Examples of such applications are phonebooks, diaries, planners providing similar functionality to current popular handheld PDA devices. Likewise, games may also be downloaded and installed providing similar functionality to current popular handheld games devices and other entertainment and leisure services.

Additionally, interactive working with other devices and servers (i.e. on-line gaming, gambling, messaging etc.) could also be generically supported.

Browsers

Applications may be downloaded and installed on the MExE client to support browser functionality already experienced by many users today with personal computers. Examples of this are internet and e-mail browsers.

Web browsing

A MExE client can be used by the user as an internet/intranet web browser by downloading and installing a web browser.

Just like the internet browser on a personal computer at home or in the office, the user is able to access the internet/intranet. Similar to accessing the internet via a personal computer, the user is able to surf the web viewing pages, images, animation and download content using standard internet HTTP and HTML protocols. By interaction with the installed web browser, the user is also able to customise his web browser to present the internet/intranet to the user in his accustomed way.

E-mail

A user can convert his MExE client into an e-mail handler by downloading and installing an e-mail browser.

Working the same way as an e-mail browser on his desk bound personal computer, the user is able to send and receive messages on the move. As with existing personal computer implementations e-mails with audio, visual and textual attachments may be exchanged with an e-mail server, using the standard e-mail SMTP, POP3 and IMAP4 protocols. Directly supported by the e-mail browser on the MExE client, the user may personalise his e-mail service and manage e-mails on remote e-mail servers.

Players

Players are a specialised type of application which the user may install on the MExE client. These players enable content to presented to the user in a specific manner, depending on the content format. Audio and video players are examples of such specialised applications.

Music players

A MExE client may also be used by the user as a portable music player by downloading and installing a music player application.

Once the music player application is installed, the user is then able to download music content using popular music formats available from the internet or third party servers.

Similar to the player applications already available on the internet and personal computers today, the user may be able to play popular music formats like MP3. Further, specialised music content may also be played by downloading and installing the appropriate compliant player.

By downloading and installing a music player, the user is able to obtain functionality from the MExE client similar to current popular handheld music devices.

Video players

Similar to the music player, a MExE client may also be used by the user as a portable video player by downloading and installing an appropriate video player application.

Once the video player application is installed, the user is then able to download video content using popular music formats like MPEG4 available from the internet or third party servers.