Mobile Messaging

PART 5
MMS Architecture and
Transaction Flows
G. Le Bodic
Part 5
1

Course Contents
Part 1
Introduction to mobile communications networks

Day 1

Part 2
Standardization
Part 3
Messaging Services in Europe and elsewhere
Part 4
Short Message Service

Part 5
MMS: Architecture and Transaction Flows

Day 2

Part 6
MMS: Design of multimedia content and application
development
Part 7
Mobile Email

Part 5
2

Part 8
Instant Messaging and IMS Messaging

Part. 5

Architecture of MMS

Part 5
3

MMS Architecture and

Transactions Flows

Interfaces
MMS centre
MMS client
Transcoder
User directory

WAP 1.x realisation of MMS

MMS interfaces
Content adaptation
Phone capabilities
Charging
Streaming (RTP and RTSP)

Transaction Flows:
Nominal use cases
MM1 interface (MMS client to MMSC)
MM4 interface (MMSC to MMSC)
MM7 interface (MMSC to VAS application)

MMS architecture

Part 5
4

MMS interfaces (1/3)

The MM1 interface is a key interface in the MMS
environment. It allows interactions between the MMS
client, hosted in the mobile device, and the MMSC.
The MM2 interface is the interface between the two
internal elements composing the MMSC: the MMS
server and the MMS relay. Most commercial solutions
offer a combined relay and server in the form of an
MMSC.

Part 5
5

The MM3 interface is the interface between an MMSC

and external servers. Transactions invoked over this
interface allow the exchange of messages between
MMSCs and external servers such as email servers and
SMS Centres (SMSCs).

MMS interfaces (2/3)

The MM4 interface is the interface between two
MMSCs. This interface is necessary for exchanging
multimedia messages between distinct MMS
environments (e.g. between two distinct mobile
networks).
The MM5 interface enables interactions between the
MMSC and other network elements. For instance, an
MMSC can request routing information from the Home
Location Register (HLR) or from a Domain Name Server
(DNS).
The MM6 interface allows interactions between the
MMSC and user databases (e.g. presence server). The
Part 5
6

MMS interfaces (3/3)

The MM7 interface fits between the MMSC and external
Value Added Service (VAS) applications. This interface
allows a VAS application to request services from the
MMSC (message submission, etc.) and to obtain
messages from remote MMS clients.
The MM8 interface enables interactions between the
MMSC and a billing system. 3GPP has standardized
Charging Data Records (CDR) that are generated by the
MMSC on the occurrence of certain events (e.g.
message submission, message retrieval, etc.).
Part 5
7

MMS centre

Part 5
8

MMSC is responsible for handling transactions from MMS phones

and transactions from other messaging systems (e.g. other MMS
systems, email systems, etc.).

MMSC is also in charge of temporarily storing messages that are

awaiting retrieval from recipient MMS clients.

MMSC may also support a persistent message store where users

can store messages persistently in their MMBoxes.

MMSC may rely on the WAP content negotiation mechanism to

adapt multimedia messages to the capabilities of receiving devices.

MMSC performance

The typical measure of performance for an MMSC is the message

per second, abbreviated MPS.

The definition of MPS must include the definition of a traffic model:

Percentage of mobile originated traffic to MM1, MM3, MM4, etc.
Percentage of traffic requiring transcoding
Size and message contents
Percentage of prepaid/postpaid customers, etc.

Part 5
9

For large networks, the MMSC can face peak loads of several
hundreds of MPS (Christmas, goal alert, etc.).

MMS client
MMS-enabled mobile devices and which offers
the following features:

Management of message, notification and reports

Message composition
Message rendering
Configuration of MMS preferences and connectivity
parameters
Handling of a remote message box

Digital cam era

built into the
MMS phone

Part 5
10

Transcoder
The MMSC can request an external Transcoder to
convert media objects to other content types (content
adaptation to recipient capabilities).
The Standard Transcoding Interface (STI) bridging the
MMSC and the Transcoder is based on:
Messages (business logic in the Transcoder)
Media objects (business logic in the MMSC)

Two classes of degradation due to transcoding activities:

Minor degradation
Major degradation
Part 5
11

User repository
The user directory can be a database internal or
external to the MMSC.
External repositories are typically implemented as
LDAP directories.
For large networks, the user repository can hold
information for several millions MMS subscribers.

Part 5
12

WAP 1.x realisation of MMS

Part 5
13

Content adaptation

Part 5
14

Content adaptation
Attribute name

Part 5
15

Description

Examples

MmsMaxMessageSize

Maximum message size expressed in bytes.

30720

MmsMaxImageResolution

Maximum image dimensions expressed in

pixels.

640x480

MmsCCPPAccept

List of supported content types.

"image/jpeg", "audio/amr"

MmsCCPPAcceptCharSet

List of supported character sets.

"US-ASCII" or "ISO-8859-1"

MmsCCPPAcceptLanguage

List of supported languages.

"en", "fr"
for, respectively, English and
French.

MmsCCPPAcceptEncoding

List of supported transfer encoding methods.

"base64", "quoted-printable".

MmsVersion

List of supported MMS version.

"1.0", "1.1"

MmsCCPPStreamingCapable

Whether or not the MMS client supports

streaming

"Yes" or
"No"

MmsSmilBaseSet

List of supported SMIL profiles supported by the

MMS client:
SMIL-CONF-1-2 for the SMIL profile

defined in [OMA-MMS-Conf] version 1.2

SMIL-3GPP-R4 for the SMIL profile

defined in [3GPP-26.234] Release 4
SMIL-3GPP-R5 for the SMIL profile

defined in [3GPP-26.234] Release 4

"SMIL-CONF-1-2", "SMIL-3GPPR4".

MmsContentClass

List of message content classes supported by

the MMS client:
TX for the text class

IB for the image basic class

IR for the image rich class

VB for the video basic class

VR for the video rich class

"TX", "IB", "IR".

MmsSuppressionContentAdaptation

Request that MMSC performs no content

adaptation.

"Yes" or
"No"

Content adaptation: UAProf (1/3)

List of phone capabilities (as advertised in user agent profiles)

available from lecturers website (121 phones).

Part 5
16

http://www.lebodic.net/mms_resource.htm

Content adaptation:
UAProf (2/3)

<?x ml vers ion="1.0"?>

<RDF xmlns ="http://www.w3.org/1999/02/22-rdf-s y ntax -ns#" x mlns :rdf="http://www.w3.org/1999/02/22-rdfs y ntax -ns#" x mlns:prf="http://www.wapforum.org/UAPROF/c cpps c hema-20010430#">
<rdf:Desc ription ID="Profile">
<prf:component>
<rdf:Des cription ID=" HardwarePlatform ">
...
</rdf:Des cription>
</prf:c omponent>
<prf:component>
<rdf:Des cription ID=" SoftwarePlatform ">
...
</rdf:Des cription>
</prf:c omponent>
<prf:component>
<rdf:Des cription ID=" NetworkCharacteristics ">
...
</rdf:Des cription>
</prf:c omponent>
<prf:component>
<rdf:Des cription ID=" BrowserUA ">
...
</rdf:Des cription>
</prf:c omponent>
<prf:component>
<rdf:Des cription ID=" WapCharacteristics ">
...
</rdf:Des cription>
</prf:c omponent>
<prf:component>
<rdf:Des cription ID=" MMSCharacteristics ">
<rdf:ty pe res ourc e="http://www.wapforum.org/profiles/MMS/c cpps c hema20010111#MMSCharac teris tics " />
<prf:Mms Max Mes s ageSiz e> 30720</prf:Mms MaxMess ageSiz e>
<prf:Mms Max ImageRes olution> 640x480</prf:Mms MaxImageRes olution>
<prf:Mms Vers ion> 1.0</prf:MmsVers ion>
<prf:Mms Cc ppAc c ept>
<rdf:Bag>
<rdf:li> image/jpg </rdf:li>
<rdf:li> image/gif </rdf:li>
<rdf:li> image/png </rdf:li>
<rdf:li> image/bmp </rdf:li>
<rdf:li> image/vnd.wap.wbmp </rdf:li>
<rdf:li> application/smil </rdf:li>
<rdf:li> audio/amr </rdf:li>
<rdf:li> audio/midi </rdf:li>
<rdf:li> text/plain </rdf:li>
<rdf:li> text/x-vCard</rdf:li>
<rdf:li> text/x-vCalendar </rdf:li>
</rdf:Bag>
</prf:Mms Cc ppAc c ept>
<prf:Mms Cc ppAc c ept-Chars et>
<rdf:Bag>
<rdf:li> US-ASCII </rdf:li>
<rdf:li> UTF-8</rdf:li>
<rdf:li> UTF-16</rdf:li>
</rdf:Bag>
</prf:Mms Cc ppAc c ept-Chars et>
<prf:Mms SmilBas eSet>
<rdf:Bag>
<rdf:li> SMIL-CONF-1-2 </rdf:li>
</rdf:Bag>
</prf:Mms SmilBas eSet>
<prf:Mms ContentClas s>
<rdf:Bag>
<rdf:li> TX </rdf:li>
<rdf:li> IB </rdf:li>
</rdf:Bag>
</prf:Mms ContentClass >
</rdf:Des cription>

Part 5
17

</prf:c omponent>
</rdf:Des cription>
</RDF>

Content adaptation: UAProf (3/3)

Part 5
18

http://www.sonyericsson.com/UAProf/T610R301.xml

Streaming

Part 5
19

Streaming protocols: RTP

The Real-Time Transport Protocol (RTP) is a generic
transport protocol allowing the transfer of real-time data
from a server.
This communication enables the delivery of streamable
content, stored in the media server, to the MMS client in
streaming mode.
RTP usually relies on the connection-less User
Datagram Protocol (UDP) (itself relying on the IP
protocol).
RTP is defined by the IETF in RFC-1889.
RTP offers the following functions
Part 5
20

Sequence numbering
Time-stamping
Payload-type identifier

Streaming protocols: RTSP

Part 5
21

With the Real-Time Streaming Protocol (RTSP), the

MMS client can control the way the streamable content
is delivered from the media server.
The MMS client instructs the media server to start,
pause and play the message content during the content
delivery and rendering.
In other words, with RTSP, the MMS client can control
the content delivery from the media server in the same
way as a person controls a VCR with a remote
controller.
This is why RTSP is sometimes
known as a network remote control
for multimedia servers.
RTSP is defined by the IETF in RFC-2326.

Event

Charging

Interface

Category

Message submission

MM1

Originator

O1S-CDR

Forward request

MM4

Originator

O4FRq-CDR

Forward response

MM4

Originator

OFRs-CDR

Delivery report

MM4

Originator

O4D-CDR

Delivery report

MM1

Originator

O1D-CDR

Read-reply report

MM4

Originator

O4R-CDR

Read-reply originator

MM1

Originator

O1R-CDR

n/a

Originator

OMD-CDR

Message forward

MM4

Recipient

R4F-CDR

Notification request

MM1

Recipient

R1NRq-CDR

Notification response

MM1

Recipient

R1NRs-CDR

Message retrieval

MM1

Recipient

R1Rt-CDR

Acknowledgement

MM1

Recipient

R1A-CDR

Delivery report request

MM4

Recipient

R4DRq-CDR

Delivery report response

MM4

Recipient

R4DRs-CDR

Read-reply recipient

MM1

Recipient

R1RR-CDR

Read-reply report request

MM4

Recipient

R4RRq-CDR

Read-reply report response

MM4

Recipient

R4RRs-CDR

Recipient message deletion

n/a

Recipient

RMD-CDR

Forwarding

n/a

Forwarding

Message store

MM1

MMBox

Bx1S-CDR

Message view

MM1

MMBox

Bx1V-CDR

Message upload

MM1

MMBox

Bx1U-CDR

Message deletion

MM1

MMBox

Bx1D-CDR

Message submission

MM7

VAS

MM7S-CDR

Delivery request

MM7

VAS

MM7DRq-CDR

Delivery response

MM7

VAS

MM7DRs-CDR

Message cancel

MM7

VAS

MM7C-CDR

Message replace

MM7

VAS

MM7R-CDR

Delivery report request

MM7

VAS

MM7DRRq-CDR

Delivery report response

MM7

VAS

MM7DRRs-CDR

Read report request

MM7

VAS

MM7RRq-CDR

Originator message deletion

Charging Data
Records (CDRs)
are generated
by the MMSC
on occurrence
of predefined
events.

Part 5
22

CDR name

F-CDR

Transactions Flows

Nominal use cases

MM1 interface (MMS client to MMSC)
MM4 interface (MMSC to MMSC)
MM7 interface (MMSC to VAS application)
Standard implementation of MM7
Alternative proprietary implementations

Part 5
23

Person to person (1/2)

Exchange of a message in the same MMS
environment.

Part 5
24

Person to person (2/2)

Exchange of a message between two distinct
MMS environments.

Part 5
25

Content to person (2/2)

Exchange of a message between a value-added
service provider and a mobile user, and viceversa.

Part 5
26

MM1 interface

MM1 interface allows

interactions between
the MMS client and the
MMSC:

Three types of PDUs can be invoked over the MM1 interface:

Request: Name of a request PDU is suffixed with .req (e.g. Msend.req).
Confirmation/response: Name of a confirmation PDU is suffixed
with .conf (e.g. M-send.conf).
Indication: Name of an indication PDU is suffixed with .ind (e.g. Mnotification.ind). An indication is not confirmed.

Part 5
27

MM1: protocol data units

Transaction
Message submission

Notification

Message retrieval

Delivery report
Read report

Message forward
Message store or update
into MMbox
View contents of MMbox

Message upload to MMbox

Part 5
28

Message deletion from

MMbox

PDU name

Description

From
OMA

M-send.req

Message submission request

M-send.conf

Message submission confirmation

M-notification.ind

Message notification indication

M-notifyresp.ind

Message notification response indication

WSP/HTTP GET.req

Message retrieval request

M-retrieve.conf

Message retrieval confirmation

M-acknowledge.ind

Message retrieval acknowledgement indication

1.0

M-delivery.ind

Delivery report indication

1.0

M-read-rec.ind

Read report indication (recipient MMSE)

M-read-orig.ind

Read report indication (originator MMSE)

M-forward.req

Message forward request

M-forward.conf

Message forward confirmation

M-Mbox-Store.req

MMbox message store/update request

M-Mbox-Store.conf

MMbox message store/update confirmation

M-Mbox-View.req

MMbox contents view request

M-Mbox-View.conf

MMbox contents view confirmation

M-Mbox-Upload.req

MMbox message upload request

M-Mbox-Upload.conf

MMbox message upload confirmation

M-Mbox-Delete.req

MMbox message deletion request

M-Mbox-Delete.conf

MMbox message deletion confirmation

1.0

1.0

1.0

1.1

1.1

1.2

1.2

1.2

1.2

MM1: message submission

Part 5
29

In WAP technical realizations of MMS, the mobile device

establishes a data connection with the network. This allows the
MMS client to communicate with the MMSC.

This data connection can rely on a circuit-switched data connection

(e.g. GSM) or a packet switched connection (e.g. GPRS).

The connection is typically established through a WAP gateway in a

WAP 1.x configuration

MM1: submission request (1/2)

From
OMA

St.

MMS protocol data unit type. Value: M-send-req

1.0

X-Mms-Transaction-ID

Unique identifier for the submission transaction.

1.0

X-Mms-MMS-Version

MMS protocol version such as 1.0, 1.1 or 1.2.

1.0

Date

Date and time of message submission.

1.0

From

Address of the originator MMS client (phone number or email address) or 'insert token' if the
originator address is to be provided by the MMSC.

1.0

To

One or multiple addresses (phone number or email address) for message recipient(s). Primary
recipients.

1.0

Cc

One or multiple addresses (phone number or email address) for message recipient(s). Secondary
recipients.

1.0

Bcc

One or multiple addresses (phone number or email address) for message recipient(s). Secondary
recipients / blind copy.

1.0

Subject

A short textual description for the message.

1.0

X-Mms-Message-Class

Message class such as 'auto' (automatically generated by the MMS client), 'personal' (default),
'advertisement' and 'informational'. Other classes can also be defined in the form of text
strings.

1.0

X-Mms-Expiry

Expiry date. Default value for this parameter is 'maximum'.

1.0

X-Mms-Delivery-Time

Earliest delivery time. Default value for this parameter is 'immediate delivery'.

1.0

X-Mms-Priority

Priority such as 'low', 'normal' (default) or 'high'.

1.0

1.0

1.0

Parameter name

Description

X-Mms-Message-Type

X-Mms-Sender-Visibility

Part 5
30

X-Mms-Delivery-Report

Visibility of the sender address. This parameter is either set to 'show' (default) for showing the sender
address to recipient(s) or 'hide' for hiding the sender address to recipient(s). From MMS 1.2,
'show' is not anymore the default value for this parameter. If this parameter is not present in
an MMS 1.2 PDU, then network preferences for the sender anonymity feature are used.
Request for a delivery report. This parameter indicates whether or not delivery report(s) are to be
generated for the submitted message. Two values can be assigned to this parameter: 'yes'
(delivery report is to be generated) or 'no' (no delivery report requested). If the message class
is 'auto', then this parameter is present in the submission PDU and is set to 'no'.

MM1: submission request (2/2)

X-Mms-Read-Report

Request for a read report. This parameter indicates whether or not read reports are
to be generated for the message. Two values can be assigned to this parameter:
'yes' (read report is to be generated) or 'no' (no read report requested). If the
message class is auto, then this parameter is present in the submission PDU and is
set to 'no'.

1.0

X-Mms-Reply-Charging

Request for reply charging. The presence of this parameter indicates that reply
charging is requested by the message originator. Two values can be assigned to this
parameter: 'requested' when the originator is willing to pay for the message reply(s)
or 'requested text only' when the originator is willing to pay for message reply(s)
containing text only. In any case, two parameters (reply message size and reply
deadline) specify conditions for the message reply to be paid for by the originator.

1.1

X-Mms-Reply-Charging-Deadline

Reply charging deadline. This parameter specifies the latest time for the
recipient(s) to submit a message reply. This parameter is only present in the PDU if
reply charging is requested.

1.1

X-Mms-Reply-Charging-Size

Reply charging maximum message size. This parameter specifies the maximum
size for message replies. This parameter is only present in the PDU if reply charging
is requested.

1.1

Reply charging identification. This parameter is inserted in a reply message only

and refers to the original message identifier (Message-ID parameter).

1.1

X-Mms-Store

MMBox storage request - This parameter indicates whether the originator MMS client
requests to save the message in the originator's MMBox in addition from sending it.

1.2

X-Mms-MM-State

MMBox message state When X-Mms-Store is set to 'yes', this parameter indicates the
message state in the originator's MMBox (e.g. sent, draft, etc.). If X-Mms-Store is set to
'yes' and if this parameter is not present then the message default state is 'sent'.

1.2

X-Mms-MM-Flags

MMBox message flag This parameter indicates the list of flags associated to a
message stored in the MMBox (considered only if X-Mms-Store is set to 'yes').

1.2

Content-Type

Content type of the multimedia message.

(e.g. application/vnd.wap.multipart.related).

1.0

X-Mms-Reply-Charging-ID

Part 5
31

MM1: submission response

From
OMA

St.

MMS protocol data unit type. Value: M-send-conf

1.0

X-Mms-Transaction-ID

Unique identifier for the submission transaction. The same as the one for the
corresponding submission request.

1.0

X-Mms-MMS-Version

MMS protocol version such as 1.0, 1.1 or 1.2.

1.0

X-Mms-Response-Status

Status code for the submission transaction. The submission request can be accepted
or rejected (permanent or transient errors). See status codes in Appendix B.

1.0

X-Mms-Response-Text

Human readable description of the transaction status.

1.0

Message unique identifier. This identifier is always provided by the MMSC if the
submission request is accepted.

1.0

1.2

1.2

1.2

Parameter name

Description

X-Mms-Message-Type

Message-ID

X-Mms-Content-Location

X-Mms-Store-Status

Part 5
32

X-Mms-Store-Status-Text

Reference to the message stored in the MMBox - This parameter is present only if
the three following conditions are fulfilled:
- the originator MMSC supports the MMBox feature
- the X-Mms-Store parameter was present in the corresponding submission request
- the X-Mms-Store-Status indicates 'success'
When available, this parameter provides a reference to the message stored in the
MMBox (reference used later for message retrieval or view request).
MMBox message status - This parameter is present only if the two following
conditions are fulfilled:
- the originator MMSC supports the MMBox feature
- the X-Mms-Store parameter was present in the corresponding submission request
When available, this parameter indicates whether or not the submitted message has
been successfully stored in the MMBox. See status codes in Appendix D.
MMBox message textual status - Textual description qualifying the value assigned to
the X-Mms-Store-Status parameter.

MM1: WAP encapsulation

Part 5
33

Request and response PDUs are transferred from the MMS client
to the MMSC as part of a WSP/HTTP Post request:

At the WSP/HTTP layer, an MMS PDU is marked with the

following content type:
application/vnd.wap.mms-message

MM1: Binary encoding

MMS standards published by OMA define an encoding of MMS

PDUs. For instance a submission PDU (message sending) is
encoded as follows:
X-Mms-Message-Type: M-send.req
X-Mms-Transaction-ID: 0123456789
X-Mms-MMS-Version: 1.0 From: +33144556677/TYPE = PLMN
To: +33111223344/TYPE = PLMN
Subject: A stay in Velen.
Content-type: application/vnd.wap.multipart.related
start = <0000>
type = application/smil
Message
type

From
To
Subject

Content type
and contents

Part 5
34

Transaction id.

Version

MM1: message notification (1/3)

Notification that a message is awaiting retrieval.

Two transaction flows:

Immediate retrieval
Deferred retrieval

Part 5
35

MM1: message notification (2/3)

Upon receipt of the notification, the MMS client can
perform the following actions:
Message rejection: The message is rejected without being
retrieved by the recipient MMS client.
Immediate message retrieval: The message is immediately
retrieved without user explicit request.
Indication message awaiting retrieval: The MMS client notifies the
user that a message awaits retrieval. In this mode, the user can retrieve the message
later at his/her own convenience (deferred message retrieval). With the notification, the
user also has the possibility of forwarding the message to other recipients without having
to retrieve the message first (from MMS 1.1 only). The user can also instruct the MMS
client to delete the notification.

Part 5
36

An important parameter of the notification indication

PDU is the X-Mms-Content-Location parameter. It
indicates the location from which the message can be
retrieved. For instance:
http://mmsc.vodafone.com/message-id-634

MM1: message notification (3/3)

The notification is typically encoded as part of one or
two SMS messages (WAP push).
Alternatively, the WAP push can directly been delivered
via an already opened GPRS session.
X-Mms-Message-Type: M-notification.ind
X-Mms-Transaction-ID: Transaction-123456789-abcdefg
X-Mms-MMS-Version: 1.0
From: +336666666666/TYPE=PLMN
X-Mms-Message-Class: Personal
X-Mms-Message-Size: 120
X-Mms-Expiry: 172800
X-Mms-Content-Location:
http://mms.vodafone.com:8002/message-123456

Part 5
37

TP-Protocol-Identifier: 0x00
TP-Data-Coding-Scheme: 8-bit data.
TP-User-Data: as shown below

MM1: message retrieval (1/2)

Retrieval of the multimedia message from the MMSC.
Prerequisite: notification has been sent out.
Alternatively, the WAP push can directly been delivered
via an already opened GPRS session.

Part 5
38

MM1: message retrieval (2/2)

As for the notification, two transaction flows:
Immediate retrieval
Deferred retrieval

Part 5
39

MM1: delivery report (1/2)

During message submission, the originator MMS client has the possibility of requesting the generation of delivery
report(s) for the submitted message.
If such a request has been made, a delivery report is generated for each one of the message recipients on the
occurrence of the following events:

Part 5
40

Message has been successfully retrieved by the recipient MMS client.

Message has been deleted (e.g. validity period has expired).
Message has been rejected by the recipient MMS client.
Message has been forwarded by the recipient MMS client.
Message status is indeterminate (e.g. message has been transferred to a messaging system where the concept of delivery report is not
fully supported).

MM1: delivery report (2/2)

As the notification, the delivery report is provided as
part of a WAP push (typically conveyed as an SMS).

Part 5
41

Parameter name

Description

From
OMA

St.

X-Mms-Message-Type

MMS protocol data unit type. Value: M-delivery-ind

1.0

X-Mms-MMS-Version

MMS protocol version such as 1.0, 1.1 or 1.2.

1.0

Message-ID

Identifier of the message to which the report relates. This

identifier is used for correlating the delivery report with
the original message.

1.0

To

Address of the message recipient.

1.0

Date

Date and time the message was retrieved, has expired, etc.

1.0

X-Mms-Status

Status of corresponding message such as 'expired',

'retrieved', 'rejected', 'forwarded', or 'indeterminate'.

1.0

MM1: read report (1/2)

During message submission, the originator MMS client has the possibility
of requesting the generation of read report(s) for the submitted message.
If such a request has been made, a read report may be generated for each
one of the message recipients on the occurrence of the following events:
Message has been read.
Message has been deleted without being read.

Part 5
42

MM1: read report (2/2)

The MMS client can generate the read report according to two different methods:
The first method, introduced in MMS 1.0, lets the MMS client submit a normal message addressed
to the message originator with the M-send.req PDU over the MM1 interface.
The second method, applicable from MMS 1.1, consists in using a set of two MM1 PDUs dedicated
to read reports.

Part 5
43

MM1: message forward (1/2)

Once a notification has been received by the recipient MMS client, the
user has the possibility to retrieve or reject the corresponding message.
In addition, from MMS 1.1, the recipient MMS client may also support the
forward of a message that has not yet been retrieved from the MMSC.

Part 5
44

MM1: message forward (2/2)

The MMSC can assign the previous address assigned to the From parameter to a new instance of the X-MmsPreviously-Sent-By parameter and associates a sequence number to this parameter.
Example:

A date of forward is also associated to each message forwarder.

This information can be presented to the subsequent recipients of the message.

X-Mms-Previously-Sent-By: 0, Gwenael <[email protected]>

X-Mms-Previously-Sent-By: 1, +33612345678/TYPE=PLMN
X-Mms-Previously-Sent-By: 2, +33698765432/TYPE=PLMN

Part 5
45

MM1: multimedia message boxes

Several additional MM1 protocol data units:

Store message in MMBox: MMS client instructs the MMSC

to store a message, which has yet to be retrieved, in the
MMBox.
Update message in MMBox: The MMS client instructs the
MMSC to update the state and/or flags of a message in the
MMBox.

Part 5
46

MMS client has the possibility to

upload a message in the MMBox

MMS client request information

about one or more multimedia
messages that are stored in the
users MMBox

MMS client has the possibility to

delete one or more messages from
the MMBox with a single transaction

MM4 interface

Part 5
47

MM4 interface allows

interactions between
two MMSCs.

Interactions between
two MMSCs are required
for Interconnect but not
for Roaming.

Transactions specified for the MM4 interface are conveyed over

the Simple Mail Transfer Protocol (SMTP):

MM4: protocol data units

MM4 interface has 6 PDUs
Transaction
Routing forward a
message.
Routing forward a
delivery report
Routing forward a
read report

PDU name

Description

MM4_forward.REQ

Message forward request

MM4_forward.RES

Message forward confirmation

MM4_delivery_report.REQ

Request for delivery report forward

MM4_delivery_report.RES

Confirmation for delivery report forward

MM4_read_reply_report.REQ

Request for read report forward

Confirmation for read report forward

From
3GPP

Rel-4

Rel-4

Rel-4

SMTP is a basic protocol for exchanging messages between Mail User

Agents (MUAs).
In the Internet domain, SMTP has become the de facto email transfer
protocol for exchanging messages.
Specifications of SMTP have been published by the Internet Engineering
Task Force (IETF) in [RFC-2821] ([RFC-2821] obsoletes [RFC-821]).

Part 5
48

MM4_read_reply_report.RES

Message routing over MM4 (1/2)

The originator MMSC has to determine the IP address of the recipient

MMSC in order to route the message with SMTP.

IMSI-based method: compliant with the Mobile Number Portability (MNP)

requirements. Steps:
1. MMSC interrogates the recipient HLR in order to get the IMSI of recipient phone
number (via MM5 interface).
2. With the IMSI, the originator MMSC extracts the Mobile Network Code (MNC)
and the Mobile Country Code (MCC).
3. With the MNC and MCC, the originator MMSC obtains the recipient MMSC
FQDN by interrogating a local database (look-up table or constructing it via
GSMA naming convention).
4. With the MMSC FQDN, the originator MMSC retrieves the MMSC IP address by
interrogating the DNS.

Part 5
49

Unbundling is performed by the MMSC.

Message routing over MM4 (2/2)

Physical connection enabling MM4 interworking typically relies

on:
National leased lines (for national interworking)
IP-VPN over the Internet
GPRS Roaming Exchange (GRX) services

Application-level (MM4) topology relies on:

Peering: proven for national interworking but does not scale well for
international interworking.
Hub concept: not proven yet but is expected to facilitate MMS
international interworking.

Part 5
50

MM4: Transaction flows

Six PDUs for three MM4 transactions:

Forward of message
Response is optional

Delivery report
The different delivery states that can be
reported over the MM4 interface are as
follows:

Expired
Retrieved
Deferred

- Indeterminate
- Forwarded
- Unrecognized.

Read report
The different read states that can be
reported over the MM4 interface are as
follows:

Part 5
51

Read
Deleted without being read.

MM4: example

Part 5
52

MM7 interface

Part 5
53

MM7 interface allows

interactions between
the MMSC and applications of value-added
service providers.

MM7 is realised with

SOAP requests over
the HTTP protocol:

MM7: protocol data units

MM7 interface has 14 PDUs for 8 transactions:
Transaction

Description

MM7_submit.REQ

Message submission request

MM7_submit.RES

Message submission response

MM7_deliver.REQ

Message delivery request

MM7_deliver.RES

Message delivery response

MM7_cancel.REQ

Message cancellation request

MM7_cancel.RES

Message cancellation response

MM7_replace.REQ

Message replacement request

MM7_replace.RES

Message replacement response

MM7_delivery_report.REQ

Delivery report request

MM7_delivery_report.RES

Delivery report response

MM7_read_reply_report.REQ

Read report request

MM7_read_reply_report.RES

Read report response

MMSC error

MM7_RS_error.RES

Error indication from the MMSC to the VAS application

Rel-5

VASP error

MM7_VASP_error.RES

Error indication from the VAS application to the MMSC

Rel-5

Message submission

Message delivery

Cancellation

Replacement

Delivery report

Read report

Part 5
54

From
3GPP

PDU name

Rel-5

Rel-5

Rel-5

Rel-5

Rel-5

Rel-5

MM7: SOAP over HTTP

Part 5
55

MM7 interface is published by 3GPP TS 23.140

(from Release 5).

MM7 is based on the Simple Object Access Protocol (SOAP) with HTTP at the transport
layer.

Proprietary MM7 implementations rely on the transfer of proprietary commands over either
SMTP or HTTP.

SOAP messages are structured according to SOAP technical specifications published by

W3C.

Several versions of the schema

for the MM7 interface are
available and each one
corresponds to a specific
version of the 3GPP standard:
Schema name

Corresponding version
of [3GPP-23.140]

REL-5-MM7-1-0

v5.3.0

REL-5-MM7-1-1

v5.4.0

REL-5-MM7-1-2

v5.5.0

REL-5-MM7-1-3

v5.6.0

http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/

MM7: Introduction to SOAP

SOAP is a lightweight protocol for the exchange of information in distributed

environments such as the MMSE.

All SOAP messages are represented using XML.

SOAP specifications consist of three distinct parts:

Part 5
56

Envelope

Set of encoding rules

Convention for representing remote procedure calls

SOAP may be used over a variety of transport protocols. In the MMSE, for the
realization of the MM7 interface, SOAP is used over the HTTP transport
protocol.

MM7: Introduction to SOAP

Part 5
57

A SOAP message, represented using XML, consists of a SOAP

envelope, a SOAP header, a SOAP body and an optional SOAP
attachment.

For messages containing a SOAP envelope only, the media type

text/xml is used. If the SOAP message also contains an
attachment, then the media type multipart/related is used
and the SOAP envelope is identified with the Start parameter of
the Content-Type.

Each part of the SOAP message has, at least, the two

parameters Content-Type and Content-ID.

MM7: Introduction to SOAP

Part 5
58

MM7: graphical convention

Part 5
59

MM7: submission

Transaction flow

Response
Request

Part 5
60

MM7:
submission,
example
Request

Part 5
61

MM7: submission, example

Response

Part 5
62

MM7: delivery
Transaction flow
Request

Response

Part 5
63

MM7: cancel
Request

Response

Part 5
64

Transaction flow

MM7: replace

Transaction flow

Request

Part 5
65

Response

MM7: delivery report

Transaction flow

Request

Part 5
66

Response

MM7: read report

Transaction flow

Request

Part 5
67

Response

MM7: generic error handling

Transaction flows

Response

Part 5
68

MM7: Nokia implementation (1/2)

Part 5
69

External Application Interface (EAIF) enables multimedia

messaging services to be developed to the Nokia MMSC.

EAIF is Nokias proprietary MM7 interface.

The application may send charging information to the

MMSC as tariff classes. Based on the tariff classes, MMSC
will create charging data records for the subscriber.

In EAIF HTTP 1.1 is used. The POST method is used to

carry MMS messages and delivery reports to/from the
MMSC.

MM7: Nokia implementation (2/2)

Part 5
70

In EAIF, HTTP POST requests are used to carry the

MMS PDU, containing the MMS content, between the
MMSC and applications. HTTP headers and MMS
specific HTTP extension headers are used to carry some
additional data, e.g. routing information. MMS PDUs are
binary encoded accorting to the standards.

The operator may decide to utilize SSL in EAIF to secure

the MMS traffic between the MMSC and applications.
SSL can be used to both authentication and traffic
encryption. The supported versions in EAIF from SSL are
SSL 2 and SSL 3. Also TLS 1 can be used.