Documentation

ContextNet is composed of a set of components and technologies, such as Data Distribution Service (DDS), SDDL, MRUDP, and ClientLib. In this page you will encounter user and developer documentation for each ContextNet component. User documentation focus on topics related to the usage of the component, such as component interface (API) and component dependencies, while developer documentation focus on architectural and technical details of the component. A brief description of each component is presented below. The documentation itself can be accessed by clicking on the desired component.

Main components are essential elements of the ContextNet Architecture. Click on the component for the full documentation.

• MR-UDP: é uma versão estendida e otimizada do Reliable UDP, que implementa comuniacão confiável sobre UDP. Além de garantir entrega confiável de pacotes, o MR-UDP trata desconexões temporárias, e identifica os endpoints através de um UUID, em vez de endereços IP. Através de um mecanismo de heartbeat, possibilita também que nós móveis atrás de NAT/Firewalls possam manter conexões MR-UDP com Gateways.
• ClientLib: uma biblioteca para comunicação assíncrona no cliente móvel que encapsula os detalhes de uso do protocolo MR-UP através de uma interface ‘nodeConnection’, gerencia uma lista de endereços de Gateways alternativos (PoA), e realiza handovers (reconexões) do nó móvel entre Gateways de forma transparente. Além disso, bufferiza mensagens de aplicação para o SDDL Core enquanto o nó estiver desconectado a qualquer Gateway. Uma versão ClientLibServer executa no Gateway, para fazer o gerenciamento de várias conexões simultâneas com nós móveis. A ClientLib utiliza a tecnologia Protcol Buffers para a serialização/compactação de objetos transmitidos. Existem implementações Java e Lua para essa biblioteca.
  • GroupAPI e PubSubAPI: são duas sub-bibliotecas da ClientLib. A primeira permite que um nó gerencie a sua pertinência a grupos, e assim possa enviar e receber as mensagens groupcast do grupo correspondente. A PubSubAPI permite que um nó publique ou se subscreva em um tópico qualquer (definido por um nome), e passe a receber todas as mensagens publicadas no tópico correspondente. Através de um protocolo de controle, as expressões da subscrição (filter expressions) são enviadas para os publicadores Pub/Sub a fim de fazer a filtragem de mensagens na fonte.
• ELISA: é uma biblioteca multi-thread para aplicações Android, que consiste de um par de serviços Android, o LocationService e o ConnectivityService e um conjunto de Broadcast Receivers (Android) que conjuntamente registram a posição geográfica do nó (p.ex. usando GPS), e realizam o envio de mensagens da aplicação carregando a posição corrente do nó,. ELISA verifica o nível da bateria do dispositivo a cada T minutos (usando o Android AlarmManager) e de acordo com a classsificacão em um de três níveis de energia - alta, média e baixa - define as frequências da leitura de posição e do envio dos dados, de modo a minimizar o consumo de energia do dispositivo. O ConnectivityService utiliza a ClientLib para bufferizacão, envio e recebimento das mensagens para o SDDL Core.
• UDI: é uma API similar a do DDS, mas que abstrai os detalhes específicos de diferentes produtos DDS, e inclui wrappers de tópicos DDS para cada produto DDS. Permite também a definição de politicas e perfis de QoS que são mapeados para as primitivas específicas de cada produto DDS. O uso da UDI facilita muito a troca entre produtos DDS. Atualmente, a UDI está disponível para os produtos: RTI Connext, DDS Open Splice Community Edition, e CoreDX DDS.
• Gateway: é um serviço do SDDL Core Network (executa em um nó do cluster/nuvem) que é responsável por gerenciar conexões MR-UDP com vários nós móveis. Suas tarefas incluem a notificação de conexões e desconexões de nós móveis, e a transcodificação de mensagens de aplicação difundidas no domínio DDS (SDDL Core) para o MR-UDP e o encaminhamento para o nó móvel correspondente, bem como a transcodificação inversa, do MR-UDP para o tópico DDS de aplicação. Além disso, o Gateway mantém os mapeamentos de nós para grupos, a fim de encaminhar mensagens groupcast para os nós membros do grupo. Devido às propriedades Peer-to-Peer e do desempenho escalável da comunicação no DDS, pode-se usar vários Gateways em paralelo, cada um atendendo a um sub-conjunto dos nós móveis, conferindo assim, escalabilidade na comunicação de/para nós móveis.

Extensions are optional services or APIs built on top of the Main components. Click on the component for its full documentation.

• Context Management Service (CMS): é um framework mobile (para Android) que possibilita o carregamento, registro e ativação dinâmica de componentes provedoras e consumidoras de contexto (ContextProviders - CxtP e ContextConsumers – CxtC). ContextProviders podem ser simples, quando coletam dados diretamente dos sensores do dispositivo móvel, ou então compostos, quando agregam, compõem ou transformam dados obtidos de outros ContextProviders mais básicos. Utilizando a Pub/SubAPI da ClientLib um CxtP pode se subscrever a dados fornecidos por outros CxtPs, tanto locais (no mesmo nó/dispositivo), como remotos (em outro nó). Desenvolveu-se também diversos ContextProviders simples para vários dos sensores acessíveis através da plataforma Android, como Location, Accelerometer, Gyroscope, etc. que podem ser disponibilizados em um repositório de ContextProviders.
• GroupDefiner: é um serviço do SDDL Core responsável por gerenciar a pertinência de nós a grupos, e notificar todos os Gateways sobre qualquer mudança nos membros dos grupos. Em particular, o GroupDefiner suporta grupos dinâmicos de nós, cuja pertinência é definida por algum atributo da mensagem de aplicação (ou de uma informacão de conetxto) enviada pelo nó, como por exemplo sua posição corrente. Naturalmente, também é possível definir grupos fixos de nós móveis e/ou do SDDL Core. Mensagens group-cast são então definidas por um Group UUID.
• PoA-Manager: é um serviço que distribui endereços de Gateways alternativos (PoA-lists) aos nós móveis, e que pode enviar comandos à ClientLib dos nós correspondentes solicitando que estes se reconectem a um novo Gateway, possibilitando assim a re-distribuição da carga de conexões entre Gateways. Isso pode ser feito quando se detecta um desbalanceamento entre os números de conexões MR-UDP, e em particular, quando Gateways são adicionados ou removidos do SDDL Core. Além disso, o PoA-Manager recebe de todos Gateways relatórios periódicos sobre as suas cargas. A política de balanceamento de carga, no entanto, é parametrizada, e pode ser configurada de acordo com as necessidades da aplicação.
• Mobile Temporary Disconnection (MTD): é um serviço que intercepta e bufferiza todas as mensagens endereçadas a um nó móvel enquanto este se encontra desconectado de qualquer Gateway. Assim que o nó se reconecta a um novo Gateway, o MTD é informado, e faz um replay de todas as mensagens acumuladas para entrega ao nó, através do novo Gateway ao qual o nó móvel está conectado.
• LoadBalancer: é um serviço que define fatias/faixas do volume total de dados incidentes dos nós, a serem processados por Processing Nodes (PN) genéricos no SDDL Core (vide Figura 1), monitora a carda destes PNs e faz uma distribuição de dinâmica dessas fatias para cada PN, permitindo assim um balanceamento na carga de processamento entre vários PNs. Para que os PNs sejam capazes de ‘trocar” as fatias, a lógica de processamento deve acessar os tópicos DDS através de um stub específico da UDI.
• GroupReplayService: é um serviço do SDDL core que persiste em um banco SQLite todas as mensagens recentes (período é parâmetro) enviadas a cada grupo de nós (group-cast). Assim, sempre que um novo nó é inserido no grupo, todas as mensagens que este não recebeu são re-enviadas para esse nó.
• Mobile Hub (M-Hub) é a componente mobile do ContextNet para Internet of Things (IoT), e atua como intermediário entre os Smart Objects e o SDDL Core. Comparado com ELISA, contém também o Short -range Sensor, Presence and Actuation (S2PA) Service. Este serviço é responsável por descobrir Smart Objects na vizinhança do smartphone, se conectar a estes, receber dados de sensores de (ou enviar comandos de atuação para) os Smart Objects. Atualmente, o S2PA contém um módulo para Bluetooth Classic e Bluetooth Low Energy (BLE). Em breve o S2PA terá também um módulo para ZigBee, que poderá ser usado quando o Mobile Hub executar no Beaglebone. Além disso, o Mobile Hub suporta um serviço para processamento de eventos complexos chamado de Mobile Event Processing Agent (M-EPA).
• Persistence Service (Persistence): é a parte de persistência na nuvem do dados coletados pelos Mobiles Hubs, persistindo os dados coletados pelo Mobile-Hub e enviando repostas e resultados de pesquisas feitos por esses. O projeto foi implementado para usar o banco de dados ctree-ACE (FAIRCOM) e suporta tipos de mensagens específicos. No momento suporta pesquisas SQL, pois o banco de dados mesmo sendo NoSQL, possui uma camada SQL.

• D3CEP: D3CEP is a Distributed Event Processing middleware architecture on the SDDL Core, which allows the dynamic deployment of networks of Event Processing Agents (EPAs). Each of such agents execute one or more Event-Condition-Actions (ECA) rules. These rules describe sub-patterns of events to be detected from the agent’s input events. Many agents are connected to each other in an Event Processing Network (EPN) to compose a global processing logic, in which each agent’s output produces more abstract events that are consumed by other agent’s input. The data-centric aspect of D3CEP provides an optimized performance for the routing of events among clustered processing nodes that execute EPAs, distributing the processing of an EPN to achieve scalability, and also optimizes the management of state among EPAs for the processing of distributed CEP rules. The dynamic aspect of D3CEP provides flexibility in the definition and re-definition of event types, rules and situations of interest at execution time, without the need to stop a monitoring system. D3CEP requires the usage of a DDS product that implements the OMG DDS XTypes standard specification.

• DG2CEP: is an on-line algorithm inspired by data mining algorithms and based on Complex Event Processing stream-oriented concepts for on-line detection of spatial-temporal clusters. The main idea of DG2CEP is to mitigate the clustering process by first mapping the position data to CEP context partitions, and then clustering the partitions rather than the nodes (using a DBSCAN-like expansion). Our experiments indicates that DG2CEP can rapidly detected, in less than few seconds, the cluster formation and dispersion. In addition, the required time to detect such clusters scale linearly with the number of nodes.

Tools are reusable elements that are used by ContextNet Elements. They can also be used by ContextNet developers.

• JTS Topology Suite Helper: é uma biblioteca de apoio para descrever modelos geométricos em 2D e contém funções geométricas básicas de processamento sobre essas estruturas, tais como centroid(), interseção de dois polígonos, verificacão de ponto dentro de um polígono. A JTS Helper foi otimizada para attender milhões de operacões por minuto.

• Hakke é um Gateway específico para acesso Web que consiste de um Web Server e um nó SDDL). Transmite comandos em JSON de /para JavaScripts nos Browsers que podem ser definidos de acordo com as necessidade de visualização e interação com nós do SDDL Core e os nós móveis.

• MN-Simuator é um simulador de nós móveis (Mobile Nodes - MN) em Java. Executa cada MN em uma thread independente, gerando uma coordenada geográfica hipotética e transmitindo-a periodicamente (parâmetro do simulador) para o SDDL core.

• MHO-Simulator é um simulador em Java de x Mobile Hubs e y Mobile Objects, que estabelecem uma conexão esporádica e aleatoria entre sí, de acordo com certo parâmetro. Uma vez que um M-OBJ fica associado a um M-Hub, permanece assim durante um certo intervalo de tempo simulado, durante o qual o M-OBJ gera dados de sensores hipotéticos e os transmite para o M-Hub. O M-Hub executa a ClientLib e MR-UDP para comunicação com um Gateway, e o S2PA para descoberta, transmissão de dados (do M-OBJ para o SDDL Core), bem como o handover de M-OBJs entre M-Hubs. O M-Hub acrescenta uma coordenada geográfica fictícia a cada mensagem de sensor obtida de um M-OBJ conectado.

• UAV-Simulator é um simulador similar ao MN-Simulator, mas que se desloca de acordo com um itinerário (lida de um arquivo), transmite periodicamente as suas coordenadas geográficas de acordo com esse itinerário, e é capaz de processar comandos recebidos da ClientLib, para mudar o seu comportamento de voo.