Mensagens Multimídia - SMS ao MMS

Prévia do material em texto

1
 
 
Mensagens Multimídia – Do SMS ao MMS 
 
Christiano Freitas de Souza, Rafael Oliveira Ribeiro 
Departamento de Engenharia de Telecomunicações – Universidade Federal Fluminense 
(UFF) 
Rua Passo da Pátria, 156 São Domingos – Niterói – RJ - Brazil 
 
Abstract. The Multimedia Messaging Service (MMS) is a new, versatile 
messaging service that can carry multimedia content, including images, video 
and audio clips, maps, graphs, layouts, cartoons, animations, etc. Today's 
popular text-based Short Messaging services and Smart Messaging services can 
be enhanced with richer MMS content. MMS also offers a radically better end-
user experience compared to text only-based short messaging services. For 
example, a weather service can be extended from text-based information to 
include animated weather maps and forecast graphs with MMS capable 
terminals. 
 
Resumo. O serviço de mensagem multimídia (MMS) é um novo e versátil 
serviço de envio de mensagem que leva conteúdo multimídia, incluindo 
imagens, vídeo e clips de áudio, mapas, gráficos, layouts, cartoons, animações, 
etc. Hoje, os serviços populares baseados em Short Message e Smart Message 
podem ser melhorados com conteúdo MMS mais rico. MMS também oferece 
uma melhor experiência ao usuário final comparado com os serviços de short 
messaging baseados somente em textos. Por exemplo, o serviço de 
meteorologia, além de informações com apenas texto, pode ser extendido para 
incluir mapas de tempo animados e gráficos de previsão com o uso de terminais 
MMS adequados. 
 
 
1. Introdução ao Serviço de Mensagem Multimídia (MMS – Multimedia Messaging 
Service) 
 
MMS é designado para redes de alta velocidade como as redes GSM com 
HSCSD (High Speed Circuit Switched Data), GPRS, TDMA, WCDMA e 3G. A primeira 
versão de um MMS Center é designada para redes GSM e GPRS. Um MMS Center 
funciona como uma central “store and forward” para o envio de mensagens MMS em uma 
rede celular. O termo “store and forward” indica que: quando o MMS Center recebe a 
mensagem ela a armazena em seu banco de dados; o MMS Center envia a mensagem 
quando a estação móvel (MS – Móbile Station) pede; se a mensagem não puder ser 
 2
entregue com sucesso, ela é armazenada para ser enviada posteriormente; depois de uma 
entrega bem sucedida, a mensagem é apagada do banco de dados do MMS Center. 
Uma central MMS pode permitir três tipos de comunicação: celular-a-celular, 
celular-e-mail e celular-outras aplicações, onde a comunicação entre o MMS Center e a MS 
é baseada em protocolos definidos pelo WAP Fórum. 
 
1.1 Padronização MMS 
 
Existem duas entidades à frente desta padronização: 
- WAP Fórum (Wireless Application Protocol Fórum) [4] que define os protocolos 
entre o celular e o MMS Center, bem como o formato de apresentação. 
- 3GPP (3rd Generation Partnership Project) [3] que define services e a arquitetura 
MMS. O escopo original do 3GPP era produzir Especificações Técnicas globalmente 
aplicáveis para um sistema móvel de 3ª geração baseado em redes GSM evoluídas. O 
escopo do projeto foi mais tarde ampliado para incluir a manutenção e o desenvolvimento 
de especificações técnicas para o padrão GSM e suas evoluções, como GPRS (General 
Packet Radio Service) e EDGE (Enhanced Data rates for GSM Evolution). 
 
2. SMS 
O SMS (Short Message Service) é o serviço de troca de mensagens de texto curtas 
entre celulares mais bem sucedido. Isto se deve basicamente à grande penetração da 
tecnologia GSM em vários mercados do mundo. Serviços semelhantes também existem em 
outras redes, como a TDMA (IS-136), CDMA (IS-95) e PDC (Japão). 
O funcionamento do SMS é muito simples.[1] As mensagens são trocadas entre 
telefones celulares num esquema “store-and-forward”, ou seja, um aparelho envia uma 
mensagem para outro, sendo que esta mensagem será recebida por um centro de controle da 
operadora do serviço antes de ser transmitida ao seu destinatário final. O centro de controle 
citado é chamado de SMSC (Short Message Service Center) e é responsável por todas as 
tarefas relativas ao processamento das mensagens, como roteamento, bilhetagem 
(cobrança) e entrega das mensagens. 
 3
Além da troca de mensagens entre aparelhos celulares, outras entidades também 
podem enviar e receber mensagens através deste sistema. Por exemplo, pode ser enviada 
uma mensagem de um computador para um aparelho celular e vice-versa. 
Neste sistema, as mensagens são enviadas utilizando-se o canal de controle do 
sistema celular, não ocupando, assim, canais que são utilizados para o tráfego de voz. 
Ao ser enviada a mensagem, pode ser que o destinatário não esteja disponível 
naquele instante. Neste caso, a mensagem será armazenada no banco de dados do SMSC e 
será feita uma solicitação ao HLR (Home Location Register) para que este avise ao SMSC 
assim que o usuário esteja disponível para receber a mensagem. Caso seja ultrapassado um 
determinado tempo sem que a mensagem seja entregue esta será descartada e, 
opcionalmente, uma mensagem notificando o remetente poderá ser enviada a este. 
Na figura abaixo podemos identificar os componentes principais de uma rede que 
dão suporte ao serviço SMS: 
 
Figura 1 
Podemos identificar as aplicações externas, como e-mail, web e voice-mail, que 
podem tanto enviar como receber SMS para / de aparelhos celulares. Os aparelhos celulares 
estão logicamente conectados ao MSC (Master Station Controller), que transfere todas as 
mensagens ao SMSC através dos Pontos de Transferência do Sinal (STP – Signal Transfer 
Point). Como já foi dito, o SMSC é a entidade responsável por processar a mensagem 
recebida. 
Uma característica muito importante deste sistema é a o tamanho de cada 
mensagem, que é limitado a 160 caracteres, se usado o alfabeto ocidental ou 80 caracteres, 
 4
no caso dos alfabetos árabe ou chinês. Este é um fator que limita as funcionalidades do 
SMS, mas que, ao mesmo tempo, possibilita que sejam criados serviços a um baixo custo, 
principalmente do ponto de vista da aquisição de equipamentos na rede celular. 
O formato da mensagem consiste basicamente de um cabeçalho, contendo 
informações de controle, como endereço de destino, de origem, tamanho da mensagem, 
entre outras, e do corpo da mensagem propriamente dito. Este formato é muito semelhante 
ao formato das mensagens de e-mail e assim é possível o intercâmbio de mensagens entre 
celular e e-mail. 
 
Header Message Body 
Figura 2 
Um detalhamento maior não será abordado, dado que o enfoque deste trabalho é o 
assunto MMS (Multimedia Message Service). 
3. EMS 
Nesta seção iremos explicar o serviço EMS (Enhanced Message Service) 
apresentando-o como uma extensão do serviço SMS [1]. Ou seja, o EMS não é uma forma 
radicalmente nova de troca de mensagens, como é o MMS. 
Na figura abaixo podemos ver um exemplo de uma mensagem EMS, contendo um 
texto seguido de uma imagem simples e novamente outro segmento de texto. 
Hello World!!!
I'm happy : ¬)
 
Figura 3 
 
O grande segredo sobre como é possível transmitir imagens como esta são dois 
tipos diferentes de cabeçalhos. A mensagem, como toda mensagem SMS, possui um 
 5
cabeçalho que contém informações que são em sua maioria invisíveis ao usuário final e um 
campo de dados do usuário, que contém o corpo da mensagem. Ou seja, uma mensagem é 
composta por um cabeçalho com informações de controle e um campo de dados. 
O cabeçalho traz informações como o endereço de destino, tamanho da 
mensagem, etc. No caso do EMS, um campo muito importante é o TP UDHI (Transport 
Protocol – User Data Header Information), informando que no campo de dados da 
mensagem há também um outro cabeçalho (UDH – User Data Header). A mensagem EMS 
terá, então, o seguinte formato: 
 
Header 1 User Data Header Message Body 
Figura 4 
 
O campo preenchido com o valor “1” é o TP UDHI, indicando ao aparelho celular 
que recebe a mensagem que dentro do corpo da mensagem existem mais informaçõesde 
cabeçalho, além da própria mensagem. 
O primeiro byte do UDH indica o comprimento deste cabeçalho, chamado de 
UDHL (UDH Length). O restante da mensagem é o corpo da mensagem usual do sistema 
SMS. 
O User Data Header é composto pelo campo UDHL e outros elementos. Cada 
elemento é composto por: 
- Information Element Identifier (IEI) 
- Information Element Identifier Length 
- O deslocamento do objeto EMS, dentro do texto SMS 
- O valor do objeto EMS 
Vários tipos de objetos EMS são definidos. Abaixo temos uma lista com vários 
exemplos: 
- Texto formatado; 
- Som predefinido, similar ao padrão MIDI; 
- Som definido pelo usuário (melodias); 
- Animações predefinidas; 
- Animação em tamanho grande (16x16); 
 6
- Animação em tamanho pequeno (8x8); 
- Figura em tamanho grande (32x32); 
- Figura em tamanho pequeno(16x16); 
 
Apesar do significativo avanço em relação ao SMS, o serviço de EMS não suporta 
conteúdo multimídia tão bem quanto MMS. Explicaremos com mais detalhes, a seguir, o 
funcionamento desta tecnologia, abordando desde a arquitetura do sistema celular com 
suporte a MMS até os protocolos e linguagens para definição do conteúdo multimídia das 
mensagens. 
 
4. MMS - Multimedia Massaging Services 
 
O MMS inclui quatro tipos básicos de serviços [2]: mensagens multimídia 
originadas no celular; mensagens multimídia terminadas no celular; mensagens multimídia 
originadas em uma aplicação; mensagens multimídia terminadas em uma aplicação. 
Em uma mensagem multimídia originada no celular quem envia é o celular. A 
mensagem pode ter três destinos diferentes: ela pode ser diretamente direcionada para outro 
celular; ela pode ser enviada para uma aplicação (como um e-mail); e ela pode ser 
processada em uma aplicação antes de ser enviada para o celular de destino (neste caso, a 
mensagem é primeiramente devolvida a MMS Center, como por exemplo se uma figura 
tiver que ser convertida em outro formato, como de JPEG para GIF) 
Em uma mensagem multimídia terminada no celular o destino da mensagem é um 
celular, onde a origem pode ser outro celular ou uma aplicação (como em um serviço de 
aplicação de imagens ou quando do envio de um e-mail para o celular). 
Em uma mensagem multimídia originada em uma aplicação quem envia é uma 
aplicação e a mensagem pode ser enviada diretamente a um celular ou para outra aplicação. 
Em uma mensagem multimídia terminada em uma aplicação quem vai receber 
esta mensagem é uma aplicação, onde a origem de tal mensagem pode ser um celular ou 
outra aplicação. 
 
 7
4.1 Características de uma Mensagem Multimídia 
As características de uma central de mensagens multimídia dizem respeito ao 
endereçamento, ao período de validade da mensagem e a notificações e reconhecimentos 
MMS, como confirmação de mensagem, indicação de mensagem e relatório de entrega. 
 
4.1.1 Endereçamento: 
Quanto ao endereçamento, a MSISDN (Móbile Subscriber ISDN number) é o 
primeiro método para endereçar um usuário final entre uma mensagem originada e 
terminada. O MSISDN deve testar em um formato internacional. O usuário pode digitar o 
número em formato internacional ou nacional, sendo que este é convertido no formato 
internacional quando a mensagem chega ao MMS Center. 
Cada aplicação tem seu próprio número. Toda vez que um MMS Center recebe 
uma mensagem, ele checa as regras de roteamento, caso a mensagem deva ser direcionada 
para uma aplicação externa. 
No endereçamento entre um MMS Center e um celular, cada celular de origem 
contata seu MMS Center, definido como default, cujo endereço é configurado no próprio 
celular. 
O endereçamento com e-mails é usado para mensagens terminadas e, neste caso, 
roteamento padrão de mensagem da internet é usado. 
 
4.1.2 Período de validade da mensagem 
São dois os modos de se definir o período de validade da mensagem: definição 
pelo próprio usuário, assinante da linha, ou pela operadora. 
Período de validade define o tempo em que a mensagem permanece válida. Por 
exemplo, se uma entrega de mensagem falhar, ela é armazenada para que outra tentativa de 
entrega possa ocorre futuramente, sendo que tais tentativas ocorrem dentro do tempo 
definido pelo período de validade. 
Quando a mensagem chega ao MMS Center, este vai determinar uma etiqueta de 
tempo para ela, a ser usado no calculo do período de validade. Depois que o período de 
validade se expira (no caso de entregas mal sucedidas), a mensagem será descartada e 
removida do banco de dados do MMS Center. 
Como dito, o usuário pode definir o período de validade diretamente de seu 
aparelho e existe um período de validade default configurado no MMS Center, o qual pode 
 8
ser modificado. Contudo, se o usuário definir um valor maior que o do operador, o sistema 
irá usar o seu período de validade estabelecido. 
 
4.1.3 Notificações e reconhecimentos MMS 
Compreendem basicamente três tipos, visíveis ao usuário final: 
 
4.1.4 Message Confirmation 
Quando uma mensagem de um celular é recebida pelo MMS Center, este notifica 
o celular de origem se o MMS Center aceitou a mensagem para ser entregue ou não. Logo, 
a mensagem de confirmação pode ser positiva ou negativa, informado sobre o sucesso ou 
falha na submissão do pedido. 
 
4.1.5 Message Notification 
Quando uma mensagem chega ao MMS Center, ele notifica o celular de destino 
sobre a mensagem que está aguardando para ser vista. Depois de receber a notificação de 
mensagem, o celular destino pode busca-la (fetch), adiar a entrega ou descartar a 
mensagem enviando uma resposta apropriada de volta ao MMS Center. Lembrando que, na 
primeira edição, alguns celulares suportavam somente a busca automática da mensagem. 
 
4.1.6 Delivery Report 
O relatório de entrega pode ser visto como um relatório de status, informando a 
origem da mensagem se esta foi entregue com sucesso ou não e tem um período de validade 
associado. (Message Confirmation só diz se a mensagem chegou ao MMS Center, não 
garantindo nada quanto à entrega ao destino). O relatório de entrega pode conter 
informações, como por exemplo, se o destino rejeitou a mensagem. 
O relatório de entrega não é enviado automaticamente. É o originador da 
mensagem quem deve requerê-la separadamente quando envia sua mensagem, a qual só é 
armazenada no MMS Center quando ocorre falha na entrega. 
 
4.2 Arquitetura e funcionalidade da rede 
 
Uma breve apresentação sobre a arquitetura num sistema celular GSM com 
suporte para MMS. 
 
 
 9
GPRS BB
MS
BSS
SMS-
GMSC
SMS-
IWMSC
WAP GW
PPG
Um Gb
A
BTS BSC
MSC HLR VLR
SGSN
GGSN
MMSC
Ext.
Appl.
SMSC
NSS
 
 
Figura 4 
 
Existem três subsistemas em uma rede: a BSS (Base Station Subsystem), a NSS 
(Network Switching Subsystem) e o GPRS (Global Packet Radio Subsystem). 
A BSS é responsável pelo controle no caminho rádio. Cada chamada (e, também, 
chamada de dados) é conectada através da BSS e NSS, que toma conta das funções de 
controle de chamada. A parte do GPRS destina-se as informações comutadas por pacote, 
tendo o SGSN E GGSN conectados a si. Observa-se, também, três interfaces: a interface 
Um, entre o celular e a BSS, a Gb, entre a BSS e SGSN a interface A, entre a BSS a NSS. 
Vamos dar um enfoque na parte da arquitetura mais afim com o assunto MMS. 
Sendo assim, temos: 
SGSN (Serving GPRS Support Node): é a parte mais importante do sistema 
GPRS. Suas responsabilidades incluem: a conversão de protocolos usados no backbone IP e 
os usados na BSS e no celular; codificação e compressão; autenticação; gerenciamento de 
mobilidade; roteamento de informação para o GGSN apropriado quando uma conexão com 
uma rede externa for solicitada; interação com o MSC/VLR e o HLR; um resumo da 
bilhetagem e de tráfego estatístico; busca de informação do HLR do assinante. 
 10
GGSN (Gateway GPRS Support Node): suas responsabilidades incluem: 
roteamento de pacotes destinados a um celular vindos de uma rede externapara o SGSN; 
roteamento de pacotes originados do celular para a rede externa correta; interfaces com 
redes IP externas; um resumo da bilhetagem e de tráfego estatístico; alocação dinâmica ou 
estática de endereços IP para os celulares, seja por ele mesmo ou com a ajuda de um DHCP 
ou um servidor RADIUS. 
MSC (Mobile Switching Center): transmite mensagens multimídia entre a BSS e 
a MMS Center. 
HLR (Home Location Register): armazena as seguintes informações do assinante: 
MSISDN; IMSI; VLR e endereço SGSN; informações do assinante (como serviços 
permitidos...) 
VLR (Visitor Location Register): armazena informação temporariamente dos 
celulares dentro da área de cobertura de uma MSC, a qual ele está ligado. A informação é 
armazenada pelo tempo em que o celular estiver na área controlada pelo este registrador. O 
VLR, também, busca informação do HLR do assinante e notifica o HLR sempre que o 
celular se mover de uma MSC para outra área de cobertura. 
SMS-GMSC: (SMS-Gateway Mobile Switching Center): recebe mensagens 
curtas da SMSC, interroga o HLR para a informação de roteamento e da mensagem curta, e 
envia a mensagem curta para o MSC (Mobile Switching Centre) apropriado ou para o 
SGSN e reporta o resultado da operação ao SMSC. Em mensagens multimídia o SMSC só 
é usado com relatórios de entrega e notificações, que usam SMS como suporte. 
WAP Push Proxy ou PPG (Push Proxy Gateway): enviam relatórios de entrega e 
notificações para o celular que esta’usando serviços SMSC. 
WAP GW (WAP Gateway): transfere a mensagem multimídia entre o celular e a 
MMSC, onde o protocolo WAP é usado para a comunicação com o celular. 
O Fórum WAP especificou duas diferentes funções, mas na prática eles ficam 
fisicamente no mesmo dispositivos. 
MMSC (Multimedia Messaging Center): é o que podemos chamar de "evolução 
natural" para a plataforma SMSC. Enquanto o SMSC é responsável pelo tratamento de 
mensagens de texto (com comprimento limitado) a plataforma MMSC permite agregar 
 11
valor ao tráfego de mensagens, possibilitando o uso de combinações de formatos de mídia, 
tais como: imagem, som e vídeo entre outros. 
Ext Appl (External Application): refere-se a aplicações de próprio operador, a 
aplicações de 3G, a conectividade com e-mail (Mail GW é um exemplo de aplicação 
externa), a conexões inter-MMSC (IMMSC é um exemplo de aplicação externa). Tal 
aplicação pode se localizar na rede do operador, na Internet ou em alguma outra rede. 
 
4.2.1 Tipos de PDU MMS 
 
São cinco os tipos de PDU, conforme observamos na tabela abaixo. 
 
Tipo de PDU Descrição 
M-Send.req 
M-Send.conf 
Envia a mensagem para o MMS Center 
Reconhecimento do MMSC para a mensagem 
M-Notification.ind 
M-NotifyResp.req 
Notificação MMS sobre a nova mensagem 
Resposta do receptor sobre a ação a ser tomada 
WSP GET.req 
M-Retrive.conf 
Busca a mensagem no MMC Center 
Recebe a mensagem do MMS Center 
M-Acknowledge.ind Reconhecimento da entrega da mensagem 
M-Delivery.ind Relatório de entrega sobre a mensagem enviada 
 
 
M-Send.req – mensagem enviada pelo celular para ao MMS Center. 
M-Send.conf – quando o MMS Center recebe o pedido de enviar (Send Request) 
ele envia uma mensagem resposta de volta ao celular indicando o status da operação, que 
pode ser positivo ou negativo. 
M-Notification.ind – notificações MMS informam ao celular sobre o conteúdo 
(URI –Uniform Resource Identifier, que é o endereço do MMS Center, tamanho, tempo de 
validade) da mensagem que está esperando. 
 12
M-NotifyResp.req – confirmação da notificação. O propósito desta confirmação 
é reconhecer a transação (deferindo, apagando,encaminhando posteriormente) para o MMS 
Center. Se for para recuperar a mensagem imediatamente, um comando de GET request é o 
deve ser usado. 
WSP GET.req – o celular recupera a mensagem enviando um WSP GET request 
para o MMS Center. 
M-Retrive.conf – quando o comando GET é bem sucedido, a resposta irá conter 
cabeçalhos e o corpo da mensagem que estiver chegando (incoming message). 
M-Acknowledge.ind – confirma a entrega da mensagem do terminal receptor 
para o MMS Center. Trata-se de um comando opcional de acordo com especificações (é 
sempre usado nas soluções Nokia). Se um GET tiver sido usado no lugar de um M-
NotifyResp.req, este é usado no lugar de M-Acknowledge.ind. 
M-Delivery.ind – um relatório de entrega MMS pode ser enviado do MMS 
Center do receptor para o celular que está originando a mensagem quando o receptor tiver 
reagido ao MMS Notification. O relatório de entrega pode incluir informações sobre busca, 
rejeição e expiração. Há um relatório de entrega separado para cada receptor e não existe 
mensagem de resposta ao relatório de entrega. 
 
4.2.2 Estrutura do PDU 
 
A estrutura do Protocol Data Unit (PDU) MMS é especificada pelo Wap Forum 
na especificação WAP-209-MMSEncapsulation. 
Um PDU consiste de um cabeçalho e um corpo, ou somente de um cabeçalho. O 
corpo está presente somente nos PDU’s dos comandos M-Send.req e M-Retrive.conf. 
Também existem PDU’s formadas só de cabeçalhos. 
As mensagens MMS são submetidas para a entrega em uma PDU M-Send.req. Ela 
consiste de cabeçalhos e corpo de mensagem, o qual contém o conteúdo da mensagem 
MMS encapsulado com MIME (O MIME vai ser explicado mais adiante). Para M-
Send.req, os seguintes cabeçalhos são mandatórios: 
 
 
 13
Nome Valor em Hex Conteúdo Comentários 
X-Mms- 
Message-Type 
8c 
Message-type- 
Value= m-send.req 
Especifica o tipo da 
mensagem 
X-Mms- 
Transaction-ID 
98 Transaction-id-value 
Um identificador único para a 
mensagem. Identifica tanto a 
mensagem enviada quanto a 
mensagem de confirmação. 
X-Mms- 
Version 
8d MMS-version-value O número da versão MMS 
From 89 From-value 
Endereço do originador da 
mensagem. Este campo 
precisa ser mostrado ao 
destinatário da mensagem. 
 
 
A completa lista de PDUs MMS e cabeçalhos M-Send.req, bem como os 
cabeçalhos opcionais, são apresentados no Wap Forum na especificação WAP-209-
MMSEncapsulation. A tabela seguinte mostra um exemplo de um cabeçalho de uma 
mensagem MMS (PDU M-Send.req) antes da codificação em binário. 
 
X-Mms-Message-Type: m-send-req 
X-Mms-Transaction-ID: 1234567890 
X-Mms-Version: 1.0 
To: +35840222222/TYPE=PLMN 
From: +35840111111/TYPE=PLMN 
Subject: Test MMS message 
Date: Wed Oct 24 09:55:52 2001 
Content-Type: application/vnd.wap.multipart.mixed 
 
 
O corpo da mensagem de múltiplas seções (multipart) do exemplo consiste de 
duas partes. A primeira é um texto sem formatação (This is an example MMS message with 
plain text and image.) e a segunda é uma imagem. 
A mesma mensagem (cabeçalhos + corpo) no formato binário codificado é 
apresentada no formato hexadecimal na tabela a seguir, onde se nota que a imagem não foi 
inteiramente apresentada na tabela. 
 14
 
The above M-Send.req in binary encoded format displayed in hex mode 
00000000: 8c80 9831 3233 3435 3637 3839 3000 8d90
00000010: 972b 3335 3834 3032 3232 3232 322f 5459
00000020: 5045 3d50 4c4d 4e00 8918 802b 3335 3834
00000030: 3031 3131 3131 312f 5459 5045 3d50 4c4d
00000040: 4e00 9654 6573 7420 4d4d 5320 6d65 7373
00000050: 6167 6500 8504 3bd6 65f8 84a3 0201 3983
00000060: 5468 6973 2069 7320 616e 2065 7861 6d70
00000070: 6c65 204d 4d53 206d 6573 7361 6765 2077
00000080: 6974 6820 706c 6169 6e20 7465 7874 2061
00000090: 6e64 2069 6d61 6765 2e1d 83c3 6403 9e81
000000a0: 83ae 1780 8610 4a46 4946 0001 0201 0131
000000bo: 0131 0000 ffed 0de6 18
.
.
. 
...1234567890...
.+35840222222/TY
PE=PLMN....+3584
0111111/TYPE=PLM
N..Test MMS mess
age...;.e......9.
This is an examp
le MMS message w
ith plain text a
nd image....d...
......JFIF.....1
.1.......
.
.
. 
 
O cabeçalho contém principalmente informações de como transferir a mensagem 
do terminal de origem para o de destino. Cada campo de cabeçalho consiste de um campo 
de nome seguido de um campo de valor. 
Uma mensagem MMS pode conter um ou mais dos tiposde conteúdo abaixo: 
Texto: pode ser texto plano ou formatado 
Gráficos: suporte a tabelas, diagramas e gráficos animados (GIFs) entre outros 
Imagens: suporte ao envio/recebimento/edição de imagens, como por exemplo 
capturadas com câmeras integradas ao celular 
Áudio: suporte para música, voz e streaming de áudio 
Vídeo: suporte a clipes curtos (30 segundos) de vídeo. Futuramente poderá ser 
aumentada esta capacidade. 
Pode ser de seção única, contendo somente um objeto ou pode ser de múltiplas 
seções relacionadas (Multipart/related) [RFC2387]. Neste caso, o corpo contém vários 
objetos multimídia, cada qual em uma seção separada e a seção de apresentação. A seção 
principal (part root) é apontada pelo parâmetro Start. Um exemplo de técnica de 
apresentação no MMS e é conseguida com o SMIL (Synchronized Multimedia Integration 
Language). A ordem dos objetos não tem importância, mas a seção de apresentação deve 
ser a primeira no corpo com múltiplas seções. 
 15
 
 
Figura 5 
 
A apresentação MMS contém instruções de como o conteúdo multimídia deve ser 
reproduzido no display e auto-falantes do terminal. Uma seção de apresentação é 
necessária para cada representação em uma mensagem. Lembrando que, nas primeiras 
versões, os terminais suportavam somente uma seção de apresentação. 
Cada uma das multparts consiste de conteúdo e informação de identificação da 
multipart. Os cabeçalhos de cada parte contêm os seguintes campos: 
• Tipo de conteúdo: indicando o conteúdo na multipart, como image/jpeg ou 
text/plain; 
• Localização de conteúdo: identificando o conteúdo, como image.jpeg ou hello.txt. 
 
O corpo, também, pode ser de múltiplas seções misturadas (Multipart/mixed). 
Neste caso, contém vários objetos multimídia, cuja ordem não tem importância e não há, no 
corpo informação de apresentação. Desta forma, depende da implementação do terminal de 
como o conteúdo multimídia era apresentado. 
A figura abaixo mostra o modelo conceitual e um exemplo de encapsulamento. 
 
 16
 
Figura 6 
 
 
4.3 SMIL 
 
Mensagens MMS são baseadas no SMIL (Synchronized Multimidia Integration 
Language).O SMIL é similar ao HTML [5] na sintaxe e construções e é essencialmente 
uma maneira de sincronizar conteúdos multimídia ricos e interativos para a entrega em 
tempo real na web e, também, sobre conexões de banda estreita. No SMIL, a informação 
de apresentação é codificada em um arquivo de apresentação. A intenção é apresentar um 
conteúdo multimídia em uma ordem específica em um intervalo de tempo predeterminado. 
As apresentações de multimídia do SMIL consistem de elementos tais como 
vídeo, voz, imagens, texto, vídeo e gráficos todos sincronizados por meio de uma linha de 
tempo comum (isto é, não são entregues com anexos). 
Um exemplo de uma apresentação multimídia com SMIL são vídeos jornalísticos 
que enfatizam as manchetes das notícias, sendo também apresentado um quadro com 
informações da bolsa de valores na base da tela. 
Mensagens usando SMIL podem ser vistas como se tivessem um estilo 
“PowerPoint” no dispositivo móvel. Usando um simples editor de mídia, um usuário pode 
incorporar áudio e vídeo com imagens, animações e texto para criar uma apresentação 
multimídia completa. 
 17
As mensagens baseadas no SMIL são do tipo “slide show” e são caracterizadas 
por: 
• Ter um ou mais slides; 
• Cada slide deveria ser entendido como um quadro que incorpora o conteúdo, o qual 
será mantido separado; 
• Inicialmente, cada slide terá duas seções, uma para o texto e outra para a imagem. 
Slides podem ter somente texto ou somente imagem; 
• SMIL especifica o layout, a ordena e apresenta cada slide; 
• Os conteúdos do slide devem ser criados em um formato aprovado; 
• Os slides e os arquivos são empacotados em uma única mensagem. 
 
4.4 Tratamento da mensagem na rede 
 
O terminal solicita uma operação de WAP POST com a mensagem M-Send.req 
incluída como conteúdo do corpo. O terminal compõe uma ID da transação para a 
mensagem submetida. O ID é usado pelo terminal e pelo MMS Center para prover um elo 
entre a mensagem originada M-Send.req e a resposta M-Send.conf. O valor usado para a 
transação ID é determinado pelo terminal e nenhuma interpretação é esperada do MMS 
Center. A mensagem é submetida usando uma URI que endereça o MMS Center que dá 
suporte ao terminal especificado. 
A mensagem é transferida através do BSS para o SGSN, que a envia para o 
correto GGSN. 
O MMS Center atribui uma mensagem ID à mensagem quando recebida com 
sucesso para a entrega. Este ID é usado em atividades seguintes que necessitam se 
referenciar a mensagem específica enviada, como por exemplo, no envio posterior de um 
relatório de entrega. No receptor da mensagem de M-Send.req, o MMS Center responde ao 
WAP POST com uma resposta, que prove um código de status para a operação solicitada. 
Se o MMS Center aceitar o pedido para enviar a mensagem, o status é “accepted” e a 
mensagem inclui o ID da mensagem que o MMS Center havia fornecido. A mensagem de 
confirmação é roteada pelo mesmo caminho feito pelo M-Send.req. 
 
4.4.1 Enviando uma notificação de mensagem deferida 
 
Os cabeçalhos do PDU (aqueles que o MMS Center adicionaram ao PDU 
original) são usados para gerar uma notificação para o receptor, e são entregues com o 
corpo da mensagem para o receptor na recuperação. 
 18
Uma transação identificadora é criada pelo MMS Center antes de enviar a 
notificação e é única dependendo somente do M-NotifyResp seguinte. Se o cliente MMS 
solicitar adiar a entrega com M-NotifyResp, o MMS Center pode criar um novo 
identificador de transação. 
A notificação usa SMS como transportador: O MMS Center envia o M-
Notification.ind para o SMS Center, que posteriormente, envia a mensagem para o SMS-
GMSC. Este, por sua vez, pede informações de roteamento ao HLR, isto é, a localização do 
MSC com o qual o celular receptor estava conectado pela última vez. O SMS-GMSC, 
então, encaminha a mensagem para o MSC, que checa o VLR para se certificar que o 
celular não foi bloqueado ou alguma outra restrição para o uso da rede. O MSC, então, 
encaminha a mensagem através da BSS para o celular receptor. 
A informação no o M-Notification.ind inclui a URI que será usada para realmente 
recuperar a mensagem em uma operação subsequente pelo terminal receptor. Informações 
adicionais sobre a mensagem (como tamanho, e expiração) podem ser usadas pelo terminal 
para determinar seu comportamento. Por exemplo: o terminal pode atrasar a recuperação da 
mensagem se ela exceder o tamanho definido. O receptor de um M-Notification.ind 
informa a ação a ser tomada pelo MMS Center com o M-NotifyResp.req, que é roteado 
para o MMS Center da mesma forma que o M-Notification.ind. 
 
4.4.2 Mensagem de busca 
Se o receptor quiser buscar uma mensagem, ele envia o WSP GET.req para o 
MMS Center. A URI (endereço da MMS Center) requerida para a recuperação, enviada na 
mensagem M-notification.ind anterior, é usado no GET request. A informação que retorna 
(M-Retrieve.conf) do MMS Center para o celular receptor inclui a mensagem multimídia. 
Outros tipos de tratamento de mensagens na rede: 
• Alerta de assinante ausente 
• Relatório de entrega 
• Assinante em roaming 
 
 
4.4.3 Mensagem originada e terminada em uma aplicação 
 
 19
O roteamento de M-Send.req e M-Send.conf entre o celular que envia e a MMS 
Center acontece exatamente da mesma forma que com mensagens originadas e terminadas 
no celular. 
O MMS Center encaminha a PDU para uma aplicação externa que pode estar na 
mesma rede IP que o próprio MMS Center, ou em outra rede. Reconhecimentos entre o 
MMS Center e a aplicação externa depende do tipo desta aplicação externa. A ligação entre 
o MMS Center e a aplicação externa é feita pelo M-Send.req. 
 
 
Figura 7 
 
 20
 
Figura 8 
 
 
4.5 Interface de Aplicação Externa 
 
A Interface de Aplicação Externa (EAIF) dá à operadoraa possibilidade de 
introduzir uma variedade de aplicações externas e serviços de valor adicionado. É esta 
interface que seré usada na comunicação com aplicações externas, como e-mail e www. O 
protocolo utilizado para este fim é o HTTP 1.1. Este é um protocolo de comunicação muito 
utilizado na Internet e é baseado num esquema de requisições/respostas envolvendo um 
servidor e um cliente. No contexto de MMS, o servidor é a parte que recebe a mensagem e 
o cliente é a parte que envia a mensagem. Em se tratando de EAIF, tanto o MMSC quanto a 
aplicação podem fazer o papel de cliente ou servidor. 
Existem três operações que podem ser realizadas através da EAIF: 
- Aplicações podem enviar mensagens; 
- Aplicações podem receber mensagens; 
- Aplicações podem receber avisos de entrega de mensagens. 
 
As mensagens MMS são enviadas através da PDU M-Send.req e na transmissão 
de avisos de entrega de mensagens, a PDU M-Delivery.ind é utilizada. As PDUs são 
entregues através da interface de aplicação externa (EAIF) através do corpo das mensagens 
HTTP. 
 21
Os aspectos de segurança são tratados utilizando-se SSL (Secure Sockets Layer), 
que oferece métodos confiáveis de encriptação e autenticação entre a interface de aplicação 
externa e as aplicações externas. 
Para maiores informações sobre HTTP, veja [3], [7] 
 
4.6 Mensagens HTTP 
 
As PDUs MMS usadas na EAIF (M-Send.req e M-Delivery.ind) são entregues 
para /de aplicações no corpo do HTTP POST request. Um HTTP POST request consiste 
simplesmente de: 
• Cabeçalhos de extensão http (opcional) 
• Cabeçalhos http mandatórios 
• Corpo da mensagem 
A seguinte figura apresenta a estrutura de um HTTP request contendo os 
cabeçalhos de extensão e os mandatórios e a PDU MMS no corpo da mensagem. 
 
 
 
Figura 9 
 
Podemos examinar um pouco mais a fundo [6] uma requisição http para 
identificarmos os campos referentes ao cabeçalho http e o conteúdo da mensagem http, que 
neste caso é uma PDU MMS. A figura abaixo ilustra este detalhamento, mostrando a PDU 
MMS em formato texto, mas na verdade, ela é encapsulada na requisição HTTP em 
formato binário: 
 22
 
Figura 10 
 
4.6.1 Exemplo de uma mensagem MMS encapsulada numa requisição http: 
 
A tabela a seguir exemplifica o uso do encapsulamento da PDU MMS dentro da 
requisição HTTP. 
Requisição http de uma mensagem originada por aplicação contendo a M-Send.req 
POST / HTTP /1.1
Host: mmsc.operator.com:80
Content-Type: application/vnd.wap.mms-message
Content-Length: 188
m-send.req
 23
A M-Send.req no corpo da requisição HTTP do exemplo acima contém os 
seguintes cabeçalhos e os valores correspondentes: 
• X-Mms-Message-Type: m-send-req 
• X-Mms-Transaction-ID: 1884022032 
• X-Mms-Version: 1.1 
• From: +123444444444 /TYPE=PLMN 
• To: +123455555555/TYPE=PLMN 
• Subject: This is a Multimedia Message 
• Content-Type: application/vnd.wap.multipart.mixed 
O corpo da mensagem contém somente um texto plano: 
This message contains only this text. 
 
4.6.2 Conectividade com E-Mail 
 
O roteamento do M-Send.conf entre o aparelho que está enviando uma mensagem 
e o MMS Center acontece exatamente da mesma forma que com mensagens originadas e 
terminadas no aparelho. 
O MMS Center converte a mensagem multimídia para uma mensagem de e-mail 
normal e a envia para o servidor de e-mail. Este servidor reconhece a mensagem recebida 
usando o protocolo SMTP, o qual é usado na comunicação entre o MMS Center e o 
servidor de e-mail. 
SMTP entende apenas informação de texto puro e é usado efetivamente para a 
transferência de dados. MIME (Multipurpose Internet Mail Extension) é usado para dar 
suporte à transmissão de dados em formatos diferentes de ASCII (por exemplo arquivos gif, 
jpeg, wav, etc) como anexos de uma mensagem. 
 24
 
4.7 Celulares para MMS 
 
O dispositivo a seguir é um exemplo de um celular da Nokia com capacidade para MMS. 
 
 Series 40 Terminals 
 
• MMS send and receive (45kB) 
• Supported formats: 
– Basics from Conf. Doc. (baseline JPEG, GIF87a, GIF89a, 
WBMP) 
- animated GIF89a, PNG, Windows BMP 
- SP-MIDI – 43 instruments, 4 at a time 
- Nokia wallpaper (image/vnd.nok-wallpaper) – 
file format is JPEG, GIF87a, GIF89a, PNG, 
BMP 
- Nokia ringing tone 
(application/vnd.�okia.ringing-tone) 
• 128x128 display 
• In MMS Viewer, available display size is 122x96 
• Using COD: Nokia color operator logo 
(image/vnd.nok-oplogo-color) – 100x50 JPEG, 
GIF87a, or GIF89a image 
 
 
Figura 11 
 
4.8 Vídeo em MMS 
 
• Nokia 3650, 6650, 6220 e 6600 são capazes de tocar e gravar clipes de vídeo 
• O tamanho máximo em uma mensagem MMS é de 100 Kb. 
• Não há limite quando se grava um clipe local 
 
 
 
 
 
Figura 12 
 
 25
4.9 Criando mensagens MMS 
 
• Adobe GoLive w/Nokia Developers’ Suite for MMS [6] 
- criação baseada no SMIL e não há controle sobre os tipos MIME 
• Nokia Mobile Internet Toolkit 4.0 
- criação baseada no conteúdo, controle sobre tipos MIME e suporte a SMIL 
baseado em texto 
• Nokia MMS Java Library 1.1 
- tem um controle detalhado e requer um conhecimento mais profundo para ser 
operado 
• Nokia Mobile Server Services API and Library 1.2 
- também tem um controle detalhado e requer muito conhecimento 
 
 
 
Figura 13 
 
5. Conclusão 
 
Depois de toda a apresentação das características do serviço MMS, fazemos uma 
analogia que ilustra nossa visão sobre o assunto: A evolução do SMS para MMS 
representa, para o mundo das comunicações móveis, o que representou para o mundo da 
informática a mudança do DOS para o Windows. 
 26
6. Referências 
 
[1] Flying Boat <http://www.btinternet.com/~jidlaw/home.html> 
[2] Mobile MMS <http://mobilemms.com> 
[3] 3GPP <http://www.3gpp.org> 
[4] WAP Forum <http://www.wapforum.org> 
[5] W3C <http://www.w3.org> 
[6] Nokia Developer´s Guide to MMS 
[7] Nokia - MMS Center Application Development Guide – Version 1.0 – 04-03-2002