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ções de

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

ABTS 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 externa para 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 8d9000000010: 972b 3335 3834 3032 3232 3232 322f 545900000020: 5045 3d50 4c4d 4e00 8918 802b 3335 383400000030: 3031 3131 3131 312f 5459 5045 3d50 4c4d00000040: 4e00 9654 6573 7420 4d4d 5320 6d65 737300000050: 6167 6500 8504 3bd6 65f8 84a3 0201 398300000060: 5468 6973 2069 7320 616e 2065 7861 6d7000000070: 6c65 204d 4d53 206d 6573 7361 6765 207700000080: 6974 6820 706c 6169 6e20 7465 7874 206100000090: 6e64 2069 6d61 6765 2e1d 83c3 6403 9e81000000a0: 83ae 1780 8610 4a46 4946 0001 0201 0131000000bo: 0131 0000 ffed 0de6 18...

...1234567890...

.+35840222222/TYPE=PLMN....+35840111111/TYPE=PLMN..Test MMS message...;.e......9.This is an example MMS message with plain text and 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 tipos de 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á à operadora a 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.1Host: mmsc.operator.com:80Content-Type: application/vnd.wap.mms-messageContent-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