WirelessBR		WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade  comercial,  feito por voluntários, para divulgação de tecnologia em telecomunicações
Pesquisa e Projeto de uma Aplicação em Computação Móvel para  Monitoramento de Pacientes em UTI     (04)
Autora: Líliam Carla Gaiotto Maluta

Capítulo 2 (Cont)

2.5  Adaptabilidade a Mudanças

            Segundo MATEUS (2001), o sucesso de uma aplicação em computação móvel está diretamente vinculado à adaptação, o que significa dizer que o resultado depende das condições existentes no ambiente, em um determinado instante no tempo. Sendo assim, se um ambiente apresenta baixa largura de banda e alta taxa de erro, pode-se optar por exibir apenas os dados mais relevantes e retomar o processamento normal assim que o usuário passe a acessar uma infra-estrutura de comunicação mais rápida.

A adaptação, do ponto de vista do sistema, pode ser feita através da criação e utilização de protocolos específicos para computação móvel. Neste contexto, há uma adaptação do protocolo à situação da rede, podendo haver troca de protocolos, ajustes no tamanho dos pacotes, aumento na compressão dos dados, utilização de cache durante períodos de alta conectividade, etc.

  A infra-estrutura existente para suportar aplicações em ambientes móveis, como visto, é bastante variável e estas variações devem ser refletidas na aplicação no momento em que as mesmas ocorrem. A velocidade de deslocamento de um usuário, e as condições ambientais devem ser levadas em consideração para se aumentar a usabilidade[7] do sistema.

            Técnicas de análise de tarefas devem ser utilizadas para descobrir quais informações são mais relevantes ao usuário, projetando-se assim, aplicativos capazes de adaptarem-se através da priorização de uma informação em detrimento de outra. Algumas aplicações podem ser personalizadas, outras devem ser genéricas.

              Existem várias técnicas para adaptação de aplicações ao ambiente de computação móvel, como a de modificação on-the-fly. Dependendo das condições e do dispositivo utilizado, o aplicativo poderia trazer uma interface com mais ou menos componentes ou componentes menores, com menos detalhes.

              Outra abordagem seria a utilização de cache local, possibilitando que enquanto um usuário estivesse lendo um determinado capítulo, a aplicação fosse buscando os demais e armazenando. Caso a conexão estivesse ruim, a aplicação poderia trazer somente títulos/seções e solicitar intervenção do usuário para que faça sua escolha. A aplicação deve ser transparente, porém, não sendo possível deve-se deixar o controle a cargo do usuário.

  A construção de interfaces de aplicativos é dependente dos dispositivos móveis, pois estes possuem características singulares, as quais limitam as aplicações a serem executadas. A entrada de dados é um aspecto crítico. Novas formas de interação usuário-aplicação-dispositivo móvel vem sendo criadas e devem ser pesquisadas a fim de melhorar a interação.

             A interface, freqüentemente o fator mais importante para o sucesso de um projeto de software, deve modificar-se às variações do ambiente, ser tão transparente quanto possível, sem deixar de ser ‘usável’.

              Para que se verifique a percepção de mudanças no ambiente de execução e auto-adaptação adequada, faz-se necessário redefinir tarefas e formas de interação entre o software do sistema e as aplicações. Assim, é desejável que:

•    O software seja capaz de monitorar o nível de energia e ter acesso a dados da interface de comunicação sem fio; tenha a capacidade de trocar dinamicamente alguns de seus módulos e variar políticas de uso de recursos; disponibilize canais para notificação de eventos de mudança no ambiente;

•    Haja uma interface através da qual aplicações possam requisitar ao software do sistema alterações de modulo e/ou política;

•    Aplicações sejam adaptáveis a novos contextos de execução por meio de chaveamentos entre procedimentos/módulos com funções similares, mas que difiram sobre demandas de recursos locais e remotos.

 2.5.1  Taxonomia das estratégias de adaptação

A adaptação pode ser vista como de inteira responsabilidade das aplicações (laissez-faire), do sistema (application-transparent adaptation) ou de ambos (application-aware adaptation) (JING 1999). Na primeira hipótese, a adaptação é de inteira responsabilidade das aplicações, evitando-se a necessidade de um sistema de suporte e ocasionando a falta de um mediador capaz de resolver incompatibilidades nas demandas e limites no uso de recursos. Sendo assim, aplicações ficam mais difíceis de serem escritas.

          Na segunda, a adaptabilidade é restrita ao software do sistema e ocorre apenas notificação de eventos ao usuário. É compatível com aplicações convencionais (sistemas legados), mas existem circunstâncias onde a adaptação realizada pelo sistema é inadequada e, às vezes, até contra-produtiva. Este modelo faz com que as aplicações trabalhem como se não houvesse modificações no ambiente, isto é, o sistema esconde das aplicações, as diferenças entre ambientes fixos e móveis.

          Neste ambiente, um proxy[8] rodando no dispositivo móvel é responsável por prover uma interface de serviços para as aplicações. Existem duas aplicações básicas: proxy de sistema de arquivo e proxy web. No sistema Coda (SATYANARAYANAN, 1995), um exemplo do primeiro caso, mecanismos automáticos para resolução de conflitos são providos para diretórios e arquivos, através do proxy e do servidor de arquivos. No segundo caso, proxies web podem ser usados para trazer páginas da web  para a cache do dispositivo móvel, para compressão de imagens e para suportar operações desconectadas e assíncronas. WebExpress usa este modelo para fornecer transparência ao navegador e ao servidor web (ou proxy).

           Por fim, a última abordagem apresenta um padrão de colaboração entre as duas primeiras, permitindo que aplicações determinem como melhor se adaptar e garantindo que o sistema possa monitorar os recursos e tomar decisões de alocação. Por ser mais flexível é uma estratégia adequada ao desenvolvimento de novas aplicações. Dependendo de onde reside a lógica da aplicação, pode ser dividida em adaptação da aplicação baseada no cliente, em cliente-servidor e no proxy (na rede fixa).

            Odyssey, uma aplicação baseada no cliente, demonstra uma adaptação colaborativa onde o sistema provê os mecanismos de adaptação (monitora recursos, notifica aplicações sobre mudanças e decide onde alocar recursos), enquanto as aplicações estão livres para especificar as políticas (NOBLE, 1997). Esta divisão de responsabilidade endereça problemas relativos a diversidade da aplicação e concorrência.

  Em sistemas de informação móveis, dados podem variar no formato e apresentar inconsistência. Utilizando o enfoque colaborativo, a diversidade pode ser solucionada pelas aplicações, através da definição de como os dados deverão ser apresentados no cliente para que estejam consistentes à cópia de referencia armazenada no servidor. Ao sistema, fica a responsabilidade de controlar a monitoração de recursos. Entretanto, a opção de alterar as chamadas ao sistema, pode dificultar sua utilização em ambientes altamente heterogêneos, típicos da computação móvel (ENDLER, 2000b).

             Uma aplicação baseada em cliente-servidor, a ferramenta Rover, suporta adaptação através do uso de objetos dinâmicos realocáveis (RDO). Objetos devem ser definidos para tipos de dados a serem manipulados pela aplicação e para dados transportados entre o cliente e o servidor. O programa deve ser dividido em partes de código que rodam no cliente e outras no servidor, as quais devem comunicar-se através de chamadas a procedimento remoto.

              O projeto BARWAN é um caso de aplicação baseada em proxy, que usa transcodificadores para otimizar a qualidade do serviço para o cliente. Não trata problemas de desconexão e é focado em serviços (BREWER et al, 1998).

 2.6  Protocolos e serviços

              Protocolos são representativos para a execução de serviços em computação móvel, portanto, seus projetos devem ser vistos como uma tarefa integrada. Existem vários tipos de protocolos e serviços inseridos neste contexto, dentre os quais o IP móvel, WAP, SMS e SMPP.

 2.6.1  IP móvel

     O protocolo IP usado na Internet define que cada destinatário existente em uma rede fixa possui um identificador de endereço IP, que determina o roteamento de pacotes a serem recebidos. Dispositivos móveis mudam de localização durante uma comunicação, podendo possuir um endereço IP diferente em cada ponto de acesso à rede fixa.

                Diante do relato, soluções começaram a ser levantadas. Fornecendo-se um novo endereço IP para o dispositivo, que correspondesse à nova localização, ter-se-ia que informar pessoas, bancos de dados e programas sobre a alteração. Fazer com que roteadores utilizassem os próprios endereços IP para roteamento exigiria milhões de entradas em suas tabelas (LIMA, 2000).

                A fim de resolver este problema, a IETF (internet engineering task force) elaborou o protocolo IP móvel. Este padrão assume que existem dois endereços IP para cada elemento móvel: um endereço fixo (home address) e outro que é atualizado em cada mudança de ponto de acesso à rede (care of address).

               Pacotes endereçados ao dispositivo móvel devem ser enviados ao home address o qual deve empacotar o pacote recebido, adicionar um novo cabeçalho contendo o endereço do care of address e remetê-lo ao destinatário. Neste processo de tunelamento, o IP móvel provê transparência de localização para as aplicações e outros protocolos de alto nível como o TCP.

               O IP móvel já está implementado em alguns produtos comerciais e em roteadores (MATEUS, 1998). O IPv6 móvel (PERKINS, 1996), provável protocolo padrão para redes móveis, apresenta os mesmos princípios de projeto, com o acréscimo de criptografia e autenticação. 

            Apesar de todas as possíveis facilidades provenientes do uso deste protocolo, ainda faltam encontrar as devidas respostas para as seguintes questões:

•      Como garantir que uma mensagem de troca de endereço físico, recebida por uma estação base, foi enviada por um dispositivo pertencente a esta estação e não a um elemento impostor;

•      Como garantir que todos pacotes enviados cheguem ao destino;

•      Como tratar a insegurança proporcionada pelas redes públicas;

•      Como garantir a privacidade e correção de pacotes transmitidos.

 2.6.2  WAP

O WAP (wireless application protocol) é a especificação de um conjunto padrão de protocolos de rede e de aplicação, criado para permitir interoperabilidade entre diversas tecnologias de comunicação sem fio (ENDLER, 2000b).

  Adota o modelo cliente/proxy/servidor, com o proxy agindo principalmente como um gateway de protocolos, convertendo a pilha WAP para a pilha HTTP/TCP/IP, a fim de assegurar a interoperabilidade entre clientes WAP e servidores HTTP. A arquitetura WAP provê um ambiente escalável e extensível para desenvolvimento de aplicações. Será vista com maiores detalhes no Capítulo 4.

 2.6.3  SMS

   O SMS (Short Message Service), concebido com o objetivo inicial de substituir os sistemas de pagers alfanuméricos, foi elaborado para efetuar a transmissão de mensagens de texto, com 160 caracteres em média[9], de e para celulares, fax, máquinas (machine to machine ou M2M) e através do endereço IP (TeleCommunication Systems, 2002).           

    Usado inicialmente em redes GSM, como parte deste padrão, foi estendido para TDMA, CDMA, iDEN, NMT, Globalstar entre outros, não estando disponível apenas para poucas redes analógicas como a TACS/ETACS[10]. Seu uso vem apresentando um crescimento considerável, devendo-se ao fato da facilidade com que serviços podem ser estabelecidos, aliados ao baixo custo e simplicidade na redação e envio de mensagens. Adicionalmente, estão surgindo novos serviços pull ou push (solicitados ou não) (CRITICAL PATH, 2001).

  Uma característica deste serviço, que o distingue dos demais, é a capacidade de receber ou submeter mensagens mesmo que haja ou não uma chamada em andamento (dados ou voz). Além disso, pode garantir a entrega via algum protocolo como o SMPP.

  O SMS utiliza-se de um serviço de store and forward oferecido pelo SMSC (Short Message Service Center). Desta feita, ao se enviar uma mensagem, esta é recebida pelo SMSC, que se encarrega de encaminhá-la ao celular. Para isso, o SMSC envia uma requisição SMS ao HLR[11] (Home Location Register) para que este encontre o destinatário, verificando se o mesmo está ativo e em que célula se encontra. Se o destino estiver inativo, o SMSC deve segurar a mensagem por um período de tempo (tempo de validade), não existindo uma definição padrão para esta configuração, e isto dependerá do contrato estabelecido entre o cliente e a operadora. 

  Quando o dispositivo é ligado ou entra em uma área de cobertura, o HLR deve notificar o SMSC, que se encarrega de fazer a entrega da mensagem ao sistema, e este, de chamar o dispositivo. Havendo resposta, a mensagem é entregue. Numa segunda etapa, o SMSC recebe a notificação de que a mensagem foi recebida pelo usuário e a seta como enviada, não necessitando novo envio. Por outro lado, a plataforma SMSC possui um esquema de re-tentativas de entrega da mensagem para o caso de não receber o alerta do HLR.

 2.6.3.1  Concepções Funcionais

    Em princípio, o universo SMS está dividido em duas concepções funcionais, MO e MT. As MOs (Mobile Originations) são mensagens originadas a partir de uma estação móvel e podem ser destinadas tanto para dispositivos móveis, quanto para redes fixas. Aparelhos com possibilidade técnica de enviar mensagens (Nokia "i") possuem uma flag responsável por setar a função de pedido de leitura. Assim, quando a flag está setada, no ato do recebimento da mensagem, o destinatário sinaliza ao originador indicando que recebeu a mensagem. Ao abrir para leitura da mesma, ocorre outra sinalização em direção ao originador, informando que o destino leu a mensagem.

    As MTs (Mobile Terminations) se originam a partir de aplicações, normalmente SMPP (Short Message Peer to Peer Protocol), submetidas ao SMSC por sistemas de voice mail, por exemplo, e transportadas do SMSC ao dispositivo móvel. Na especificação do protocolo SMPP (SMPP Developers, 1999), existe a possibilidade, assim como na concepção MO, de requerer o "pedido de leitura". A única diferença é a de que, ao invés de um aparelho celular receber as sinalizações (de entrega, leitura ou falha), agora é a aplicação SMPP que irá receber essas sinalizações.  

    Muitas aplicações podem ser implementadas usando MOs e MTs, como serviços de notificação (voice mail, lembretes e avisos), e-mail, pager e serviços de informação (acesso sem fio a dados por usuários corporativos, tráfego, tempo, entretenimento e financeira).

 2.6.3.2  Eventuais problemas e/ou ataques

   Job de Haas, pesquisador da empresa de segurança ITSX, demonstrou como é possível travar certos modelos de celular a partir da manipulação de mensagens curtas (SMS). As técnicas para travar um aparelho consistem em enviar uma mensagem com uma serie de 160 caracteres "." ou "-" para aparelhos com uma arquitetura GSM (padrão universal para aparelhos móveis) antiga ou uma mensagem com um cabeçalho propositalmente mal-formado (HAAS, 2001). 

Em aplicações mais avançadas de comunicação via SMS, como logística e segurança patrimonial (AVL [12]/LBS), utiliza-se o modo PDU [13] (protocol data unit) para envio de dados. Nestas situações, um "attack" com SMS adulterado pode causar problemas. Supondo-se que determinado modem tenha certa vulnerabilidade quanto ao recebimento de SMS PDU mal formados e que uma certa rede de distribuição possua "vending machines" utiliza este tipo de modem, se uma lista com o número de todos modems destas maquinas cair na mão de pessoas mal intencionadas, tem-se um grave problema.

 2.6.4  SMPP

O protocolo SMPP (Short Message Peer to Peer) é um protocolo aberto, desenvolvido pela Lógica, com o objetivo de prover uma interface de comunicação para troca de mensagens entre uma central de mensagens, como SMSC (um servidor SMPP), GSM USSD[14] (um servidor USSD) ou CBC (Cell Broadcast Centre); uma aplicação SMS (denominada ESME ou External Short Message Entity, um cliente SMPP) como, por exemplo, um Proxy WAP para aplicações do tipo WAP Push (muito utilizado no MMS - Multimídia Message Service), um sistema de Voice Mail, para a notificação de mensagens, um servidor de E-mail; e um gateway de mensagens, comumente chamado de RE (Routing Entity) o que pode ser visualizado na figura 2.1. Uma RE pode emular funcionalidades tanto de uma central de mensagens, como de uma ESME.

      Em linhas gerais, o protocolo SMPP caracteriza três principais entidades, que são o SMSC, a ESME e a SME (Short Message Entity), sendo esta última, por exemplo, um aparelho celular.

             O sistema de MMS utiliza o SMPP para se comunicar com o SMSC para enviar uma mensagem de Push, que faz com que o terminal "encontre o caminho" para chegar até a figura que deve ser baixada no aparelho. Nos casos onde o celular não suporta o serviço MMS, o MMSC (Multimídia Message Service Center) envia uma mensagem SMPP para o SMSC, pedindo para este enviar uma mensagem de texto normal, contendo a URL onde pode ser visualizada a mensagem. 

Nos sistemas TDMA (ANSI-136), o aviso de mensagem de voz é enviado pela própria plataforma de Voice Mail[15], utilizando o MWI (Message Waiting Indicator). Nos sistemas GSM o Voice Mail avisa o SMSC (Short Message Service Center) de que o cliente possui uma mensagem de voz. O SMSC, por meio do protocolo SMPP, envia então um SMS avisando o cliente que existem mensagens não lidas armazenadas. Além destas, o SMPP suporta também as tecnologias IS-95 (CDMA) e iDEN (SMPP Developers, 1999).

             Usando o protocolo SMPP, uma ESME (entidade externa de mensagens curtas) pode iniciar uma conexão da camada de aplicação com um SMSC sobre uma conexão TCP/IP ou X.25 e então enviar e receber mensagens curtas do SMSC. Uma ESME pode também examinar, cancelar ou realocar mensagens usando SMPP. 

             O SMPP suporta um conjunto de funções para envio de mensagens tais como:    

•       Transmitir mensagens de um ESME para um ou vários destinos via SMSC;

•       Uma ESME pode receber mensagens via SMSC de outra SME (estação móvel);

•       Examinar o status de uma mensagem armazenada no SMSC;

•       Enviar uma mensagem registrada (um recibo de entrega será devolvido pelo SMSC ao originador da mensagem);

•       Agendar a entrega de mensagens, selecionando a data e a hora de entrega;

•       Selecionar o modo de transmissão da mensagem, datagrama ou store and forward;

•       Definir a prioridade de entrega da mensagem;

•       Definir o tipo de codificação da data da mensagem;

•       Setar o período de validade;

•       Associar um tipo de serviço a cada mensagem (voice mail).

            Com a necessidade de interoperabilidade, ou mesmo, troca de SMS entre operadoras, o SMPP (Lógica) vem sendo utilizado neste contexto. A maioria absoluta dos fabricantes de SMSC incluiu o suporte ao SMPP em suas plataformas. Cada fabricante também possui o seu protocolo nativo, como EMI/UCP (CMG), CIMD (Nokia), porém o SMPP acabou tornando-se o padrão de fato.

---