MMS is a method of communication by which you can exchange the non-text / multi-media contents. MMS can be implemented in various access technologies as follows.
- WCDMA
- LTE
- IMS
But core protocol sequence is basically same as shown in the examples in this page.
An MMS never travels as one message from the sender to the receiver. The network first tells the UE that a message is waiting, and the UE then fetches the content itself. On UMTS, the notice usually arrives as an SMS over the CS domain, while the content comes over a PS data connection. So one MT MMS log mixes SMS signalling with plain TCP traffic, and you need both parts to follow it. Let's first see how the pieces fit together, and then walk through two examples from a test setup.
- How does an MMS reach the UE ?
- Case 1 : MT MMS - No Delivery Report, No Read Report
- Case 2 : MO MMS - No Delivery Report, No Read Report
- Reference
How does an MMS reach the UE ?
Before reading the logs, it helps to know which messages MMS defines and which layer carries each one. The two examples on this page show only some of them. So this section lists the full set first and marks where each one appears in the examples.
3GPP TS 23.140 describes MMS in terms of abstract messages on the MM1 interface. MM1 runs between the MMS User Agent in the UE and the MMS Relay/Server in the network. For a message to the UE, the MMS Relay/Server first sends MM1_notification.REQ. This notification does not carry the content. Instead, it carries a Message Reference, which is a URI that points to the stored message. The UE answers the notification with MM1_notification.RES. When the UE wants the content, it sends MM1_retrieve.REQ to that reference, and the content comes back in MM1_retrieve.RES. For a message from the UE, the UE sends MM1_submit.REQ, and the MMS Relay/Server answers with MM1_submit.RES.
The abstract messages do not fix a transport. In the WAP/OMA implementation that the examples use, the notification is an m-notification-ind. It travels as a WAP Push inside an SMS, so it reaches the UE even when the UE has no PS connection. The retrieval and the submission run over HTTP on a PS connection. The table below maps each abstract message to the examples.
Abstract message |
Direction |
Where it shows on this page |
MM1_notification.REQ |
MMS Relay/Server to UE |
Case 1, step 04 : m-notification-ind in a WAP Push SMS |
MM1_notification.RES |
UE to MMS Relay/Server |
Not shown in the Case 1 capture |
MM1_retrieve.REQ |
UE to MMS Relay/Server |
Case 1, steps 09 to 11 : HTTP GET to the X-Mms-Content-Location |
MM1_retrieve.RES |
MMS Relay/Server to UE |
Case 1, steps 09 to 11 : HTTP/1.0 200 OK with the content |
MM1_acknowledgement.REQ |
UE to MMS Relay/Server |
Sent only if the MMS Relay/Server requests it; not shown |
MM1_submit.REQ and MM1_submit.RES |
UE to MMS Relay/Server, and back |
Case 2 : MO MMS over IP data |
Two reports are missing from the table on purpose. A delivery report tells the sender that the MM reached the recipient, and a read report tells the sender that the recipient opened it. Both examples on this page have neither, which is what "No Delivery Report, No Read Report" in their titles means. In the notification, the optional Delivery report IE is simply absent.
The notification and the content take different paths : The notification comes as an SMS on the CS domain, while the content comes over HTTP on the PS domain.The Message Reference links the two paths : The UE fetches the content from the URI in X-Mms-Content-Location, so a wrong address there breaks the retrieval, not the notification.An MO MMS needs no SMS at all : The UE submits the message directly over HTTP, so only the PS connection shows up in the log.
Case 1 : MT MMS - No Delivery Report, No Read Report
: This example is the case where MT MMS is performed with a UE Test Equipment (Anritsu MD8475 + NowSMS). The test equipment plays the UMTS network, and NowSMS plays the MMS Relay/Server. The sequence has two halves. Steps 04 to 07 deliver the notification as an MT SMS on the CS domain, and steps 09 to 11 download the content over the PS domain.
01) < In Idle Mode or In Connected Mode >
02) < Send a MMS (from Network) to Test UE >
03) < Various Protocol Sequence depending on Situation >
04) UE <- NW : downlinkDirectTransfer + SMS : CP-DATA
05) UE -> NW : uplinkDirectTransfer + SMS : CP-ACK
06) UE -> NW : uplinkDirectTransfer + SMS : CP-DATA
07) UE <- NW : downlinkDirectTransfer + SMS : CP-ACK
08) < You will see SMS(MMS Delivery Notification) on UE display >
09) < Open the SMS and Retrieve MMS Contents >
10) < Various Protocol Sequence to establish the connected that is required to download the contents >
Note : In this example, it is assumed that MMS Notification is done in single SMS. However, there are cases that the notification message is conveyed in multiple SMS (Concatenated SMS)
Why is one SMS enough here? A single SMS can carry at most 140 octets of user data. In this capture the TP-User-Data-Length is 139 octets, so the whole notification fits. A longer subject or a longer URI would push it over the limit. In that case the notification is split into a concatenated SMS, as the note above says.
Step 04 - UE <- NW : downlinkDirectTransfer + SMS : CP-DATA
This one message carries the whole notification. It is nested six layers deep. Read the decode from the top down: RRC, then the CM sublayer of 24.011, then the RP layer, then the SMS TPDU, then WAP, and finally the MMS header.
Decoded message from a test equipment log,
downlinkDirectTransfer: r3 (0)
r3
downlinkDirectTransfer-r3
rrc-TransactionIdentifier: 0
cn-DomainIdentity: cs-domain (0)
nas-Message: 0901a601000481999999009d440a81214365870900f54150...
GSM A-I/F DTAP - CP-DATA
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
0... .... = TI flag: allocated by sender
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-DATA (0x01)
CP-User Data
Length: 166
RPDU (not displayed)
GSM A-I/F RP - RP-DATA (Network to MS)
Message Type RP-DATA (Network to MS)
RP-Message Reference
RP-Message Reference: 0x00 (0)
RP-Originator Address - (999999)
Length: 4
1... .... = Extension: No Extension
.000 .... = Type of number: unknown (0x00)
.... 0001 = Numbering plan identification: ISDN/Telephony Numbering
(ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x01)
BCD Digits: 999999
RP-Destination Address
Length: 0
RP-User Data
Length: 157
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-DELIVER
0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER
.1.. .... = TP-UDHI: The beginning of the TP UD field contains a Header
in addition to the short message
..0. .... = TP-SRI: A status report shall not be returned to the SME
.... .1.. = TP-MMS: No more messages are waiting for the MS in this SC
.... ..00 = TP-MTI: SMS-DELIVER (0)
TP-Originating-Address - (1234567890)
Length: 10 address digits
1... .... : No extension
.000 .... : Type of number: (0) Unknown
.... 0001 : Numbering plan: (1) ISDN/telephone (E.164/E.163)
TP-OA Digits: 1234567890
TP-PID: 0
00.. .... : defines formatting for subsequent bits
..0. .... : no telematic interworking, but SME-to-SME protocol
...0 0000 : the SM-AL protocol being used between the SME and the MS (0)
TP-DCS: 245
1111 .... = Coding Group Bits: Data coding/message class (15)
1111 .... : Data coding/message class
.... 0... : Reserved
.... .1.. : Message coding: 8 bit data
.... ..01 : Message Class: Class 1 Default meaning: ME-specific
TP-Service-Centre-Time-Stamp
Year 14, Month 05, Day 28
Hour 23, Minutes 23, Seconds 39
Timezone: GMT + 5 hours 0 minutes
TP-User-Data-Length: (139) depends on Data-Coding-Scheme
TP-User-Data
User-Data Header
User Data Header Length (6)
IE: Application port addressing scheme, 16 bit address (SMS Control)
Information Element Identifier: 0x05
Length: 4
Destination port: 2948, As allocated by IANA (http://www.IANA.com/)
Originator port: 9200, As allocated by IANA (http://www.IANA.com/)
Wireless Session Protocol, Method: Push (0x06),
Content-Type: application/vnd.wap.mms-message
Transaction ID: 0xcd
PDU Type: Push (0x06)
Headers Length: 34
Content-Type: application/vnd.wap.mms-message
Headers
X-Wap-Application-Id: x-wap-application:mms.ua
MMS Message Encapsulation, Type: m-notification-ind
X-Mms-Message-Type: m-notification-ind (0x82)
X-Mms-Transaction-ID: 5386A6D4
X-Mms-MMS-Version: 1.0
From: 2580
Subject: MT MMS
X-Mms-Message-Class: Personal (0x80)
X-Mms-Message-Size: 780946
X-Mms-Expiry: 604800.000000000 seconds
X-Mms-Content-Location: http://192.168.1.2:7082/20140528/23/5386A6D3a.MMS
DL-DCCH (Hex) : 8D 6E 3C 4B 81 40 15 01 20 34 C0 20 00 90 33 33 33 20 13 A8 81 50 24 28 6C B0 E1 20 1E A8 2A 10 46 46 52 60 51 60 C0 A0 81 70 84 7E 19 A0 C4 4C 2E 0E 0D 8D 2C 6C 2E 8D 2D ED C5 EE CD CC 85 CE EC 2E 05 CD AD AE 65 AD AC AE 6E 6C 2C EC A0 15 F0 91 90 53 06 A6 67 06 C8 26 C8 86 80 11 B2 11 20 D0 06 46 A7 06 00 12 C9 AA 84 09 A9 AA 60 11 50 11 C0 61 7D 52 51 00B0 20 61 27 50 10 6D 0E 8E 8E 07 45 E5 E6 27 26 45 C6 26 C7 05 C6 25 C6 47 46 E6 07 06 45 E6 46 06 26 86 06 A6 47 05 E6 46 65 E6 A6 67 06 C8 26 C8 86 6C 25 C9 A9 AA 60 00
Let's peel the layers one at a time. The RRC DownlinkDirectTransfer only says that the NAS message belongs to the CS domain. Inside it, CP-DATA uses protocol discriminator 9 for SMS, and the TI flag is 0 because the network started this transaction. The RP-DATA inside CP-DATA carries the RP-Originator Address 999999, which is the address of the service centre, and the RP-Message Reference 0.
The TPDU is an SMS-DELIVER. TP-UDHI is 1, so the user data starts with a header. TP-SRI is 0, so the service centre will not get a status report. TP-DCS 245 is 0xF5, which means 8 bit data in message class 1. The user data header has one IE, 0x05, which is the application port addressing scheme with 16 bit addresses in 23.040. It sends the data to destination port 2948 from originator port 9200. Port 2948 is where the UE listens for WAP Push.
The WAP layer then marks the payload as application/vnd.wap.mms-message for the application mms.ua. So the UE passes it to its MMS client. The MMS header is an m-notification-ind, and its fields are the IEs of MM1_notification.REQ in 23.140. Message class, message size, time of expiry and the message reference are all mandatory there. You can find them in the capture as X-Mms-Message-Class, X-Mms-Message-Size, X-Mms-Expiry and X-Mms-Content-Location. The expiry of 604800 seconds is 7 days.
The screenshot below shows a notification of the same kind in the SMS editor of the test equipment. Colour marks link the decoded fields on the left to the bytes on the right. It is a different notification from the capture above, so its transaction IDs and time stamp differ.
Each decoded field of the notification comes from a fixed group of bytes, so the header can be checked by hand.
User Data Header 06 05 04 0B84 23F0 : 06 is the header length, 05 is the IE, 04 is the IE length, 0x0B84 is port 2948 and 0x23F0 is port 9200.CF 06 22 : These are the first bytes of the WAP part. CF is the Transaction ID, 06 is PDU Type Push and 0x22 is the Headers Length of 34.132 bytes, 1 SMS messages : The editor counts the payload after the user data header. 132 bytes plus the 7 header bytes give 139 octets, the same TP-User-Data-Length as in the capture.Originator Address 1234567890 : This becomes the TP-Originating-Address of the SMS-DELIVER. The MMS sender shown to the user comes from the From header instead, which is 2580 here.
Step 05 - UE -> NW : uplinkDirectTransfer + SMS : CP-ACK
CP-ACK only confirms that the CP-DATA arrived at the CM sublayer. It says nothing yet about whether the SMS was accepted. Without it, the network repeats the CP-DATA when the timer TC1* expires.
Decoded message from a test equipment log,
uplinkDirectTransfer
cn-DomainIdentity: cs-domain (0)
nas-Message: 8904
GSM A-I/F DTAP - CP-ACK
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-ACK (0x04)
UL-DCCH : E6 B5 20 99 8E C0 00 C4 82 00
The TI flag is now 1, because the UE answers inside a transaction that the network started. The TIO stays 0, so both messages belong to the same transaction.
Step 06 - UE -> NW : uplinkDirectTransfer + SMS : CP-DATA
This message is the real answer to the SMS. The UE puts an RP-ACK inside a new CP-DATA and tells the service centre that it has accepted the SMS-DELIVER.
Decoded message from a test equipment log,
uplinkDirectTransfer
cn-DomainIdentity: cs-domain (0)
nas-Message: 8901020200
GSM A-I/F DTAP - CP-DATA
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-DATA (0x01)
CP-User Data
Length: 2
RPDU (not displayed)
GSM A-I/F RP - RP-ACK (MS to Network)
Message Type RP-ACK (MS to Network)
RP-Message Reference
RP-Message Reference: 0x00 (0)
UL-DCCH : BE B2 EA 4F 96 C0 02 44 80 81 01 00 00
The RP-Message Reference is 0, the same value as in the RP-DATA of step 04. This is how the service centre matches the RP-ACK to the message it sent. The whole NAS message is only 5 octets, 89 01 02 02 00. Here 02 is the length and then the RP-ACK message type, and 00 is the message reference.
Step 07 - UE <- NW : downlinkDirectTransfer + SMS : CP-ACK
The network closes the SMS transaction with a CP-ACK for the CP-DATA of step 06. After this message, the notification has reached the UE, and the CS part of the sequence is over.
Decoded message from a test equipment log,
downlinkDirectTransfer: r3 (0)
r3
downlinkDirectTransfer-r3
rrc-TransactionIdentifier: 0
cn-DomainIdentity: cs-domain (0)
nas-Message: 0904
GSM A-I/F DTAP - CP-ACK
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
0... .... = TI flag: allocated by sender
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-ACK (0x04)
DL-DCCH :BA 21 1E 44 89 40 00 21 20 80
Step 08 - You will see SMS - MMS Delivery Notification - on UE display
Following is the SMS (MMS Delivery Message) shown on SamSung Galaxy 4 as an example. The UE does not show the WAP Push as a normal SMS. Its MMS client reads the notification and shows a new MMS entry instead.
In the screenshot below, the new entry is marked in red at the top of the message list.
The UE builds the list entry from the MMS header, not from the SMS header.
2580 : The sender is the From field of the m-notification-ind, not the TP-Originating-Address 1234567890 of the SMS.<MT MMS> : The second line is the Subject field of the notification.
Step 09 - Open the SMS and Retrieve MMS Contents
The notification only holds a reference, so the content still has to come down. The UE opens a PS connection and sends an HTTP GET to the URI in X-Mms-Content-Location.
< 10) < Various Protocol Sequence to establish the connected that is required to download the contents > >
< 11) < Downloading Contents > >
The packet list below is taken at the IP level. It starts after the PS connection is up, so the RRC and NAS messages that set up that connection are not in it. The UE at 192.168.1.11 talks to the MMS Relay/Server at 192.168.1.2 on port 7082, which is the port in the X-Mms-Content-Location.
The download is a plain HTTP transfer over TCP, and most of the packets are full size segments from the server.
SYN from 40486 to 7082 : The grey rows are SYN segments from the UE port 40486 to port 7082. With them, the UE opens the TCP connection.PSH, ACK with length 354 : This segment carries the HTTP GET shown below.ACK rows with length 1514 : These are the server segments that carry the MM content.FIN, ACK with Ack=781056 : The UE closes the connection after it has received the whole response.
TCP : From UE to MMS Center
Payload from a TCP capture,
GET /20140528/23/5386A6D3a.MMS HTTP/1.1??Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic??x-wap-profile: http://wap.samsungmobile.com/uaprof/SHV-E330S.xml??Accept-Language: ko-KR, en-US??Host: 192.168.1.2:7082??Connection: Keep-Alive??User-Agent: Android-Mms/2.0????
TCP : From MMS Center to UE
Payload from a TCP capture,
HTTP/1.0 200 OK??Content-Length: 780946??Content-Type: application/vnd.wap.mms-message??Connection: close ??????????S??{?MT MMS????2580???????????? ???"<5386A6D2.txt>??5386A6D2.txt?MT MMS Testing??????"<Koala.jpg>
TCP : From MMS Center to UE
A lot of Binary Data of the MMS Contents
The GET goes to exactly the path in X-Mms-Content-Location, and it accepts application/vnd.wap.mms-message. The answer is HTTP/1.0 200 OK with a Content-Length of 780946 bytes, the same value as X-Mms-Message-Size in the notification. The body is the MM in binary MMS encoding, and you can still read the subject MT MMS, the sender 2580 and the attached file names in it.
Following is the SMS (MMS Delivery Message) shown on SamSung Galaxy 4 as an example to show MMS Contents downloading process.
The download starts only when the user presses Download, so on this UE the retrieval is manual.
Left screen : The UE shows the size and the expiry from the notification before it downloads anything. Expires on Jun 5 is 7 days after the notification on May 29, which matches X-Mms-Expiry.Middle screen : The HTTP GET and the TCP transfer shown above run while the progress bar is on screen.Right screen : The UE shows the text MT MMS Testing and the picture from the retrieved MM.
An MT MMS needs both domains : Steps 04 to 07 need the CS domain for the SMS, and steps 09 to 11 need a PS connection for the HTTP download.Two acknowledgements close the SMS : CP-ACK confirms the CM layer transfer, and RP-ACK inside a second CP-DATA confirms that the UE accepted the SMS.The URI in the notification must be reachable : The UE fetches the content from X-Mms-Content-Location, so the address and port must be reachable from the PS connection of the UE.The Content-Length should match the notified size : Here both are 780946 bytes.
Case 2 : MO MMS - No Delivery Report, No Read Report
: This example is the case where MO MMS is performed with a UE Test Equipment (Anritsu MD8475 + NowSMS). The MO direction is much simpler than the MT direction. The UE already knows that it has a message to send, so no notification is needed.
01) < In Idle Mode or In Connected Mode >
02) < Send a MMS (from UE) to Test Equipment >
03) < UE send MMS message through IP data > // Therefore you would not see any Radio Signaling Message here
Let's compare this with Case 1. In the MT case, the network needs an SMS because it has to reach a UE that may not have a PS connection. In the MO case, the UE starts the transfer itself. So it sends MM1_submit.REQ straight to the MMS Relay/Server over HTTP, and the MMS Relay/Server answers with MM1_submit.RES. The answer carries the status of the submission and, when it succeeds, a message ID for the new MM.
The note in step 03 means that no SMS and no other NAS message carries the MMS itself. You may still see RRC and NAS messages, though. If the UE is in idle mode, or has no PS connection yet, it has to set up the PS connection first. Those messages set up the bearer, and they carry none of the MMS content.
After the submission, the MMS Relay/Server stores the MM. If the recipient is another UE, the MMS Relay/Server then starts a Case 1 sequence toward that UE. So an MMS between two phones is one Case 2 followed by one Case 1. In a test setup with only one UE, you can send an MMS to the UE itself and see both halves in one log.
MO MMS is a pure PS procedure : The UE sends the MM in an HTTP request, and no SMS is involved.Radio messages in an MO log belong to the bearer : RRC and NAS messages in an MO MMS log set up the PS connection, and they do not carry the MMS.MM1_submit.RES is the only answer the sender gets : Without a delivery report or a read report, the sender never learns whether the recipient received or read the MM.
Reference
- 3GPP TS 23.140 v6.16.0 : Multimedia Messaging Service (MMS); Functional description; Stage 2
- 3GPP TS 23.040 v20.0.0 : Technical realization of the Short Message Service (SMS)
- 3GPP TS 24.011 v20.0.0 : Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface