5 General Requirements

22.1403GPPMultimedia Messaging Service (MMS)Stage 1TS

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

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

– 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

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.

– 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]. MMS Content Providers shall be able to invoke DRM to prevent unauthorized copying and forwarding of controlled content through the MMS.

5.2 Multimedia message delivery and submission

– Submission mechanism

The MMS shall support multimedia messages or messages elements to be submitted from the sender’s UE.

– Push Mechanism

The MMS shall be able to support a request for multimedia messages or messages elements to be automatically delivered to the recipient’s UE.

– Pull Mechanism

The MMS shall be able to support a request for multimedia messages or messages elements to be delivered to the recipient’s UE on request by the recipient.

NOTE 1: Push and pull delivery mechanisms could be identical; the criteria which decide on the type of mechanism (push / pull) are either described in the User Services Profile or out of the scope of this specification.

– Concurrency

The MMS shall be able to support MM delivery to and from the user’s terminal not be restricted during other active services (subject to the capabilities of the terminal and the network).

– Streaming

The MMS shall be able to support streaming for MM delivery from the MMS system to the terminal.

Support for streaming for MM upload from the terminal to the MMS system will be considered for future releases.

– Preferred Bearer

It shall be possible to define a list of precedence for bearers in the configuration information sets for delivery and submission of MM (e.g. GPRS, CSD). By default, the the terminal shall be able to support automatic bearer selection (i.e. without user intervention) based on the order of precedence defined in the configuration information sets on the USIM[7] or SIM [8]. The user shall be able to enable or disable automatic bearer selection. When disabled, manual bearer selection shall be available from the list of bearers.

– Conditional delivery mechanism

It shall be possible for the user to define in the User Profile a set of conditions that determine which delivery mechanism should be used for the delivery of a MM.

Such conditions should include:

– Roaming status of the recipient (e.g. inside or outside the home network)

– Identity of the MM originator

– Time of day (of the recipient’s home network)

– Upper limit to the MM size

The notification message indicating an MMS awaiting delivery shall relay the information of the user’s preferred delivery mechanism, if such information is made available by the user profile in the network, to the UE. If a mismatch is identified between the delivery mechanism configured in the UE and the delivery mechanism indicated in the notification message, it shall be possible for the user to select either the delivery mechanism configured in the UE or the delivery mechanism indicated in the notification message.

Furthermore, the terminal may also display a warning prior to the download of a message depending on some terminal parameters such as:

– Available storage capacity

– Remaining battery life

– Available bearers

For example, the user may elect to have all MMs downloaded automatically when in the home network, be able to manually select whether to download a MM or not when roaming.

It shall be possible for the network operator to program a default set of rules for the delivery mechanism in the User profile. Such rules can be overridden by the user.

NOTE 2: The way the user profile is accessed and modified is not subject of standardisation.

– MM intended for applications other than the default MMS client on the UE

The MMS shall support MMs that are not intended for presentation but used to originate and deliver information to applications residing on the UE other than the default MMS client.

NOTE 3: The intended application can present the MM contents.

When an application sends a MM not intended for presentation, it shall be possible to uniquely identify that originating application and the target application on the recipient UE as well as the instance of the application if more than one instance can be active. The originating application may reside on a UE or within the network.

The message payload shall not be modified by the MMS.

If the MM is originated by the subscriber’s home environment, it shall be possible to protect the MM from accidental deletion by the user.

5.2.1 MM delivery to and submission from a VASP

– VASP submission mechanism

The MMS shall support multimedia messages or messages elements to be submitted from a VASP.

– VASP delivery mechanism

The MMS shall be able to support multimedia messages or messages elements to be delivered to a VASP.

– VASP mass distribution

The MMS shall be able to support a request from a VASP for mass distribution of MMs to recipients.

– Additional VASP data

The MMS shall be able to convey additional data associated with an MM from a VASP to the MMS service provider and vice versa.

Note: A possible use case for this could be the option to sent additional charging information from the VASP to the MMS service provider. However the data itself is not specified for this release.

5.3 Notification and Acknowledgement

The MMS shall be able to support a request to send generic notification and acknowledgement capability to inform the user in an appropriate manner of MMS events. Examples may include:

– notify the recipient about received messages (including a description of the message, e.g. content, size, type).

– notify the recipient about actions taken by the MMS, (e.g. due to profile settings like automatic MM forwarding, deletion, etc.).

– acknowledge the sender about successful or failed MM or storage of a MM.

– acknowledge the sender about successful or failed MM submission.

– acknowledge the sender, including a VASP, about successful or failed MM delivery to the recipient terminal (subject to the recipient permitting such an acknowledgement).

– acknowledge the sender, including a VASP, about the MM being read/handled at the recipient terminal (subject to the recipient permitting such an acknowledgement).

– acknowledge the sender, including a VASP, about successful or failed MM deletion.

– acknowledge the sender, including a VASP, upon request, about the status of a submitted MM (i.e. delivered / not delivered).

– acknowledge a VASP, upon request, about the status of a mass distributed MM. A mass MM status report might be an aggregated report on the status of individual messages for all recipients on the distribution list of a specific mass distributed MM.

– acknowledge a VASP, upon request, about the status of previously submitted MMs, after a VASP had sent the MMs being queried.

5.4 Addressing

The MMS shall support different addressing formats to identify the sender and recipient. It shall be possible to submit one message to multiple recipients.

The MMS shall support the capability for both MSISDN [4] and e-mail addressing schemes [5] to be used, and the user may use either form of addressing to send a message.

The MMS shall be able to support the request to hide the sender’s address from the recipient.

The MMS shall support a distribution list for mass distribution of MMs from a VASP. The MMS shall support the ability for a VASP to have the distribution list modified by the MMS service provider for this release.

The MMS may support short code addresses to address Value Added Services. If supported, and routing of messages to a MMS VASP service based on a short code address is enabled, the MMS shall be able to translate the short code address to a routable address to be used in the transport layer, e.g. a URI.

5.5 Management and Control of a Network Based Repository

Network based repository is optional. If supported, MMS shall be able to support following functionalities:-

– The MMS shall allow an MMS service provider to configure MMS in such a way that one, several or all incoming MMs of a particular user be stored persistently in a network based repository

– The MMS shall allow an MMS service provider to configure MMS in such a way that one, several or all submitted MMs of a particular user be stored persistently in a network based repository

– The MMS shall be able to support a request from a sender to persistently store a sent MM in a network based repository at the time of sending

– The MMS shall be able to support a request from a user to persistently store a MM for which he received a notification in a network based repository

– The MMS shall be able to support a request from a user to upload one or more MMs into a network based repository for persistent storage

– The MMS shall be able to support a request from a user to retrieve one or more MMs that are stored in a network based repository

– The MMS shall be able to support a request from a user to delete one or more MMs that are stored in a network based repository

– The MMS shall be able to support a request from a user to forward one or more MMs that are stored in a network based repository to another destination without being delivered first to that user.

– The MMS shall be able to support a request from a user to view the list of MMs and MM related attributes, such as sender, recipient, subject and date/time, in a network based repository

5.6 Error Messages

It shall be possible for the operator to configure the content of the error message delivered to the MMS client.

5.6.1 Prepaid Errors

The MMS shall notify a prepaid user when message submission was unsuccessful due to lack of credit in the prepaid account, explicitly stating this situation.

5.7 MMS client interaction with UICC

It shall be possible for an MMS client in the ME to interact with a UICC to manage (e.g. send, receive and present) MMS messages stored on the UICC, in accordance with the requirements in this specification. It shall be possible to indicate to the UE that an MM needs to receive special treatment. When a MM has been marked with this indication, means shall be provided to protect the MM from accidental deletion e.g. by asking for additional confirmation to the user. The use of this indication shall be under the control of the HPLMN.