Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

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.
Up

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.
[2]
TS 22.057: "Mobile Execution Environment (MExE); Stage 1".
[3]
Personal Java 1.1.1 or higher: Sun Microsystems http://www.javasoft.com/products/personaljava/.
[4]
JavaPhone API version 1.0: http://java.sun.com/products/javaphone/.
[5]  Void.
[6]
Wireless Application Protocol (WAP) June 2000 Conformance Release: http://www.wapforum.org.
[7]  Void.
[8]  Void.
[9]
RFC 2616:  Hypertext Transfer Protocol - HTTP/1.1: http://www.w3.org/Protocols/rfc2616/rfc2616.
[10]  Void.
[11]
TR 22.170: "Universal Mobile Telecommunications System (UMTS); Service aspects; Provision of Services in UMTS - The Virtual Home Environment".
→ to date, withdrawn by 3GPP
[12]
TS 22.121: "The Virtual Home Environment; Stage 1".
[13]  Void.
[14]
TS 22.101: "Service Aspects; Service Principles".
[15]
CC/PP Exchange Protocol based on HTTP Extension Framework; W3C http://www.w3.org/Mobile/CCPP.
[16]
Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation: http://www.w3.org/Mobile/CCPP.
[17]
UAProf Specification: http://www.wapforum.org/what/technical.htm.
[18]
JDK 1.1 security: http://www.javasoft.com/products/jdk/1.1/docs/guide/security/index.html.
[19]
Java 2 security: http://www.javasoft.com/products/jdk/1.2/docs/guide/security/index.html.
[20]
Java security tutorial: http://java.sun.com/docs/books/tutorial/security1.2/overview/index.html.
[21]
OCF 1.1: "Smartcard API specified by OpenCard Consortium http://www.opencard.org.
[22]
RFC 1738:  "Uniform Resource Locators (URL)" http://www.w3.org/pub/WWW/Addressing/rfc1738.txt.
[23]
The MD5 Message Digest Algorithm", Rivest, R., RFC 1321, April 1992. URL: ftp://ftp.isi.edu/in-notes/rfc1321.txt.
[24]
ISO/IEC 10118-3 (1996): "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions".
[25]
RFC 2368:  "The mailto URL scheme".
[26]
ITU-T Recommendation X.509: "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks".
[27]
TS 51.011: "Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface".
[28]
TS 23.107: "QoS Concept and Architecture".
[29]
TS 24.007: "Mobile radio interface signalling layer 3; General Aspects".
[30]
TS 24.008: "Mobile radio interface layer 3 specification, Core Network Protocols; Stage 3".
[31]
TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2".
[32]
PKCS #15: "Cryptographic Token Information Syntax Standard" version 1.1, RSA Laboratories, June 2000
URL: ftp://ftp.rsa.com/pub/pkcs/pkcs-15/pkcs-15v1_1.doc.
[33]
RFC 2510  (1999): "Internet X.509 Public Key Infrastructure Certificate Management Protocols".
[34]
Connected Limited Device configuration, J2ME version 1.0: http://java.sun.com/j2me/docs/.
[35]
Mobile Information Device Profile, J2ME version 1.0: http://java.sun.com/j2me/docs/.
[36]
eXtensible Markup Language (XML) 1.0: W3C Recommendation. http://www.w3.org/XML.
[37]
Resource Definition Framework (RDF) Model and Syntax:W3C Recommendation. http://www.w3.org/RDF.
[38]
UML Partners: Unified Modelling Language: http://www.omg.org.
[39]
TS 31.102: "Characteristics of the USIM applications".
[40]
RFC 2396  (1998): "Uniform Resource Identifiers (URI): Generic Syntax". T. Berners-Lee, R. Fielding, L. Masinter.
[41]
RFC 2616  (1999): "Hypertext Transfer Protocol -- HTTP/1.1". R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.
[42]
Description of the "JAR Manifest" file encoding, Sun Microsystems. URL: http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html.
[43]
RFC 2459  (1999): "Internet X.509 Public Key Infrastructure Certificate and CRL Profile". R. Housley, W. Ford, W. Polk, D. Solo.
[44]
TR 21.905: Vocabulary for 3GPP Specifications.
[45]
WAP Binary XML Content Format Specification (WBXML): http://www.wapforum.org/what/technical.htm.
[46]
RFC 1766:  "Tags for the Identification of Languages".
[47]
WAP Certificate and CRL Profiles: WAP-211-WAPCert http://www.wapforum.org/what/technical.htm.
[48]
TS 23.227: "Applications and User interaction in the UE-Principles and specific requirements".
[49]
PKCS#1 "RSA Cryptographic Standard" version 2.0: RSA Laboratories, October 1998 http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html.
[50]
Common Language Infrastructure: ECMA specification ECMA-335, http://www.ecma.ch/ecma1/STAND/ecma-335.htm.
[51]
Simple Object Access Protocol version 1.1, (SOAP): http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
[52]
PKCS#7 "Cryptographic Message Syntax Standard" version 1.5: RSA Laboratories, November 1993 http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html.
[53]
TS 23.040: "Technical realization of the Short Message Service (SMS)".
Up

3  Definitions and abbreviationsp. 10

3.1  Definitionsp. 10

For the purposes of the present document, the following terms and definitions apply:
administrator:
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
certificate:
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
Operator:
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
phonebook:
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
MExE API:
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
MExE-(U)SIM:
(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:
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:
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:
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
session:
period between the launching of a MExE executable and its execution termination
signature:
"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:
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.
Up

3.2  Abbreviationsp. 12

For the purposes of the present document the following abbreviations apply:
AA
Attribute Authority
API
Application Programming Interface
APDU
Application protocol data unit
ARPK
Administrator Root Public Key
CA
Certification Authority
CC/PP
Composite Capability/Preference Profiles
CGI
Common Gateway Interface
CCM
Certificate Configuration Message
CLDC
Connected Limited Device Configuration
CLI
Common Language Infrastructure
CP-Admin
Certificate Present (in the MExE (U)SIM) - Administrator
CP-TP
Certificate Present (in the MExE (U)SIM) - Third Party
CRL
Certificate Revocation List
Diff-serv
Differentiated Services
DTMF
Dual Tone Multiple Frequency
GSM
Global System for Mobile Communication
GPRS
General Packet Radio Service
HTTP
HyperText Transfer Protocol
HTTPS
HyperText Transport Protocol Secure (https is http/1.1 over SSL, i.e. port 443)
IETF
Internet Engineering Task Force
IP
Internet Protocol
ISDN
Integrated Services Digital Network
JAD
Java Application Descriptor
J2ME
Java 2 Micro Edition
J2SE
Java 2 Standard Edition
JTAPI
Java Telephony Application Programming Interface
JAR file
Java Archive File
ME
Mobile Equipment
MIDP
Mobile Information Device Profile
MIDlet
MIDP Application
MMI
Man-Machine Interface
MRPK
Manufacturer Root Public Key
MSE
MExE Service Environment
MSISDN
Mobile Subscriber ISDN Number
MT
Mobile Termination
OCF
OpenCard Framework
OEM
Original Equipment Manufacturer
OCSP
Online Certificate Status Protocol
ORPK
Operator Root Public Key
QoS
Quality of Service
PDP
Packet Data Protocol
PKI
Public Key Infrastructure
RDF
Resource Description Format
RFC
Request For Comments
RPK
Root Public Key
SCVP
Simple Certificate Verification Protocol
SIM
Subscriber Identity Module
SMS
Short Message Service
SOAP
Simple Object Access Protocol
SSL
Secure Socket Layer
TE
Terminal Equipment
TLS
Transport Layer Security
TP
Third Party
UDP
User Datagram Protocol
UE
User Equipment
UI
User Interface
UMTS
Universal Mobile Telecommunications System
URL
Uniform Resource Locator
URI
Uniform Resource Identifier
USIM
Universal Subscriber Identity Module
USSD
Unstructured Supplementary Service Data
VM
Virtual Machine
WAE
Wireless Application Environment
WAP
Wireless Application Protocol
WBXML
WAP Binary XML
WDP
Wireless Datagram Protocol
WMLS
Wireless Markup Language Script
WSP
Wireless Session Protocol
WTA
Wireless Telephony Applications
WTAI
Wireless Telephony Applications Interface
WTLS
Wireless Transport Layer Security
WTP
Wireless Transaction Protocol
WWW
World Wide Web
XML
Extensible Markup Language
Further abbreviations are given in TS 22.057 and TR 21.905.
Up

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.
Up

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)
Up

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.
Up

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].
Up

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