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.

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.

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.

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

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.

The MMS shall be able to support the ability to create, update, store, transfer, interrogate, manage and retrieve a user's multimedia messaging profiles. The multimedia messaging profiles shall allow a user to configure and personalise his multimedia messaging environment with the multimedia messaging profiles (e.g. which media types and notifications that shall be delivered to the recipient , such as voice only or text only). The user profile shall allow the user to create and manipulate a list of users, identified by their addresses, from which the user does not want to receive messages. This list is called "user-level blacklist". It shall be possible for the user to add, remove and edit addresses in the user-level blacklist. If the MMS supports a network based repository of MMs, it shall be possible for the users to configure where incoming MMs will be stored. The multimedia messaging profiles shall form part of the user's virtual home environment. MMS information in the user profile when stored in the UA or the network shall be accessed in a standardised manner. The MMS should accomplish this using mechanisms described in the 3GPP Generic User Profile TS 22.240 whenever possible.

The user shall be able to use and access MM in a secure manner. It shall be possible for the contents of MMs to be read only by the intended recipient(s). A recipient shall be informed of the reliability of the identity of the sender in case the sender has authorised his identity to be transmitted. The integrity of MMs during transit shall be assured to extent of the network capabilities. The MMS shall be intrinsically resistant to attempts of malicious or fraudulent use. An MMS service provider shall be able to authenticate a VASP connected to it and shall be able to be authenticated by a VASP connected to it. The MMS service provider shall be able to authorise the VASP to use various MM services. The MMS shall support encryption of the transport layer between an MMS service provider and a VASP. The "Security Threats and Requirements" specified in TS 21.133 shall not be compromised.

The MMS shall be able to support various charging models, including:

• Sender pays;
• both Sender and Recipient pay their respective charges for message delivery;
• Recipient pays for receipt of messages from a VASP when there is a commercial agreement between the Recipient and the VASP;
• Sender pays for reply message on a per message basis.
• The third party who has a commercial agreement with the VASP (and possibly additional agreement with the operator and/or recipient) is charged for the delivery of the message to the recipient.

The MMS shall be able to support various charging mechanisms. The following charging characteristics may be considered:

• message types, length, storage time in the network, etc,
• delivering time, upload / download method,
• MM-sender / -recipient,
• number of messages sent,
• number of messages received,
• roaming conditions,
• location conditions,
• Indication of charging,
  The MMS indicates to the recipient prior to the recipient downloading a multi media message whether the sender has paid or the recipient is expected to pay for the message.
• Prepaid subscriptions.
• Bearer of the message

The MMS shall support a standardized interface to transfer CDRs and other charging related information between the MMS system and the billing system for prepaid and postpaid billing solutions.

External interfaces for controlling and delivering MM between the terminal and an external device e.g. portable computer should be supported.

The standard shall permit interworking with other or existing messaging technologies, messaging services, intelligent network services and supplementary services, either located within or outside a mobile network. In the case of a VASP, such interworking shall include capability negotiation between the VASP and the MMS service provider. Such capability negotiation shall include service version information as a minimum for this release.

Roaming between network operators shall be supported.

The MMS may support operator specific services. Thereby network operators shall be able to provide additional MMS services dealing with enhanced addressing and charging. If supported, the interaction between the MMS and Operator Specific Service shall happen immediately after multimedia message submission time or immediately before multimedia message delivery time, or both. Multimedia Messages sent or delivered from/to users shall be subject to operator specific services handling if:

• the user is provisioned with operator specific services in the MMS user profile. The user may be provisioned independently for operator specific services applicable for submission and delivery of multimedia messages.
  Provisioning of Operator Specific Services for MMS is under control of the HPLMN operator.
• the MMS determines based on a pre-analysis of the recipient's address(es) found in a submitted multimedia message that an Operator Specific Service needs to be invoked. The definition of the addresses invoking MMS Operator Specific Services is under control of the HPLMN operator(s) of the originating and terminating subscribers.

If the Operator Specific Services needs to be invoked, the MMS shall temporarily suspend the normal process of that multimedia message and shall provide the Operator Specific Services with at least the following information:

• messaging event (submission, delivery)
• multimedia message data:
  • sender identification
  • recipient addresses

As a response to the above request from the MMS, the Operator Specific Services may request the MMS to perform one of the following actions:

• leave the multimedia message unmodified and proceed with its processing;
• reject the message.
• modify one or more of the following multimedia message data:
  • sender identification
  • recipient addresses

Operator Specific Services shall be allowed to influence charging of the message by providing additional information to the MMS. The MMS shall transparently forward this information to the billing systems together with the MMS charging relevant data.