Tech-invite3GPPspaceIETF RFCsSIP

Content for  TS 23.057  Word version:  17.0.0

Top   Top   None   None   Next
1…   5…


1  Scopep. 8

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.

2  Referencesp. 8

  • 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]  Void.
TS 22.057: "Mobile Execution Environment (MExE); Stage 1".
Personal Java 1.1.1 or higher: Sun Microsystems
JavaPhone API version 1.0:
[5]  Void.
Wireless Application Protocol (WAP) June 2000 Conformance Release:
[7]  Void.
[8]  Void.
RFC 2616:  Hypertext Transfer Protocol - HTTP/1.1:
[10]  Void.
TR 22.170: "Universal Mobile Telecommunications System (UMTS); Service aspects; Provision of Services in UMTS - The Virtual Home Environment".
→ to date, withdrawn by 3GPP
TS 22.121: "The Virtual Home Environment; Stage 1".
[13]  Void.
TS 22.101: "Service Aspects; Service Principles".
CC/PP Exchange Protocol based on HTTP Extension Framework; W3C
Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation:
UAProf Specification:
JDK 1.1 security:
Java 2 security:
Java security tutorial:
OCF 1.1: "Smartcard API specified by OpenCard Consortium
RFC 1738:  "Uniform Resource Locators (URL)"
The MD5 Message Digest Algorithm", Rivest, R., RFC 1321, April 1992. URL:
ISO/IEC 10118-3 (1996): "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions".
RFC 2368:  "The mailto URL scheme".
ITU-T Recommendation X.509: "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks".
TS 51.011: "Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface".
TS 23.107: "QoS Concept and Architecture".
TS 24.007: "Mobile radio interface signalling layer 3; General Aspects".
TS 24.008: "Mobile radio interface layer 3 specification, Core Network Protocols; Stage 3".
TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2".
PKCS #15: "Cryptographic Token Information Syntax Standard" version 1.1, RSA Laboratories, June 2000
RFC 2510  (1999): "Internet X.509 Public Key Infrastructure Certificate Management Protocols".
Connected Limited Device configuration, J2ME version 1.0:
Mobile Information Device Profile, J2ME version 1.0:
eXtensible Markup Language (XML) 1.0: W3C Recommendation.
Resource Definition Framework (RDF) Model and Syntax:W3C Recommendation.
UML Partners: Unified Modelling Language:
TS 31.102: "Characteristics of the USIM applications".
RFC 2396  (1998): "Uniform Resource Identifiers (URI): Generic Syntax". T. Berners-Lee, R. Fielding, L. Masinter.
RFC 2616  (1999): "Hypertext Transfer Protocol -- HTTP/1.1". R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.
Description of the "JAR Manifest" file encoding, Sun Microsystems. URL:
RFC 2459  (1999): "Internet X.509 Public Key Infrastructure Certificate and CRL Profile". R. Housley, W. Ford, W. Polk, D. Solo.
TR 21.905: Vocabulary for 3GPP Specifications.
WAP Binary XML Content Format Specification (WBXML):
RFC 1766:  "Tags for the Identification of Languages".
WAP Certificate and CRL Profiles: WAP-211-WAPCert
TS 23.227: "Applications and User interaction in the UE-Principles and specific requirements".
PKCS#1 "RSA Cryptographic Standard" version 2.0: RSA Laboratories, October 1998
Common Language Infrastructure: ECMA specification ECMA-335,
Simple Object Access Protocol version 1.1, (SOAP):
PKCS#7 "Cryptographic Message Syntax Standard" version 1.5: RSA Laboratories, November 1993
TS 23.040: "Technical realization of the Short Message Service (SMS)".

3  Definitions and abbreviationsp. 10

3.1  Definitionsp. 10

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
delivered QoS:
actual QoS parameter values with which the content was delivered over the lifetime of a QoS session, TS 23.107.
End Entity:
user of PKI certificates and/or end user system that is the subject of a certificate.
fine grain:
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 pair:
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.
negotiated QoS:
response to a QoS request, the network shall negotiate each QoS attribute to a level that is in accordance with the available network resources
personal certificate:
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
MExE certificate:
used in the realisation of MExE security domains
MExE device:
UE (User Equipment) that supports MExE functionality in the ME (Mobile Equipment)
MExE executable:
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
MExE Server:
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:
MIDP application, or "MIDlet", is one that uses only the APIs defined by the MIDP and CLDC specifications.
MIDlet suite:
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)
QoS session:
Lifetime of PDP context, the period between the opening and closing of a network connection whose characteristics are defined by a QoS profile
QoS profile:
comprises of a number of QoS parameters
requested QoS:
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 [18].
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
service name:
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 [42] (the Manifest contains a file which has attributes defined in it)
subscribed QoS:
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.

3.2  Abbreviationsp. 12

For the purposes of the present document the following abbreviations apply:
Attribute Authority
Application Programming Interface
Application protocol data unit
Administrator Root Public Key
Certification Authority
Composite Capability/Preference Profiles
Common Gateway Interface
Certificate Configuration Message
Connected Limited Device Configuration
Common Language Infrastructure
Certificate Present (in the MExE (U)SIM) - Administrator
Certificate Present (in the MExE (U)SIM) - Third Party
Certificate Revocation List
Differentiated Services
Dual Tone Multiple Frequency
Global System for Mobile Communication
General Packet Radio Service
HyperText Transfer Protocol
HyperText Transport Protocol Secure (https is http/1.1 over SSL, i.e. port 443)
Internet Engineering Task Force
Internet Protocol
Integrated Services Digital Network
Java Application Descriptor
Java 2 Micro Edition
Java 2 Standard Edition
Java Telephony Application Programming Interface
JAR file
Java Archive File
Mobile Equipment
Mobile Information Device Profile
MIDP Application
Man-Machine Interface
Manufacturer Root Public Key
MExE Service Environment
Mobile Subscriber ISDN Number
Mobile Termination
OpenCard Framework
Original Equipment Manufacturer
Online Certificate Status Protocol
Operator Root Public Key
Quality of Service
Packet Data Protocol
Public Key Infrastructure
Resource Description Format
Request For Comments
Root Public Key
Simple Certificate Verification Protocol
Subscriber Identity Module
Short Message Service
Simple Object Access Protocol
Secure Socket Layer
Terminal Equipment
Transport Layer Security
Third Party
User Datagram Protocol
User Equipment
User Interface
Universal Mobile Telecommunications System
Uniform Resource Locator
Uniform Resource Identifier
Universal Subscriber Identity Module
Unstructured Supplementary Service Data
Virtual Machine
Wireless Application Environment
Wireless Application Protocol
WAP Binary XML
Wireless Datagram Protocol
Wireless Markup Language Script
Wireless Session Protocol
Wireless Telephony Applications
Wireless Telephony Applications Interface
Wireless Transport Layer Security
Wireless Transaction Protocol
World Wide Web
Extensible Markup Language
Further abbreviations are given in TS 22.057 and TR 21.905.

4  MExE basic principlesp. 14

4.1  Generic MExE aspectsp. 14

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) [6] - 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 [3] - 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 [34] and [35] - supports Java applications running on resource-constrained devices.
  • MExE classmark 4 - based on Common Language Infrastructure [50] Compact Profile - supports CLI based applications running on a broad range of connected 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.

4.2  High level architecturep. 14

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.
Copy of original 3GPP image for 3GPP TS 23.057, Fig. 1: Generic MExE architecture
Figure 1: Generic MExE architecture
(⇒ copy of original 3GPP image)

4.3  Multiple classmark supportp. 15

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.

4.3.1  Classmark 1 service support in non-Classmark 1 MExE devicesp. 16

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 [6].

4.3.2  Classmark 2 service support in non-Classmark 2 MExE devicesp. 16

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.

4.3.3  Classmark 3 service support in non-Classmark 3 MExE devicesp. 16

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.

4.3.4  Classmark 4 service support in non-Classmark 4 MExE devicesp. 16

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.

Up   Top   ToC