Multimedia Messaging Service

 

Acronym: MMS

UID: 1818

Main responsibility: T2

 

References for WI " Multimedia Messaging Service "

Document	Title/Contents
TP-000078	WI Description
Impacted Specifications
TS 22.140 TS 23.140	Multimedia Messaging (MMS) stage 1 Multimedia Messaging (MMS) stage 2/3
New Dedicated Specifications
	None

 

The Multimedia Messaging Service (MMS) was first introduced in Release 99. It allows users to send and receive messages exploiting a large array of media types e.g. text of almost unlimited length, images, audio and video clips, while also making it possible to support new content types as they become popular. Multiple media elements can be combined into a composite single message. Messages can be sent either to a mobile phone or to an e-mail address.

 

The main network element of the Multimedia Message Service Environment (MMSE) is the MMS Relay/Server which is responsible for storage and handling of incoming and outgoing messages and for the transfer of messages between different messaging systems. Beside these tasks, the MMS Relay/Server has many other tasks which are described in TS 23.140. Other involved MMS elements are the MMS User Agent and MMS User databases. The functional descriptions of the involved MMS elements are provided in TS 23.140 and for implementation of the MMS User Agent – MMS Relay/Server interface a reference to the WAP Implementation of MMS is given. Whereas the Release 99 specifications only included the concept with some little technical details, the Release 4 document was enhanced significantly.

 

The figure below shows the MMS reference architecture and identifies the reference points.

 

MMS reference architecture

The main improvement of MMS in Release 4 is the full definition of an operable MMS, including the MMS Service Behaviour Description, the Reference Architecture as shown above, the MMS framework, the application protocol framework and service primitives, and the Technical realisation of MMS, including the handling of MMS-related information on the USIM.

To enable interoperability of MMS between terminals and MMS network equipment of different manufacturers, the definition of a minimum set of mandatory media formats for the MMS User Agent was introduced. It included AMR for media type Audio, and Baseline JPEG for media type Image. The optional support of several more codecs is specified.

The support of the following aspects were added:

• streaming in MMS, enabling an MMS to trigger a streaming session.
• prepaid services in MMS
• sender’s address hiding
• SMS over MMS. For this, the encapsulation of a short message in a multimedia message was specified.

The other aspects of Release 4 MMS are:

• The service behaviour description and the technical realization of Delivery-report and Read-reply report were introduced.
• As implementation examples for the MM1 interface between MMS User Agent and MMS Relay/Server, WAP implementation and IP implementation of MMS were added as Annexes.
• The reply-charging feature was added. This allows a user to take over the charge for the sending of a reply-MM to their submitted MM from the recipient(s). The originating MMS User Agent may define a reply-charging limitation request (e.g. may specify the latest time of submission of the reply-MMs or a maximum size of reply-MMs).
• The interworking with external servers (in particular IP-based) was further defined. An annex was added giving guidance on MM3 principles.
• The addressing scheme was further elaborated.
• The ability of forwarding MMs without prior download was inserted.
• The interface MM7 between the MMS Relay/Server and the MMS VAS Applications was added to the reference architecture. (It has to be noted that the detailed stages 2 and 3 descriptions were provided only in Rel-5)
• An example of Integration with Unified Messaging System (UMS) was added as an annex.
• Charging enhancements: An annex was added describing information of MMs/abstract messages which may be required for inclusion into Call Data Records (CDRs) for MMS for the purpose of Billing and Traceability.

MExE enhancements Rel-4

 

Acronym: MExE

UID: 1445

Main responsibility: T2

 

References for WI " MExE enhancements Rel-4 "

Document	Title/Contents
TP-030052	WI Description
Impacted Specifications
TS 22.057 TS 23.057	Mobile Execution Environment stage 1 Mobile Execution Environment stage 2
New Dedicated Specifications
	None

 

The work item MExE enhancements Rel-4 consists of two aspects:

· MExE Rel-4 Improvements and Investigations: several enhancements are introduced in Release 4 of which the most significant ones are mentioned in the MExE description below

• MExE Security Analysis Activity: this task was suggested to carry out an analysis of the MExE security framework and evaluate if it is sufficient to eliminate the risks posed by downloading content and applications. This analysis was performed by SA3 (Security) in co-operation with T2-MExE group.

 

MExE is a feature introduced in GSM Release 98, enhanced in GSM Release 99 to cover SIM MExE certificate management, security clarifications and QoS aspects. Release 4 introduces further enhancements of which the most significant is the introduction of a new small footprint Java classmark (Classmark 3).

 

MExE provides a standardised execution environment in an MS, and an ability to negotiate its supported capabilities with a MExE service provider, allowing applications to be developed independently of any MS platform. The MS can then be targeted at a range of implementations for MExE from small devices with low bandwidth, limited displays, low processor speeds, limited memory and MMI to sophisticated devices with a complete MExE execution environment.

 

A standardised means of negotiating the MSs’ and network’s capabilities is supported. This negotiation permits the mutual exchange of capabilities between the MS and the MExE server, and possibly includes the service profile of the user and capabilities of the network.

 

A network can be a transport bearer for the negotiation, interaction and transferring of applications, applets and content with the MS. It does not have to be the provider of the MExE services with which the MS’s execution environment is interacting with. The network may also be the intermediary between two MSs which are engaged in a MExE service with each other, with the network effectively supplying the “pipe” and not playing a MExE role in the connection. Network nodes, nodes external to the network, or even MSs are the entities which can interact with the MSs’ execution environment.

 

Central elements of the MExE specification are the classmark concept, content negotiation and the security architecture which are explained below.

 

The MExE classmark provides the device’s capabilities. The following classmarks are defined in Release 4 (in Rel-4 MExE classmark 3 was added):

 

· MExE classmark 1 - based on Wireless Application Protocol (WAP) - 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 - 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.)

• MExE classmark 3 – based on J2ME CLDC and MIDP environment – supports Java applications running on resource-constrained devices. Classmark 3 MExE devices are based on the Connected Limited Device Configuration (CLDC) with the Mobile Information Device Profile (MIDP). Java 2 Micro Edition (J2ME) is a version of the Java 2 platform targeted at consumer electronics and embedded devices. CLDC consists of a virtual machine and a set of APIs suitable for providing tailored runtime environments. The J2ME CLDC is targeted at resource constrained connected devices (e.g. memory size, processor speed etc.)

 

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.

 

In order to manage the MExE and prevent attack from unfriendly sources or transferred applications unintentionally damaging the MExE device a security architecture is specified. The basis of MExE security is:

· a framework of permissions which defines the permissions transferred MExE executables have within the MExE MS;

· the secure storage of these permissions and permission types;

· conditions within the execution environment that ensure that MExE executables can only perform actions for which they have permission.

 

The MExE permissions framework is as follows (there is no implied hierarchy):

· MExE Security Operator Domain (MExE executables authorised by the HPLMN operator);

· MExE Security Manufacturer Domain (MExE executables authorised by the terminal manufacturer);

· MExE Security Third Party Domain (trusted MExE executables authorised by trusted third parties);

· Support for the three domains is mandatory;

Untrusted MExE executables are not in a specific domain, and have very reduced privileges.

 

In Release 4 several enhancements to the security framework have been introduced in particular enhancements related to the new MExE classmark 3 based on J2ME CLDC and MIDP.

 

Another enhancement in Release 4 is the optional support of core software download. Core software download enables the UE radio, characteristics and properties to be updated by changing the software in the UE. E.g. a new codec may be loaded into a device, a new air interface, etc. Guidelines are introduced into the specification but the functionality is not specified in detail.

5.3 Advanced Speech Call Items enhancements_REL-4

 

Acronym: ASCI

UID: 2230

Main responsibility: CN1

 

References for WI " Advanced Speech Call Items enhancements_REL-4 "

Document	Title/Contents
NP-000730	WI Description on ASCI Release 4 enhancements
Impacted Specifications
TS 43.068 TS 43.069 TS 44.068 TS 44.069 TS 24.008	Voice Group Call Service (VGCS); Stage 2 Voice Broadcast Service (VBS); Stage 2 Group Call Control (GCC) protocol Broadcast Call Control (BCC) protocol Mobile radio interface Layer 3 specification; Core network protocols; Stage 3
New Dedicated Specifications
	None

 

This work item was introduced manly for maintenance of the ASCI feature. ASCI refers to the use of GSM for Railways (GSM-R).

The Release 4 enhancements cover ASCI’s High Speed Train Interoperability, as requested by the TSI (Technical Standards for Interoperability).

The enhancements are the possibility to add operator-to-dispatcher information, the definition of ASCI related event records, and the introduction of ciphering for Voice Group Call Service (VGCS)/Voice Broadcast Service (VBS).