4 Generic MExE aspects

03.573GPPFunctional descriptionMobile Station Application Execution Environment (MExE)Release 1998Stage 2TS

This section 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 this TS categorises devices by giving them different MExE classmarks. In this specification two 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 Personal-Java [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 2 also includes support for MExE classmark 1 applications (via the WML browser.)

Future classmarks may require other Java-packages, APIs, and/or support of other features such as speech-recognition, video-I/O with online (de)-compression, minimal storage requirements, high-speed local communication, etc. but these are subject to future standardisation efforts.

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.1 MExE classmark 1 (WAP environment)

The WAP forum has proposed designs for both the transport protocols on the wireless leg of the end-to-end connection (based on the Wireless Datagram Protocol (WDP), the Wireless Transaction Protocol (WTP), Wireless Transport Layer Security (WTLS) and Wireless Session Protocol (WSP)), as well as the client-side application environment, which revolves around a Wireless Markup Language (WML) browser supporting a Wireless Markup Language Script (WMLScript).

4.2 MExE classmark 2 (Personal Java environment)

This classmark characterises Java enabled devices with telephony specific extensions.

4.3 High level architecture

The following architectural model shows an example of how a GSM network uses standardised transport mechanisms to transfer MExE services between the MS and the MExE service environment, or to support the interaction between two MSs executing a MExE service. The same architectural model can be applied in 3G networks as well.

The MExE service environment could, as shown in figure 1,consist of several service nodes each providing MExE services that can be transferred to the MS using standard Internet protocols. 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 network shall provide the MS with access to a range of bearer services on the radio interface to support application control and transfer from the MExE service environment.

Figure 1: Generic MExE architecture

4.4 Capability and content negotiation

Interaction between the MExE MS and the MSE shall be supported by the use of the hypertext transfer protocol HTTP/1.1 [9], or an HTTP/1.1 derived protocol (e.g. WSP as defined in Wireless Application Protocol [6]). Communication between the MExE MS and the MSE supports:-

  • Capability negotiation

The MExE MS connects to the MSE by using HTTP/1.1 or an HTTP/1.1 derived protocol. Capability negotiation between the MExE MS and the MSE only takes place for the first time after the MExE MS has connected to the MSE, and the MSE is informed about the MExE MS. Without this first initial contact from the MExE MS, the MSE has no knowledge of the MExE MS, and thereafter the MSE may connect to the MExE MS by using HTTP/1.1 or an HTTP/1.1 derived protocol.

Capability negotiation represents the mechanism by which the MExE MS and the MSE interact to inform each other of the specific mechanisms, capabilities and support which each is able to provide or support within the scope of a MExE service interaction. The capability negotiation normally takes place prior to any content transfer between the two entities.

Capability negotiation is used by the MSE to request the MS’ MExE capabilities, to which a response may be returned by the MExE MS. Information is normally requested by the MSE and supplied by the MExE MS, however the MExE MS may also be informed by the MSE of its current view of the MExE MS’s capabilities. The MExE MS may also spontaneously inform the MSE of its capabilities without initially being requested to send them (i.e. following a change in MExE support, such as removal of MExE MS from a docking station with its keyboard, mouse and monitor). The characteristics which may be requested and transferred between the MExE MS and the MSE during the capability negotiation are identified in subclause 4.4.1 Capability negotiation characteristics.

  • Content negotiation

Content negotiation represents the means by which the MExE MS and the MSE inform each other of the requested and available form of content. If needed, the content negotiation may take place following capability negotiation between the two. The methods for content negotiation are the basic HTTP/1.1. or WSP methods explained in [9] and [6].

Content negotiation is used to select the best representation of an entity when there are multiple representations of the entity available from the MSE. The entity (e.g. a service, an image, etc) is located behind a URI, and the application in the MExE MS connects to the URI by using HTTP/1.1 or an HTTP/1.1 derived protocol. The best representation of an entity can be decided by the server (server-driven negotiation) or by the client application (agent-driven negotiation).

Both the capability and the content negotiation has the same purpose: to optimise the content according to client’s capabilities. The term "content negotiation" has been used e.g. in the HTTP specification and the HTTP/1.1. and the WSP contain headers to perform the content negotiation. However, the capability negotiation in MExE aims at extending the basic HTTP and WSP methods for content negotiation. MExE terminal is free to use both the existing HTTP/WSP content negotiation methods and the new MExE capability negotiation methods.

The content negotiation transferred between the MExE MS and the MSE is identified in subclause 4.4.2 Client Capability Report onwards.

4.4.1 Capability negotiation characteristics

Method for capability negotiation is based on the CC/PP specification made by W3C, [16]. The properties and the actual schema is based on the WAP UAProf group specification [17]. The Composite Capability/ Preferences Profiles framework is intended to provide an efficient mechanism for enabling enhanced content and service negotiation through a standardised format for user agent profiles. The use of Resource Description Framework (RDF) in CC/PP allows for interoperable encoding of the profile metadata in XML and supports multiple vocabularies to provide for future extensibility. WAP UAProf is based on the CC/PP framework. The purpose of the UAProf is to specify

  • an RDF based schema and vocabulary for CC/PP in the context of WAP UAProf that includes the class definitions and semantics of attributes described in a user agent profile, and
  • guidelines for schema extensibility to support a composite profile that enables future additions to the vocabulary and schema.

Not all capabilities have to be reported in the request to the server but instead, the client may point to an URL where the server may fetch the properties.

The generic set of capabilities which may be negotiated between the client and the server consists of the subsequently identified properties in the UAProf schema, [17]. A MExE terminal shall support (but not be limited to) the following properties in the UAProf schema for capability negotiation::-

  • MexeClassmark
  • MexeSpec
  • Vendor
  • Model
  • Screensize
  • ScreenSizeChar
  • ColorCapable
  • AudioInputEncoder
  • VideoInputEncoder
  • PointingResolution
  • CcppAccept-Language
  • Keyboard
  • SoftwareNumber
  • SupportedBearers

It is not required that a MExE terminal shall send all the above properties together when sending a request, however it shall be possible for the MExE terminal to send one or more of the above properties if subsequently requested by the server, with user permission.

Generally, the combination of user profile and ME logic will determine the information sent in the capability negotiation from the MExE device to the MExE Service Environment. As an example, for the support of location information the user’s profile controls if and when location information may be sent to the MExE Service Environment (e.g. never sent, always sent, only after user confirmation).

The capability negotiation process shall be used by the client to permit transfer of capabilities from the client to the server. By transferring its capabilities, the client will support efficient use of resources both over the radio interface as well as in the client or server. Capability negotiation shall be performed prior to transfer over the radio interface to verify as far as possible the ability of the client to support any services to be downloaded.

In order to transfer the capability information between the MExE MS and the MSE, CC/PP method is used with the schema defined in the WAP UAProf working group.

4.4.2 CC/PP over WSP (classmark1)

In classmark 1 the CC/PP is carried over by using CC/PP over WSP, [17].

4.4.3 CC/PP over HTTP (classmark2)

In classmark 2 the CC/PP is carried over by using CC/PP over HTTP, [15] or CC/PP over WSP, [17].

4.4.4 Client content capability report

The client may perform content negotiation capabilities to the server by using appropriate HTTP/1.1 or WSP request headers. The following methods are available for content negotiation:

  • Client software (product): User-Agent header
  • MIME media types: Accept header
  • Character set: Accept-Charset header
  • Content encoding: Accept-Encoding header
  • Language: Accept-Language header

There is no need for MExE to specify any tokens for content negotiation, as these headers are already defined in HTTP and WSP. The formats for these headers are specified in [9] and [6].


The following HTTP request reports that the name of client software is "GSM-Phone" version "1.0". The client accepts both compiled WML and compiled WMLScript, and supports both the English and Swedish as languages.

GET / HTTP/1.1

Host: www.company.com

User-Agent: GSM-Phone/1.0

Accept: application/x-wap.wmlc, application/x-wap.wmlscriptc

Accept-Language: en, sv

The basic format of the User-Agent: header is: User-Agent: software-name/version. A comment can be attached enclosed in parentheses to give more specific information. For example, operating system, display size, supported software extensions, script libraries, etc. The format of the comment is, however, not specified in [9].

4.4.5 Server role in capability negotiation

The server may request the capabilities of a client whenever required, and shall enquire of the client’s capabilities prior to making each transaction resulting in a set of transfers to the client; the characteristics which may be reported in the client capability report are identified in the list above.

In server-driven negotiation the server signals to the client that the response entity was selected from a set of available representation. To do this, the server attaches the Vary: response header in the response to the client. The Vary: header includes a list of request headers. For example:

HTTP/1.1 200 OK

Vary: User-Agent, Accept-Language

Content-type: application/x-wap.wmlc

Content-language: en

Indicates that the entity is available for multiple languages and user-agents. The selected entity is the English version.

4.4.6 Client-driven negotiation

If the server cannot specify an optimal version for the client basing on the CC/PP sent over to the server, the server may also indicate to client which type of versions are available and let the client make the decision. This method is already available in HTTP1.1. In client-driven negotiation the client selects the best representation after having received an initial response from the server. The response from the server is a 300 Multiple Choices response and contains a list of available representations. The selection of the available representations may be done automatically by the client application or by the (human) user from a menu.

It is noted that there is an implicit overhead of (at least) one additional round-trip delay with client-driven negotiation. The client-driven negotiation will always require an additional request/response iteration, due to the fact that the initial response from the server to the client’s initial request may be a 300 Multiple choices response, or an equivalent presentation of available choices. After the user has selected one of the available options, the client sends the request for the actual content to the server.

4.5 User profile

The user profile (which may consist of sub user profiles for a user) contains the characterisation of the MExE MS as defined by the user and service provider. Further, it is also possible for multiple users of a MExE MS to each have their own user profiles. The user profile is not unique to the MExE MS, and this clause identifies the usage and content of the user profile from a MExE perspective only, and does not identify the generic support of user profiles in general. Refer to UMTS 22.101 [14] for further details on the user profile.

4.5.1 Location of, access to, and security of, the user profile

As multiple user profiles may be defined, the user is able to set up or receive calls/connections associated with different user profiles simultaneously by securely activating a user profile (with each user profile being associated with at least one unique identifier). Refer to the Security clause for further details on user profile activation.

The user’s characterisation of the MExE MS in the user profile may be modified at any time by the user and the service provider, and changes affected at the earliest possible opportunity.

The security clause shall apply to all user profiles at all times, whether activated or not

The user profile is securely managed by the MExE MS, and stored in a secure area of the MExE MS (either SIM or ME). The service provider may also retain the user profile in the network for service optimisation. User private data in the user profile should not be stored in the network.

The support of more than one user profile is not mandatory.

4.5.2 User profile and capability negotiation relationship

The user profile contains the user’s preferences. Support of the user’s preferences will depend on the capabilities of the device. If the capabilities change, then the degree of support of the user’s preferences may change too.

The capability negotiation between the MExE terminal and the MSE, as shown in figure 2, contains those user preferences which the device is able to support.

In this way the MSE will serve a MExE terminal with the lowest common denominator of the users preferences, the terminal capabilities and the provided service characteristics and support the user’s preferences to the maximum degree.

Figure 2: Model of user profile and capability relationship

4.5.3 Support of the user profile

The user profile acts as a repository (which is always available in the MExE MS) defining the MExE MS behaviour.

MExE preferences and personalisation are supported in the user profile (e.g. UMTS portability and support of VHE defined in [12] and other 22-series specifications), which in turn is based on the Composite Capability/Preference Profile (CC/PP) specification from W3C [16].

MExE preferences and personalisation may not only be recorded directly in the user profile as supported by CC/PP (the direct referencing mechanism), but may also be retrieved from a URL (the indirect referencing mechanism).

Generally, the user profile’s CC/PP framework provides the mechanism for the standardised format of preferences, and its use of Resource Description Framework (RDF) permits the interoperable encoding of MExE preferences and personalisation. Future extensions will be supported by the W3C mechanism, allowing for evolution and development of MExE preferences and personalisation.

The set of preferences which are supported in the user profile consists of the following:-

  • user interface personalisation

the user’s personalisation of the user interface.

  • service personalisation and management

the user’s generic service management information.

The coding and presentation of the above characteristics in the user profile is defined by the Composite Capability/Preference Profile (CC/PP) specification from W3C [16], and referenced by the MExE capability negotiation in clause 4.4.

The following user preference information is supported by UAProf [17]. A MExE terminal shall support (but not be limited to) the following properties in the UAProf schema for user preference information:

  • CcppAcceptLanguage User’s preference for document language
  • DownloadableSoftwareSupport User’s preference for accepting downloadable software
  • PreferenceForFrames User’s preference for displaying frames
  • PushMsgPriority User’s settings for WAP Push message priorities

Also, there is support for indicating terminal’s capabilities related to UI features, e.g. capability for displaying images or frames, as well as capability information about input and output methods.

E.g. the following preference information is for future consideration:

  • Maximum size and time of transfer and other preferences related to transferring the content
  • User’s preferences for input/output methods and other preference parameters related to user interface management
  • User’s preferences for memory usage
  • Service-related parameters (e.g. voice mail numbers, etc.)

4.6 User interface personalisation

The MS interface consists of the buttons, menus, screens and MMI as designed and provided by the MS manufacturer; the nature of this MS interface is naturally evolving, MS specific and proprietary to the individual manufacturers of the industry. This interface is the one normally seen by the user in normal operation of his MS. This specification does not place any requirements or limitations on the individual manufacturers’ MS interface.

The MExE MMI, in turn, is the interface available to the user to support MExE services and functionality on the MS. The nature of the MExE MMI interface, like the normal MS interface described above, is not standardised in any way, to allow for manufacturer innovation, cater for evolving market needs, and permit manufacturer differentiation. The MExE MMI, depending on different manufacturer implementations, may consist of the normal MS interface, the normal MS interface with modifications, a different interface to the normal MS interface, or some combinations thereof etc. MExE services operate within, and using the capabilities of, the MExE MMI.

User interface personalisation consists of two parts. The first part refers to the user’s ability to request, and verify, the preferred changes to the user interface; thus the user’s preferences, as supported by the specific MS, require to be recorded. The second part refers to the MExE MS’s support of the user’s preferences for the interface, within the capabilities of an MS. By defining the user interface personalisation to consist of two stages, the preferences which have been recorded by the user may be transferred (as part of the user profile, e.g. CcppAcceptLanguage and/or PreferenceForFrames), and thereby provide portability of the user’s preferences.

4.6.1 MExE user interface personalisation

Personalisation of the user interface offers the MExE Service Environment and or the user, the ability to inform the MExE MS of the desired extent of personalisation. All support of the user interface personalisation is optional, not mandatory on any class of MS, and subject to the capabilities of the MS. Depending on the capability of the MS, the personalisation may be fully supported, partially supported, interpreted or ignored.

Personalisation of the user interface is not restricted to modifying the appearance of the MMI, but also the modification of MMI parameters (e.g. programming of the voicemail number). The user’s personalisation of the interface is retained as part of the user profile.

4.6.2 Support of MExE user interface personalisation

MExE user interface personalisation is supported via the preferences in the user profile, which in turn is based on the Composite Capability/Preference Profile (CC/PP) specification from W3C [16].

User interface personalisation may not only be reported in the CC/PP request to the server (the direct referencing mechanism), but indeed the client may point to a URL (the indirect referencing mechanism) from where the user interface personalisation preferences may be retrieved.

Generally, the user profile’s CC/PP framework provides the mechanism for the standardised format of preferences, and its use of Resource Description Framework (RDF) permits the interoperable encoding of user interface personalisation. Future extensions will be supported by the W3C mechanism, allowing for evolution and development of MExE user interface personalisation.

4.7 Management of services

The MExE ME shall be capable of supporting services in a standard (WAP or Java) execution environment independently of the MExE ME manufacturer. Management of services provides the user with the capability to

  • discover services
  • configure services
  • control the transfer and execution of services
  • terminate or suspend executing services

on his MExE MS.

Service discovery

A MExE user is able to request (or be informed about), the range of MExE services available from the MExE server to which it is connected. Support for the request, and transfer, of information on MExE services from the MExE server is primarily provided by the use of the capability negotiation mechanism.

All services available in the network continue to be available to the user, in addition to MExE services.

An example of an alternative means of possibly receiving information on MExE services, is the use of an application on the MExE MS which the user interrogates to provide services information (from various sources), and which in turn then obtains such information and presents it to the user. Such an example is not subject to standardisation.

4.7.2 Service configuration

  • The user controls whether a service transferred to the MExE MS is also automatically configured in the MS. Configuration of a service may result in changes to user interface using icons, browsers or menus as applicable depending on the capability of the MExE MS to support them. The service name may be contained in the package in which it was received (i.e. a JAR file or script), assigned by the user during configuration, or some other means. If service automatic configuration is enabled, the user is notified of the automatic service configuration once it is completed.
  • In the event that there is no authorisation for the automatic configuration of a transferred service, the user is notified that it was not configured.
  • The user controls which services may be automatically configured.
  • Subsequent user modification of a service’s configuration (e.g. by modification of use profile settings) shall take effect at the earliest possible opportunity thereafter.

4.7.3 Service management

  • The MExE MS shall support the ability to determine which services are transferred to, resident, configured or executing on the MS. The information relating to the services includes (as a minimum) the name and version.
  • The user controls which services are permitted or denied to be transferred , resident, configured or executing on the MExE MS via the user profile, e.g. DownloadableSoftwareSupport. The user profile permits characteristics such as security level, identification of specific services etc. to manage services on the MExE MS.

4.7.4 Service termination

  • A service may terminate by itself, or be terminated by the provider of the service or by the user. The user is in charge of the service, except when the service provider may appropriately control the service as part of user support.
  • The mechanism for terminating a service is out of scope of standardisation and shall be provided on a service by service basis by the provider of the service.

4.7.5 Service deletion

  • A service may be deleted (i.e. removed) from the MExE with the authorisation of the user. The deletion may be initiated by the authoriser of the service or by the user.

4.8 Virtual home environment

Virtual Home Environment (VHE) (see [11] and [12]) is defined as a concept for personalised service portability across network boundaries and between terminals. MExE is identified by VHE as one of the mechanisms which may be used to support VHE.

VHE presents the same look and feel depending on the capabilities of the serving network and the capabilities of the terminal in use, with any limitations in the terminal being indicated to the user when the terminal is changed. Services that are available/unavailable will be displayed in a way that is familiar to the user no matter what class of terminal is used.

With the general ability of the MExE requirements and functionality to support VHE requirements, MExE shall support the Virtual Home Environment system concept.

The characteristics of the VHE (to reflect any user or home environment modification of the user’s VHE) shall be stored as part of the user profile. Access and modification of the user profile) to support:-

  • identification of subscribed services
  • service personalisation.
  • user interface personalisation

shall be supported by the MExE APIs (when available).

4.9 User control of application connections

  • This sub-clause addresses the generic aspects of connection control supported by both WAP and Java classmark MExE MSs.
  • In order to allow the user to maintain control over connections on his MExE MS and the ability to initiate connections, the user shall be able to terminate or suspend any active connection associated with an application in the MExE environment of the MExE MS. The user shall be able to obtain information on all connections associated with applications on the MExE MS. Behaviour of the application following termination or suspension of its connection is undefined.
  • The specific support of connection control by WAP and Java classmark MExE MSs is identified in subsequent sub-clauses, the security aspects of connection control are identified in the security sub-clause, and the user control of connection authorisation is identified in the user profile sub-clause.

4.10 Journalling of network events

To support the user in monitoring and maintaining a record of (potentially chargeable) network events initiated by services in the MExE environment, it shall be possible for the user to request the MExE MS to maintain a record of network events initiated by services on the MExE MS. Support of such journalling is mandatory.

Network events for the purposes of journalling, are defined as events which result in the origination of voice or data connections by a service in the MExE environment of the MExE MS. Examples of such events are:-

  • Sending an SMS message
  • Sending an USSD message
  • Initiating a circuit switched connection
  • Initiating a packet switched connection
  • Sending data over a packet switched connection

The above list is not exhaustive, but includes any (potentially chargeable) network event initiated by services in the MExE environment.

The user shall be able to activate and deactivate the journalling of network events in a secure manner. The length, format and longevity of the journal is undefined and subject to manufacturers’ discretion.

The journal shall be managed by the ME, and not be accessible by MExE executables.

4.10.1 Journalling requirements

The terminal shall support the logging of network events. The user shall determine whether logging is in operation or not and the events that are logged. The size and format of the log is not the subject of this specification.

4.11 User notification

It is recommended that the device should clearly display an indicator whenever network activity is in progress.

Ideally, this would be an icon on the phone’s screen which is displayed whenever the device is sending/receiving SMS, USSD, data call, voice call, or packets.

However, there are certain cases when this indicator need not be displayed, especially if it is obvious by some other means that the device is performing network actions.