3GPP TSG-T WG2#4
Miami, Florida, USA, 14-16 June 	TSGT2#4(99)502

Agenda Item:	SWG3

Source:	NTT DoCoMo

Title:	Multimedia Message Service 

Document for:	Discussion

___________________________________________________________________________

Introduction

   This document provides a concept of “Multimedia Message Service” (we call “MMS”) in the 3G system and general requirements for MS to support the service.  We describe first about general idea and overview of MMS, then present required features or functionality of MS in order to provide those advanced messaging services.

Messaging in the 2G and the 3G 

   In the second generation many cellular systems provide messaging service, which can send/receive short length text. In GSM, SMS can support up to 160 character messages.  In PDC and PHS, many short text message services have been introduced. However, due to various technical limitations in the existing wireless and wireline interface, it is difficult in the 2G to handle any multimedia message containing huge application data (still picture, video, audio sound, etc.).  
On the other hand, in the Internet a lot of multimedia application and data are frequently exchanged. This movement is accelerated day by day, nowadays many people can enjoy making some short “video clip” message on the PC and send it to their friends via the Internet very easily.  It is clear that the 3G system has to have enough capability to support those huge/complicated user data and provide sophisticated application/tool/platform for user to do that.
   In order to achieve the above requirements, we believe that:
 (1) We should discuss first about the concept of MMS to have a common view of it.
 (2) According to the discussed concept, we should find out general (common) requirements for MS.

Basic Concept of MMS 

  To start discussion about MMS, we would like to present our view as example.
Existing many “messaging service” support only short and plane text delivery.  But many people would like to communicate with other people via various media, not only text, but also video, still picture, audio sound, complex document and etc. In addition, many people would like to draft, edit, send, receive and see (or listen?) those complicated messaging without any special skill to handle a lot of commands or function.  MMS should consist of many “media” as much as possible if user wants, then it should be handled very easily.
Figure 1 presents a basic architecture of MMS.

How to support MMS 

   In this chapter, we would like to describe some basic requirements for MMS.

MS Ability Profile
   If we send some “MMS” from MS to our friends, they can receive and read/see/listen it?  It depends ability of their MS. If MS who has enough function (application) to handle it receives MMS; the received MMS can be displayed or decoded appropriately. But, if MS has not enough capability to support MMS, the delivered MMS should become no meaning message or clashed data.  To avoid such “mismatch”, MMS sender should know or confirm the ability of receiver.  If all MS have standardised “MS Ability Profile” and disclosed to the others (or system), this pre-confirmation can be achieved.

Internet

Send/Receive
Multimedia Message

MMSC

Send/Receive
Multimedia Message

PDA

IP, etc

MS

WAP/SMS/IP, etc

Integrated MS

Send/Receive
Multimedia Message

Send/Receive
Multimedia Message

IP, etc

PC/DTE

Figure 1.  The MMS architecture (concept overview)

IP support
   In the Internet world, any data are exchanged as IP packet.  We can say that major multimedia application should have a compatibility with IP.  In order to follow and support that Internet application, MMS should be designed based upon IP.

Data Completion
   It is considered that MMS requires huge binary data (around X Mbps).  To send such huge data efficiently, the air interface or MMSC has to provide some data completion function.   

IMAP like message control
   Multimedia message may have huge binary data (ex. more than 1M byte) or include unexpected message (push message for advertisement).  Therefore end user should want to decide which message should be received (downloaded/pulled from MMSC).  In the Internet, “IMAP” protocol provides smart service that, IMAP mail server shows header Information of received e-mail, then user can select which mail should be downloaded to local terminal.  In the MMS, we believe same type service should be provided by MMSC.

The Way Forward

T2-SWG3 needs to discuss what is needed from Multimedia Messaging for 3G and decide on the way forward for this.