The present document defines the stage 2 and stage 3 description of the Mobile Execution Environment (MExE). Stage 2 identifies the functional capabilities and information flows needed to support the service described in stage 1.
The present document includes information applicable to network operators, service providers and terminal, switch and database manufacturers.
The present document contains the core functions for a Mobile Execution Environment (MExE) which are sufficient to provide a complete service.
MExE uses a number of technologies to realise the requirements of the stage 1 description (TS 22.057). The present document describes how the service requirements are realised with the selected technologies. The TS is devised into clauses each covering the aspects relating to particular MExE technologies, it is intended that this specification will evolve along with the MExE technologies. A generic clause of the specification covers areas of MExE common to all technologies.
Implementation of this specification outside the UE (User Equipment) is outside the scope of this specification.
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.
For the purposes of the present document, the following terms and definitions apply:
administrator of the MExE device is the entity that has the control of the third party trusted domain, and all resources associated with the domain
best effort QoS (Quality of Service):
best effort QoS refers to the lowest of all QoS traffic classes
entity that contains the issuer's public key, identification of the issuer, identification of the signer, and possibly other relevant information
actual QoS parameter values with which the content was delivered over the lifetime of a QoS session, TS 23.107.
user of PKI certificates and/or end user system that is the subject of a certificate.
refers to the capabilities of the Java security system to allow applications, sections of code or Java classes to be assigned permissions to perform a specific set of privileged operations
key pairs are matching private and public keys
term operator as used in this specification refers to the term Home Environment, defined as "Home Environment: The home environment is responsible for enabling a user to obtain UMTS services in a consistent manner regardless of the user's location or terminal used (within the limitations of the serving network and current terminal)" in TR 21.905.
response to a QoS request, the network shall negotiate each QoS attribute to a level that is in accordance with the available network resources
certificate loaded by the user or a user application which is limited to the application that it is intended for, and is not a MExE Certificate
dataset of personal or entity attributes
Mobile Execution Environment (MExE):
is defined in detail in the present document, but the scope of MExE does not include the operating system, or the manufacturer's execution environment
consists of interfaces present in the MExE device and exposed to MExE executables
used in the realisation of MExE security domains
UE (User Equipment) that supports MExE functionality in the ME (Mobile Equipment)
is one or more applet, application, or content, which conforms to the MExE specification and may execute on any MExE device, conforming to the appropriate classmark
MExE Java VM:
this is a standard Java virtual machine used to execute MExE Java applets and applications
MExE native library:
this is a downloaded native library that can be accessed by MExE executables
node supporting MExE services in the MExE service environment
(U)SIM that is capable of storing a security certificate that is accessible using standard mechanisms
MIDP application, or "MIDlet", is one that uses only the APIs defined by the MIDP and CLDC specifications.
collection of MIDP Applications, or MIDlets packaged together and share resources within the context of a single Java Virtual Machine
owner of the MExE device
power up event:
abstract event that occurs when the MExE device is cold started (i.e. switched on)
Lifetime of PDP context, the period between the opening and closing of a network connection whose characteristics are defined by a QoS profile
comprises of a number of QoS parameters
QoS profile is requested at the beginning of a QoS session
sandbox is a safe area to run Java code. Untrusted Java code executing in a sandbox has access to only certain resources, JDK 1.1 security .
service (which may consist of an application or applet, and its related content) is a set of functions offered to a user by an organisation, and may be performed on the MExE device and/or remotely
identifier associated with a service, which could be a string, a fully qualified Java class name, a unique URI or other identifier
period between the launching of a MExE executable and its execution termination
"Signing" is the process of encrypting a hash of the data using a private key
signed JAR file:
archives of Java classes or data that contain signatures that also include a way to identify the signer in the manifest  (the Manifest contains a file which has attributes defined in it)
network will not grant a QoS greater than that subscribed
user of the MExE device
valid (U)SIM application:
identification by the MExE ME that a valid SIM card, or USIM application on the UICC, has been detected (e.g. through insertion of (U)SIM card, power up of MExE device etc.)
Further definitions specific to MExE are given in TS 22.057.
Support of at least one MExE classmark is mandatory. A MExE device may also include optional support for applications from any other MExE classmark (refer to clause 4.3"Multiple Classmark support").
This clause defines the common aspects of all MExE compliant devices, independent of MExE technology.
Considering the wide and diverse range of current and future technology and devices that (will) use wireless communication and provide services based thereon a one-size-fits-all approach is unrealistic. Instead the present document categorises devices by giving them different MExE classmarks. In this specification the following MExE classmarks are defined:
MExE classmark 1 - based on WAP (Wireless Application Protocol)  - requires limited input and output facilities (e.g. as simple as a 3 lines by 15 characters display and a numeric keypad) on the client side, and is designed to provide quick and cheap information access even over narrow and slow data connections.
MExE classmark 2 - based on PersonalJava  - provides and utilises a run-time system requiring more processing, storage, display and network resources, but supports more powerful applications and more flexible MMIs.
MExE classmark 3 - based on J2ME CLDC and MIDP environment  and  - supports Java applications running on resource-constrained devices.
Content negotiation allows for flexible choice of formats available from a server or adaptation of a service to the actual classmark of a specific client device.
Bi-directional capability negotiation between the MExE Service Environment and MExE device (including MExE classmark), supports the transfer of capabilities between the client and the server.
The following architectural model shows an example of how standardised transport mechanisms are used to transfer MExE services between the MExE device and the MExE service environment, or to support the interaction between two MExE devices executing a MExE service.
The MExE service environment could, as shown in Figure 1"Generic MExE architecture", consist of several service nodes each providing MExE services that can be transferred to the MExE device using mechanisms such as (but not limited to) fixed/mobile/cordless network protocols, Bluetooth, infrared, serial links, wireless optimised protocols, standard Internet protocols. These service nodes may exist in the circuit switched domain, packet switched domain, IP multimedia core network subsystem or in the internet space (e.g. SMS service centres, multimedia messaging servers, internet servers etc.). The MExE service environment may also include a proxy server to translate content defined in standard Internet protocols into their wireless optimised derivatives.
For the versatile support of MExE services, the wireless network shall provide the MExE device with access to a range of bearer services on the radio interface to support application control and transfer from the MExE service environment. As MExE also applies to fixed and cordless environments, MExE device may also access MExE services via non wireless access mechanisms.
Support of multiple MExE classmarks on a MExE device is optional.
A given MExE Classmark identifies support by a MExE device for a defined level of MExE functionality as defined by that classmark. Support of MExE classmarks by a MExE device shall enable flexible support of MExE functionality. A MExE device may support any multiple combinations of MExE classmarks.
The support of any other functionality by a MExE device is also possible, and is out of scope of this specification.
Support of Classmark 1 executables in non-classmark 1 MExE devices is optional.
To allow access to services designed for MExE Classmark 1 devices, MExE devices other than Classmark 1 will need to support full or a subset of WAP protocol as identified below. Due to the fast evolution of new technologies, support of WAP in Classmarks other than Classmark 1 is not mandated by MExE specification. However WAP is a possibility for the integrity of service provisioning as well as quick access to information by feature rich devices (e.g. Java devices).
If Classmark 1 services are supported by non-Classmark 1 devices, Classmark 1 services shall execute in the same manner as they execute in a MExE Classmark 1 device. For that purpose, a MExE non-Classmark 1 device shall comply with data profile class (Class C) of WAP Class Conformance Requirement Specification .
Support of Classmark 2 executables in non-classmark 2 MExE devices is optional.
If Classmark 2 services are supported by non-Classmark 2 devices, Classmark 2 services shall execute in the same manner as they execute in a MExE Classmark 2 device.
Support of Classmark 3 executables in non-classmark 3 MExE devices is optional.
If Classmark 3 services are supported by non-Classmark 3 devices, Classmark 3 services shall execute in the same manner as they execute in a MExE Classmark 3 device.
Support of Classmark 4 executables in non-classmark 4 MExE devices is optional. If Classmark 4 services are supported by non-Classmark 4 devices, Classmark 4 services shall execute in the same manner as they execute in a MExE Classmark 4 device.