6 Java MExE devices

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

Java MExE devices shall be based on the MExE API for Java, which defines the required and optional components of Java APIs that shall be used to realise a MExE compliant device.

The MExE API for Java primarily defines the functions available to a Java-based MExE device such that services (specified in the form of Java classes and interfaces) can control such a device in a standardised way.

Many aspects of the MExE API specification are optional. Services and applications shall be able to determine the presence of optional parts of the functionality. When optional parts of the functionality are implemented, the MExE API shall be supported.

6.1 High level architecture

Figure 4: Basic functional architecture of a Java MExE device

The functional architecture of a Java MExE device is shown in figure 4. Java applets, applications, and services access functionality via the MExE API for Java. The MExE API is based on a combination of optional Java APIs approved by Sun Microsystems and the Wireless Profile of the JavaPhone API [4] as defined by the JavaPhone Expert Group. The JavaPhone API is based on the PersonalJava API [3] defined by Sun Microsystems.

6.2 High level functions

6.2.1 Optionality

The use of Java encourages development of modular interfaces and minimal required functionality. Additional functionality is provided by optional APIs specified in terms of the Java language. In general, optionality is specified in terms of Java packages. Packages are containers for the highest level of functionality in the Java language. In some cases, optionality is specified in terms of Java classes and interfaces. Classes and interfaces are elements contained inside packages.

The following table 1 specifies the Sun Microsystems defined optionality of the Wireless Profile of the JavaPhone APIs. Within some of the packages, certain classes and methods may be individually specified as optional by the JavaPhone API specification.

Where a mandatory package is identified, it is implicit that any packages called by that mandatory package are also mandatory.

Table 1: Optionality of the Wireless Profile of the JavaPhone APIs

JavaPhone API	Java package	Optionality
Addressbook	Javax.pim.addressbook	Mandatory
User Profile	Javax.pim.userprofile	Mandatory
Calendar	Javax.pim.calendar	Mandatory
Network	Java.net	Mandatory
Datagram	Javax.net.datagram	Mandatory
Power Monitor	Javax.power.monitor	Mandatory
Power Management	Javax.power.management	Optional
Install	Javax.install	Optional
Communications	Java.comm	Optional
SSL	Javax.net.ssl	Optional
JTAPI Core Package	Javax.telephony	Mandatory
JTAPI Core Capabilities Package	Javax.telephony.capabilities	Mandatory
JTAPI Core Events Package	Javax.telephony.events	Mandatory
JTAPI Call Control Package	Javax.telephony.callcontrol	Optional
JTAPI Call Control Capabilities Package	Javax.telephony.callcontrol.capabilities	Optional
JTAPI Call Control Events Package	Javax.telephony.callcontrol.events	Optional
JTAPI Phone Package	Javax.telephony.phone	Optional
JTAPI Phone Capabilities Package	Javax.telephony.phone.capabilities	Optional
JTAPI Phone Events Package	Javax.telephony.phone.events	Optional
JTAPI Mobile Package	Javax.telephony.mobile	Mandatory
	Java.math	Optional
	Java.rmi	Optional
	Java.rmi.dgc	Optional
	Java.rmi.registry	Optional
	Java.rmi.server	Optional
	Java.security	Optional
	Java.security.interfaces	Optional
	Java.sql	Optional
	Java.io	Optional

6.2.2 Required and optional PersonalJava APIs

Java MExE devices shall support the PersonalJava specification [3]. The PersonalJava APIs provide a standardised and readily implementable execution environment as a means for applications, applets, and content:

to access and personalise the user interface via the java.awt packages
to utilise both Internet and Intranet connections via the java.net package

6.2.3 Required and optional JavaPhone APIs

The JavaPhone APIs extend the PersonalJava APIs to provide functionality unique to telephony devices. Java MExE devices shall support the Wireless Profile of the JavaPhone API specification [4]. Java MExE devices shall support all APIs specified as required by the Wireless Profile in the JavaPhone API specification. All APIs that are optional in the Wireless Profile shall be optional in Java MExE devices.

6.2.3.1 Application installation

Java MExE devices shall support the following JAR file manifest entries (as described in the JavaPhone specification) as described below:

Implementation-Title

the Implementation-Title shall be used in any textual description of the application which is displayed in the UI element used to launch the application. E.g. the text displayed with an icon.

Main-Icon

if icons are used as elements to launch the application, then the icon file within the JAR file named by the Main-Icon attribute shall be displayed, and may be scaled if desired.

Main-Class and Class-Path

when the application is launched, the MExE Java VM shall be supplied with the classpath and shall call the main() method in the class named by the Main-Class attribute.

6.2.3.2 Power

Java MExE devices shall support the Power Monitor package (javax.power.monitor) as specified by the JavaPhone API to access the power level of the device and receive notifications concerning changes in power states.

Note that the Power Monitor package does not specify the minimum required events that should be generated under certain circumstances. A MExE Java device shall at least implement the following event generation:

BatteryCritical

shall be generated when the battery is at a critically low level.

BatteryNormal

shall be generated when the battery is no longer low.

All the other event generation should be supported by the implementation.

6.2.4 Required and optional MExE APIs

A Java MExE device shall not be required to support any other Java APIs.

A Java MExE device may optionally support any other Java APIs which comply with the MExE security requirements in table 3, such as:

OCF SmartCard API OpenCard, available from [21]. If the ME supports smartcards other than the SIM, and the smartcard is open to 3^rd party applications, then the opencard.core.terminal section of the OpenCard API may be used to access the card.

6.2.5 Mandated services and applications

6.2.5.1 WAP browser support

To provide backward compatibility to MExE classmark 1, i.e. allow access to services designed for MExE classmark 1 devices, classmark 2 devices must feature a pre-installed or pre-loaded WAP browser that is capable of rendering at least the following content formats:

tokenised WML documents (“WML decks”)
WMLscript bytecode
A WAP service in a MExE classmark 2 MS shall execute in the same manner as it executes in a MExE classmark 1 MS.

Other WML formats (such as textual WML documents or textual WMLscripts) are optional.

The pre-installed/pre-loaded WAP browser may be upgraded, replaced or extended by transferring, a replacement, extension or plug-in mechanism to the MS. Depending on user preferences identified in the user profile and the terminal capabilities, the pre-installed or pre-loaded WAP browser may be overwritten or the new browser stored in a different location.

6.2.5.2 Network protocol support

Support for network protocols in Java MExE devices is specified in the following table 2:

Table 2: Support for network protocols

Protocol	Optionality
HTTP/1.1 [9]	Mandatory
HTTPS	Mandatory
Gopher	Optional
ftp	Optional
mailto [25]	Mandatory
File	Optional

6.2.6 Datagram recipient addressing

The Datagram API (as specified by JavaPhone) may resolve server/service names using a name resolution service. The MExE Java implementation shall at least be able to resolve names using the addressbook.

The implementation of the Datagram API shall support use of the addressbook to resolve names: The addressbook entries shall be searched for items whose name matches the server/service name by the Datagram API implementation in order to resolve names to actual addresses. It shall look for an item of type “FN" with a value equal to the server name, using the following syntax:

server_name: *mostchars

e.g. "The PIZZA Hut".

Then it shall search for aggregate fields named by the service name concatenated to "X-DATAGRAM-", the field name which is named according to the following syntax:

field_name = "X-DATAGRAM-" service_name

service_name = *mostchars

Then it shall use the value of the aggregate attributes which use this field. These strings shall specify in order, the preferred and available protocols and addresses for the named server/service. The string value in each X-DATAGRAM… field shall be formatted as so (inspired by RFC 1738 [22]):

address = primary_name "{" primary_addr "}" *[ secondary_name "{" secondary_addr "}" ]

primary_name = wdp_name | udp_name | sms_name | any_name

primary_addr = internet_addr | phone_number | port | httpurl | *unreserved

secondary_name = sms_name | url_name | sms_center_name | ip_name | any_name

wdp_name = "WDP"

udp_name = "UDP"

sms_name = "SMS"

url_name = "URL"

sms_center_name = "CENTER"

ip_name = "IP"

any_name = 1*alphadigit

secondary_addr = internet_addr | phone_number | port | httpurl | *unreserved

internet_addr = hostname | hostnumber

phone_number = *phonechar

httpurl = "http://" host [ "/" hpath [ "?" search ]]

host = hostname | hostnumber

hostname = *[ domainlabel "." ] toplabel

domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit

toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit

hostnumber = digits "." digits "." digits "." digits

port = digits

hpath = hsegment *[ "/" hsegment ]

hsegment = [ "~" ] *[ uchar | ";" | ":" | "@" | "&" | "=" ]

search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]

lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |

"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |

"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |

"y" | "z"

hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |

"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |

"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

alphadigit = alpha | digit

alpha = lowalpha | hialpha

phonechar = "+" | digit | "#" | "*" | "C" | "D" | "c" | "d"

digits = 1*digit

digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |

"8" | "9"

safe = "$" | "-" | "_" | "." | "+"

extra = "!" | "*" | "’" | "(" | ")" | ","

hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |

"a" | "b" | "c" | "d" | "e" | "f"

escape = "%" hex hex

unreserved = alpha | digit | safe | extra

uchar = unreserved | escape

mostchars = unreserved | " "

As a minimum, the following transport/bearer combinations shall be supported if the device supports the bearer/transport combination:

Transport/bearer combination	Value of primary_name	Syntax of primary_addr	Value of secondary_name	Syntax of secondary_addr
WDP over SMS	WDP	port	SMS	phone_number
SMS	SMS	phone_number
WDP over HTTP	WDP	port	URL	httpurl
UDP over IP	UDP	port	IP	internet_addr

For example:

WAP Datagram over SMS: "WDP=358,SMS={+358503583862}"

SMS: "SMS={+358503583862}"

WDP over HTTP: "WDP={1234},URL={http://somewhere.on.the.web/path/name}"

UDP over IP: "UDP={1234},IP={147.23.120.2}"

If the service centre number is specified for SMS, then the secondary_name shall be "CENTER" and secondary_addr shall be the phone number. If it is not present, then it shall be derived from the default service centre.