|
TECHNICAL SPECIFICATION
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Multimedia Messaging Service (MMS);
Stage 1
(3GPP TS 22.140 version 15.0.0 Release 15)
---------------------- Page: 1 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 1 ETSI TS 122 140 V15.0.0 (2018-07)
Reference
RTS/TSGS-0122140vf00
Keywords
GSM,LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
If you find errors in the present document, please send your comment to one of the following services:
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 2 ETSI TS 122 140 V15.0.0 (2018-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 3 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 3 ETSI TS 122 140 V15.0.0 (2018-07)
Contents
Intellectual Property Rights . 2
Foreword . 2
Modal verbs terminology . 2
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 High level Requirements . 6
5 General Requirements . 7
5.1 Multimedia message management . 7
5.2 Multimedia message delivery and submission . 10
5.2.1 MM delivery to and submission from a VASP . 12
5.3 Notification and Acknowledgement . 12
5.4 Addressing . 12
5.5 Management and Control of a Network Based Repository . 13
5.6 Error Messages . 13
5.6.1 Prepaid Errors . 13
5.7 MMS client interaction with UICC . 13
6 User Profile . 14
7 Security. 14
8 Charging . 14
9 External Interface . 15
10 Interworking . 15
11 Roaming . 15
12 Support of Operator Specific Services . 15
12.1 Service Interaction . 16
12.1.1 VASP Services . 16
Annex A (informative): Change history . 17
History . 19
ETSI
---------------------- Page: 4 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 4 ETSI TS 122 140 V15.0.0 (2018-07)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
SMS has been very successful in the GSM second generation system, as all mobiles have supported the application
level and it is possible to send to any GSM handset without the need to check for individual support. This easy to use
service for non realtime text transmission between GSM users shall be succeeded to in third generation mobile systems
by a non real-time Multimedia Message Service, MMS. The MMS will allow users to send and receive messages
exploiting the whole array of media types available today e.g. text, images, audio, video while also making it possible to
support new content types as they become popular.
3GPP shall not standardise new services themselves, but instead uses the standardised set of service capabilities features
on which the new services will be built.
Multimedia technology is rapidly developing new capabilities, such as multimedia messages, games, presentations and
services that are now considered to be a part of everyday life. Multimedia consists of one or more media elements (such
as text, voice, image and video), and it is the combination of these media elements in an ordered synchronised manner
that creates a multimedia presentation.
A non-realtime multimedia message as observed by the user is a combination of one or more different media elements
in a multimedia presentation, that can be transferred between users without the requirement for the need to be
transferred in realtime. The non-real-time multimedia messaging service shall be capable of supporting current and
future multimedia messaging services, and exploit the advances being made in the world multimedia community, with
additional mobile requirements.
ETSI
---------------------- Page: 5 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 5 ETSI TS 122 140 V15.0.0 (2018-07)
1 Scope
This Technical Specification defines the stage one description of the non real-time Multimedia Messaging Service,
MMS. Stage one is the set of requirements which shall be supported for the provision of non real-time multimedia
messaging service, seen primarily from the subscriber’s and service providers’ points of view.
This TS includes information applicable to network operators, service providers, terminal and network manufacturers.
This TS contains the core requirements for the Multimedia Messaging Service, which are sufficient to provide a
complete service.
This TS defines the requirements for MMS to be understood as a framework to enable non real-time transmissions for
different types of media including such functionality as:
- multiple media elements per single message
- individual handling of message elements
- different delivery methods for each message element
- negotiate different terminal and network MM capabilities
- notification and acknowledgement of MM related events (e.g. delivery, deletion, .)
- handling of undeliverable MM
- personalised MMS configuration
- flexible charging
The above list is not exhaustive.
Thus the MMS enables a unified application which integrates the composition, storage, access, and delivery of different
kinds of media, e.g. text, voice, image or video in combination with additional mobile requirements.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• 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] 3GPP TS 22.101: "Service Principles".
[2] Void
[3] 3GPP TS 21.133: "3G Security; Security Threats and Requirements".
[4] ITU-T E.164 (1997): "The International Public Telecommunications Numbering Plan".
[5] IETF; STD 0011 (RFC 2822): "Internet Message Format", URL:
http://www.ietf.org/rfc/rfc2822.txt.
[6] 3GPP TS 21.905: "Vocabulary".
[7] 3GPP TS 31.102 "Characteristics of the USIM Application".
ETSI
---------------------- Page: 6 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 6 ETSI TS 122 140 V15.0.0 (2018-07)
[8] 3GPP TS 51.011 (Rel-4): "Specification of the Subscriber Identity Module – Mobile Equipment
(SIM-ME) interface".
[9] 3GPP TS 22.242 "Digital Rights Management (DRM); Stage 1".
[10] 3GPP TS 22.240 "Stage 1 Service Requirement for the 3GPP Generic User Profile (GUP)" .
3 Definitions and abbreviations
3.1 Definitions
Recipient : the recipient is the entity to which a MM has been sent.
Sender: the sender is the entity that sent a MM.
User: the user is the MM sender or the MM recipient.
message element: a message element is a part of a MM consisting of only one media type.
multimedia message: a multimedia message is a message composed of one or more message elements.
multimedia message service: A multimedia message service allows transfer of multimedia messages between users
without the requirement for the multimedia messages to be transferred in real-time.
media types: a media type refers to one form of presenting information to a user, e.g. voice or fax.
media formats: within one media type different media formats are applicable for the media presentation, e.g. a picture
can be GIF or JPEG format.
network: for the purposes of supporting multimedia messaging, the term network shall be considered to include the
mobile operator's network and any functionality which may exist outside the mobile operator's network (i.e.fixed,
internet and multimedia technologies etc.), and the support provided by that functionality for multimedia messaging.
Operator Specific Service: network-based and operator administred function being able to perform additional,
operator defined, MMS services based on MMS capabilities for address translation and charging.
Value Added Service Provider: provides services other than basic telecommunications service for which additional
charges may be incurred.
Short code: A string of alphanumeric characters which addresses a specific service of a Value Added Service Provider.
3.2 Abbreviations
For the purposes of this document the following abbreviations apply:
MM Multimedia Message
MMS Multimedia Message Service
SMS Short Message Service
VASP Value Added Services Provider
4 High level Requirements
The following list gives the high level requirements of the MMS. These are requirements which are independent of the
user’s perception of the service:
- Forward compatible multimedia messaging
Multimedia messaging mechanisms shall provide the capability to support current and evolving multimedia
messaging by re-using existing standards as far as possible and proposing extensions (as necessary) to existing
standards (i.e. the multimedia messaging service shall support the evolution of multimedia messaging
technologies).
ETSI
---------------------- Page: 7 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 7 ETSI TS 122 140 V15.0.0 (2018-07)
- Consistent messaging
Regardless of the message type / format, MMS shall be capable of supporting integration of all types of
messaging (e.g. fax, SMS, Multimedia , voicemail, e-mail etc.) in a consistent manner.
- Universal messaging access
Within the capabilities of networks and terminals, the user shall be able to experience consistent access to the
MMS regardless of the access point.
For example the user should be capable of accessing her multimedia messages through a number of different
access points, which should include 3GPP systems, fixed networks, the Internet, etc.
- Interoperability
The MMS shall support a minimum set of functionality and message formats to ensure interoperability (e.g.
deletion of MM, identified standardised message notification, message media types and message content
formats).
The MMS shall provide a minimum set of supported formats to ensure full interoperability between different
terminals and networks from the very beginning of service provisioning (e.g. JPEG for pictures, MP3 for audio,
MPEG for motion pictures, etc.).
The MMS shall support version management by indicating a version number in the MM for interoperability
purpose.
5 General Requirements
Network operators have many differing requirements, and MMS shall be supported in the network in a manner which
allows network operators to consider different configurations depending on their network and commercial requirements.
Thus, an identified set of functionalities and formats shall be standardised to ensure interoperability across networks and
terminals to support MMS.
However, some network operators may wish to design and configure networks in different ways, and the subsequent
requirements are identified to allow flexibility in how the MMS functionality is supported. For example in some
networks the network operators may wish to implement the MMS functionality within the core network, whereas other
may wish to place the MMS functionality on the periphery of the core network (e.g. a centralised network model instead
of a distributed architecture). Further, some network operators may wish to support a limited set of MMS functionality,
while others may require extensive and elaborate MMS support according to their business models (e.g. basic MMS
instead of advanced MMS). Interoperability shall always be maintained within this flexible architecture.
The following sub-clauses use the term "The MMS shall be able to support a request for …" and similar phrases to
allow network operators to consider these different network models and business requirements, to permit flexible
architectures and ensure MMS interoperability.
The following sub-clauses use the term "This requirement shall be supported at the application layer in the terminal
(and/or the network), and will not be further elaborated.” and similar phrases to identify those service requirements that
shall be supported by MMS but do not require standardisation.
The criterion for identifying these types of requirements is as follows:
If the requirement corresponds to an interaction and/or command between the terminal and the network applications
from the same Service Provider (e.g. between the recipient’s terminal resident messaging application and the recipient’s
network resident application. The same applies for the sender), then this requirement shall be supported by MMS but
does not require standardisation.
The following general requirements shall be supported.
5.1 Multimedia message management
- Terminal-sensitive MM management
The MMS shall be able to support the capability for the terminal and network to take account of the capability of
the user's terminal (e.g. deliver a MM / notification in a manner compatible with the terminals capability).
ETSI
---------------------- Page: 8 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 8 ETSI TS 122 140 V15.0.0 (2018-07)
- Terminal status-sensitive MM Management
The MMS shall be able to support the capability of the network to take account of the availability, changes of
the state of availability of the terminal (e.g. store messages if the recipient is not available).
- MMS Control by the operator
The MMS shall be able to support a request from the operator to enable/disable MM delivery and submission.
- MMS Control by the user
The MMS shall be able to support a request from the user to enable/disable MM delivery and submission.
This requirement shall be supported at the application layer in the terminal, and will not be further elaborated.
- Storage of MMS parameters
The USIM shall be able to store the following types of MMS related data:
i) a number of sets of issuer configuration information to allow access to MMS services.
At least one of these sets of configuration information should be stored on the USIM by the issuer of the
USIM.
The first issuer configuration information set is denoted as the default configuration set.
This configuration information shall only be configurable by the issuer of the USIM.
ii) a number of sets of user configuration information to allow access to MMS services.
If more than one set of configuration information is present, it shall be possible for the user to select which
set is used. If the user has not selected any of the configuration information sets, then the default set in the
active USIM is used.
iii) MMS notifications
iv) MMS user preferences
A terminal using a USIM [7] or a SIM [8] with these MMS parameters, shall by default use them and the related
preferred bearer, to access to the MMS services.
NOTE 1: Terminal support of SIM and USIM in general is specified in 3GPP TS 22.101[1].
- Personalise multimedia messaging
The MMS shall be able to support a request by the user to manage the Service Preferences of his User Service
Profile related to this MMS [6](e.g. customise his MM environment within the capabilities of the terminal,
network and MM application. This could be unconditional or conditional e.g. depending on roaming conditions
or operator restrictions).
- MM creation
The MMS shall be able to support the request to create a MM by the user or an application.
This requirement shall be supported at the application layer in the terminal, and will not be further elaborated.
- MM Time Stamping
The MMS shall be able to support the request to include a reliable time value in an MM, a notification and an
acknowledgement as appropriate.
- Multiple Media
Multimedia messages may be composed of either a single medium (e.g. voice) or multi-media (e.g. Voice and
video). The MMS shall be able to support a request for media synchronisation / sequencing.
- Media Type Conversion
ETSI
---------------------- Page: 9 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 9 ETSI TS 122 140 V15.0.0 (2018-07)
The MMS shall be able to support a request to convert between media types (e.g. Fax to image). The MMS shall
be able to support an indication from a VASP that VASP originated content of an MM should not be converted
or changed by the MMS service provider before it is delivered to the recipient.
This requirement shall be supported at the application layer in the network, and will not be further elaborated.
- Media Format Conversion
The MMS shall be able to support a request by the user or the application to convert between MM media
formats (e.g. JPEG to GIF).
This requirement shall be supported at the application layer in the terminal and/or in the network, and will not be
further elaborated.
- Message forwarding
The MMS shall be able to support a request to forward multimedia messages or multimedia message elements
without having to first download the MM to the terminal. The MMS shall provide a mechanism to prevent an
MM forwarding loop (e.g. MMs are setup to be automatically forwarded from User A to B, then from B to C
and from C back to A. Users A, B, and C are unaware that they have setup this undesirable situation).
- Storage of Multi-Media Messages
The MMS shall be able to support a request for multimedia messages or message elements to be stored until
delivered to the recipient’s terminal, until they expire, or until they are deleted by the user (unless configured
differently). The MMS shall be able to support a request to store and manage all MMs in a network based
repository rather than on the mobile terminal.
When the USIM supports MMs storage, it shall be possible for the MMS client to store and retrieve MMs or
elements of MMs in the USIM.
NOTE 2: There is no requirement for the MMS to be responsible for the processing/presentation of the MM
message, after it has been delivered to the terminal.
- Prioritisation of Messages
The MMS shall be able to support a request for MM prioritisation . The prioritisation is passed to the
recipient(s) of the message as an indication of the importance the sender places on the message. MM
prioritisation is not acted upon by the network.
- Message qualification
The MMS shall be able to support a request for MM qualification (e.g. subject) for the purpose of advanced user
experience and awareness.
- Screening of Messages
The MMS shall be able to support a request for MM screening subject to the capabilities of the network (e.g.
automatically delete “junk mail”, anonymous messages without delivery to the recipient’s terminal).
This requirement shall be supported at the application layer in the terminal an/or in the network, and will not be
further elaborated.
- Validity Period
The MMS shall be able to support a request by the originator of a message to define validity periods (earliest and
latest desired time) for message delivery (e.g. if a message can not be delivered within a certain time it will be
automatically deleted). The MMS service provider shall be able to set the MAXIMUM allowable validity period
for any message.
- Multimedia Message Processing by a VASP
The MMS shall be able to support a request for messages to be processed by a VASP. An example of such
processing may be where an MM is sent to a VASP before delivery to the recipient so that the VASP can add
multimedia element(s) to the original message.
ETSI
---------------------- Page: 10 ----------------------
3GPP TS 22.140 version 15.0.0 Release 15 10 ETSI TS 122 140 V15.0.0 (2018-07)
- Replacing MM
The MMS shall be able to support a request by a VASP to replace a previously sent MM from the VASP with a
second newer MM.
- Cancellation of MM
The MMS shall be able to support a request by a VASP to delete a MM that had previously been sent from the
VASP but not yet delivered to the terminal.
- Hyperlinks in MM
It shall be possible to embed a hyperlink in a MM.
The following guidelines on editing, presenting and following of hyperlinks should be followed:
• There should be no restriction to the position in the MM where a hyperlink can be added.
• It should be possible to clearly recognise the presence of a hyperlink.
NOTE 3: It is preferable to display the title of a hyperlink rather than the complete address. (URI)
• Presence of a hyperlink in an MM should not impact the presentation of the MM (i.e. due to immediate
following or storage of the link)
• The recipient of an MM should be able to follow a hyperlink.
The hyperlink should not be followed automatically by default (explicit user interaction should be required)
- Digital Rights Management
The MMS shall be able to support controlling the distribution of controlled content as defined in 3GPP TS
22.242 [9].
...