Abstract — This paper presents an idea for a new

innovative service in mobile telephony and the technical solution for it. We called the new service “Play MMS”, as it is realized using MMS technology. Service is designed to send and receive audible messages of a special kind.

Keywords — Audible messages, MMS, play messages, Play MMS, speakerphone.

I. INTRODUCTION HE purpose of today’s electronic telecommunication systems is to provide for a simple, fast and efficient

communication between distant people. Mobile communication systems, such as

GSM/GPRS/3G etc. offer a vast set of services to provide for such communication. But, sometimes, we need it to be even faster and simpler.

For example: Have you ever wanted to pick up your phone – but you could not because your hands were busy?

Or: Have you ever just wanted to say few words to your spouse on the phone – but you knew he/she was driving and didn’t want to disturb?

Or: Do new touch screen phones annoy you because you cannot type in a message correctly?

That is why we are introducing an idea for a new service “Play MMS”.

II. SERVICE DESCRIPTION The purpose of the service is to convey audible

messages over mobile lines, so that the recipient of the message (B party) will hear the message on the device’s speakerphone immediately after it has been received on the device – without the need to interact with the device in any way.

Today, in mobile networks, there is the MMS service which allows sending/receiving of audio messages, and we took the MMS service as the base for this new service. However, audio messages sent via MMS service today are little hard to use. In today’s MMS service when B party receives an audio message – B party has to come to the phone, take it, click on the message, open the message, then open the recording, then to place the device near the ear in order to hear the audio message. Also when composing an audio message in today’s MMS service user has to click many times in order to add an attachment of a

Katarina Piljanovic M.Sc. EE. Belgrade, Serbia (phone: 381-63-332-495; e-mail: kdjakovic@hotmail.com)

Milutin Aksic M.Sc. EE, Belgrade, Serbia; (phone: 381-63-312-576, e-mail: milutin.aksic@hotmail.com)

recorded audio file. The interface is quite complicated and so not often used.

This, different “Play MMS” service would add to the current MMS functionality and allow a simple exchange of audio messages. The recipient will hear the message the moment it has been received on the device. The fact that the B party does not have to manipulate with the phone gives this service a new dimension and makes it useful in all situations where users are busy and unable to manipulate with the phone – be it because of their profession, situation in particular moment, their physical capabilities or other.

However, in order not to be disturbed by malicious users, the B party has to control the “white list” of senders allowed to send such messages to the B party. The B party is aware that the “Play MMS” messages will be played on the speakerphone immediately after they have been received on the device, in case they have been sent by A parties in the “white list”.

On the sender’s side (A party) the sender will record his/her audio message and send it to the B party. The party A is aware that the message will be reproduces on the B party’s device automatically and sends the message as such on purpose. The A party will use special piece of software on the device to label the messages as “Play MMS” message.

In other words, the “Play MMS” messages received on the device will be audible “hands free” and will save the recipient from the need to take the device, click few times and place it close to the ear to actually hear the message.

On the other hand, the idea is also to simplify the sending interface for this kind of messages, so that the sender does not have to click many times in order to record and send “Play MMS”, as now he/she has to do with normal MMS messages. The interface will be simplified and straighten-forward to take only two-three clicks and the recording in order to utilize this new service.

For the service described, the MMS technology was chosen because of its push functionality. However, there is a need to change MMS technology standards as there is no existing information that can indicate and describe the service from end-to-end in today’s standards. Possibly other parameters in the message content description could be used to support the service, but that would produce the overhead in content processing. Using the X-MMS-Message-Class field, however, the desired functionality would be supported in the correct manner and the field would be used in the right way, as the class of the message

“Play MMS”: A new service in mobile communications

Katarina Piljanovic M.Sc. EE, Milutin Aksic M.Sc. EE

T

20th Telecommunications forum TELFOR 2012 Serbia, Belgrade, November 20-22, 2012.

978-1-4673-2984-2/12/$31.00 ©2012 IEEE 166

really becomes different for this service.

III. TECHNICAL SOLUTION

A. MMS Standards As mentioned, MMS technology will be used to realize

the described service. MMS protocols are defined by standards, by which sending and receiving of “Play MMS” messages is not defined.

In order to define the new service and to support it in 3GPP/OMA standards the specifcation for Multimedia Messaging Service Protocol [1] and [2] need to be changed, while many standards, like [3] or [4] do not need to be changed at all.

B. MM1 Interface MM1 interface is the interface between the MMS User

Agent on one side and the MMS Server/Relay on the other side [2]. This interface is our area of interest since it needs to convey the information that the message is of the “Play MMS” type. A Party UA composing the message needs to insert this information into the message and the receiving UA (B party) needs to recognize the information and automatically play the message accordingly.

Three messages carry the relevant information, those are: MM1_submit.REQ, MM1_notification.REQ, MM1_retrieve.RES on MM1 interface. MM1_submit.REQ on Party A side and MM1_notification.REQ, MM1_retrieve.RES on Party B side (please see Fig. 1).

Originator MMS UA Recipient

MMS UA

MM1_submit.REQ

MM1_notification.REQ MM1 notification.RES

MM1_retrieve.REQ MM1_retrieve.RES

MM1_acknowledgement.REQ

MM1_read_reply_originator.REQ

O- & R- MMS Relay/

Server

MM1_delivery_report.REQ

MM1_read_reply.REQ

C5

C1 MM1_submit.RES

C6

C8

C2

C3

C4

C7

MM1_cancel.REQ MM1_cancel.RES

C9

MM1_delete.REQ C10

MM1_delete.RES

Fig. 1: Message flow on MM1 interface

Considering the needs, we chose a header field in those three MMS messages, as this header field is conveyed unchanged from Party A, over the MMS Relay/Server all the way to Party B’s UA during the message transmission. The name of the field is X-MMS-Message-Class.

Currently the identifiers for this octet string field are: “Personal”, “Advertisement”, “Informational” and “Auto”. In order to distinguish the “Play MMS” messages from other types of messages a new value for this field should be introduced into the encapsulation protocol specification [1]. For example, the new identifier could be called Play. etc.

Fig. 2: MMS_notification.REQ header fields The message flow on this inteface stays exactelly the

same, and the only thing to change in the standard is to add

Field Name Description X-Mms -Message-Type

Mandatory. Specifies the PDU type.

X-Mms -Transaction-ID

Mandatory. This transaction ID identifies the M -Notification.ind and the corresponding M -NotifyResp.ind

X-Mms -MMS-Version

Mandatory. The MMS version

From Optional. Address of the last MMS Client that handled the MM, i.e. that sent or forwarded the MM.

Subject Optional. Subject of the message.

X-Mms -Delivery - Report

Optional. Specifies whether the user wants a delivery report from each recipient. The absence of the field does not indicate any default value.

X-Mms -Message-Class

Mandatory. Class of the message. The MMS Proxy -Relay M UST provide the Personal message class if the original submission did not include the X-Mms -Message-Class

X-Mms -Message-Size

Mandatory. Full size of the associated M -Retrieve.conf PDU in octets. The value of this header field could be based on approximate calculation, therefore it SHOULD NOT be used as a reason to reject the MM.

X-Mms -Expiry Mandatory.

167

a new value for this field. Please see Fig. 2 for the illustraion of MMS_notification.REQ header fields.

By introducing this new field value into the standard message both Party A UA and Party B UA will have an exact indication that the MMS is of a special type and that it should be composed and reproduced in the way specified by the „Play MMS“ service.

C. MMS Relay/Server No major changes are needed on the MMS Relay/Server

side, as it only has to accept the new X-MMS-Message-Class value in relevant messages and convey it throughout the system. No actions are needed by the MMS Relay/Server on acceptance of such message, unless the new privacy features are introduced into it, described in the next section.

D. Privacy and security “Play MMS” message service needs to be controlled by

users on the basis of white lists. Namely, B Party should define a list of phone numbers from which he/she accepts “Play MMS” messages. These lists are needed as without them messages recipients could be disturbed by malicious senders.

The lists could be created both on the device (UA side), or on the network side on the MMS Relay/Server.

If created on the device side, users should be able to browse through their phone book and chose the authorized senders, for example by clicking by the authorized senders phonebook name.

In case white list is kept on the MMS Relay/Server side, the possible way to update it would be through SMS messages, where users would be sending SMSs to the operators systems with phone numbers from which they accept to receive “Play MMS” messages.

Both solutions have their upsides and downsides. The first solution is more convenient for end users, but the message sent as “Play MMS” message would be conveyed all the way through the network as a “Play MMS” and only at the end point it would be reproduced as the normal MMS and not as the “Play MMS” in case Party A is not whitelisted. This way the sender would not be aware that the message was actually turned into a normal MMS message.

The other solution is not that convenient for end users, in sense of forming up the white list, but the network element MMS Relay/Server would be more in control of unauthorized messages and could possibly reject the non-authorized message or at least could send to the sender the information that the message was turned into a normal MMS message. This second option also opens the door to new parameter values for “Play MMS” messages rejected on the MMS Relay/Server side.

Please see Fig. 3 for the example on whitelist creation on Android platform.

The end user only needs to “click” by the name of the sender that he/she authorizes to send “Play MMS” messages to he/she.

Fig. 3 Whitelist creation on Android platform

E. Billing This new service also opens the new opportunities to

bill for such messages. These messages could be billed as MMS messages or as

special MMS messages, as the Message Class field is present in Call Detail Records produced by MMS Relay/Server systems, so they would not be hard to distinguish among other messages [3].

Apart from being billed like MMS messages, they could also be combined with the voice service billing, because, in fact, they represent the voice service – only not done in the real time. That is why, there is a possibility to bill them as call minutes/seconds and combine them with billing packages available to the public in most billing systems today.

By billing them in attractive way mobile operators would have a new tool to increase their revenue, while offering a new service to the public.

F. MMS UA changes In order to support the service MMS UA on the devices

have to be altered. First, on the recipient side when MMS message with the

X-MMS-Message-Class = “Play” the UA agent should first play the message notification sound, and then, after the message download it should play the message automatically on the handset speakerphone.

It should save the message and display the notification that such message has been received. This notification should be displayed, because the Party B could’ve missed the message broadcast.

On the sender’s side, during the message composition there should be an option to record message as the “Play MMS” message. The A Party UA should then insert the right value for the X-MMS-Message-Class field into it. This interface should be maximally simplified so that it becomes much easier to compose such message then the “normal” MMS.

Please see Fig. 4 for the example on UA message creation on Android platform, where you can see the option to Record the “Play MMS” message.

168

Fig. 4 Message composition on Android platform

IV. PRELIMINARY TEST RESULTS First test results produced on an Android platform show

that the service is feasible and producible using the proposed X-MMS-Message-Class field on MM1 interface. Since the new value for “Play” messages is still not entered into standards, we used an existing value for “Informational” messages, to prove the concept. Some of the functionality can be demonstrated on Android emulators and the full functionality can be demonstrated on Android phone devices.

V. CONCLUSION Benefits of the service are primarily on the end users –

consumer’s side. The service allows for more direct and simpler communication. Lots of professions that involve manual work could benefit from it like drivers, cooks, or mechanics when they need timely information without having to stop their work. Apart from those, groups like elders or children or people with special needs could also benefit from this service.

Also, in the recent time, touch screen phones made it harder to type in SMS messages, and a service of this kind could overcome this problem.

Basically, anytime when the recipient is busy, the sender could utilize “Play MMS” service to inform recipient of something - without making them to pick their phone to hear the information.

The “Play MMS” service technical solution is submitted for patent recognition and currently is protected by patent rights.

REFERENCES [1] Multimedia Messaging Service Encapsulation Protocol (OMA-TS-

MMS-ENC-V1_3-20080128-C) [2] “Multimedia Messaging Service: Service aspects; Stage 1”, 3rd

Generation Partnership Project TS 22.140 Rel-4 [3] Telecommunication management; Charging management;

Multimedia Messaging Service (MMS) charging 3GPPTS 32.270 [4] Wireless Application Protocol, Multimedia Messaging Service,

Client Transactions Specification, WAP-206-MMSCTR-20010612

169