Skip to content
Browse files

Chap 5 goes on.

  • Loading branch information...
1 parent 4a7a4f9 commit 784a08780e786b1a37c9165d942404dee4863655 mnobrega committed Oct 29, 2012
View
15 0_cfg_misc/0_acronyms.tex
@@ -39,7 +39,20 @@
\acro{NIC}{\acroemph{Network Interface Card}}
\acro{PHY}{\acroemph{Physical Layer}}
\acro{GSM}{\acroemph{Global System for Mobile Communications}}
- \acro{EMoS}{\acroemph{Elder Monitorization System}}
+ \acro{EMoS}{\acroemph{Elder Monitoring System}}
+ \acro{IEEE}{\acroemph{Institute of Electrical and Electronics Engineers}}
+ \acro{SD}{\acroemph{Secure Digital}}
\acro{MN}{\acroemph{Mobile Node}}
\acro{SN}{\acroemph{Static Node}}
+ \acro{BN}{\acroemph{Base Node}}
+ \acro{RSSI}{\acroemph{Received Signal Strength Information}}
+ \acro{PC}{\acroemph{Personnal Computer}}
+ \acro{RREQ}{\acroemph{Route Request}}
+ \acro{RREP}{\acroemph{Route Response}}
+ \acro{RREP-ACK}{\acroemph{Route Response Acknowledge}}
+ \acro{RERR}{\acroemph{Route Error}}
+ \acro{APP}{\acroemph{Application Layer}}
+ \acro{FIFO}{\acroemph{First In First Out}}
+ \acro{TTL}{\acroemph{Time To Live}}
+ \acro{ARP}{\acroemph{Address Resolution Protocol}}
\end{acronym}
View
11 0_cfg_misc/d_code_highlighting.tex
@@ -61,4 +61,15 @@
xleftmargin=2em,
xrightmargin=2em
}
+}{}
+
+\lstnewenvironment{annex-code}[2]{
+ \lstset{
+ caption=#1,
+ label=#2,
+ style=workflowStyle,
+ captionpos=t,
+ xleftmargin=2em,
+ xrightmargin=2em
+ }
}{}
View
2 1_capa-resumo-indice/1_capa.tex
@@ -24,7 +24,7 @@
% The supervisor. Use the second command if required.
% Always remember that 'Professor' should only be used for a supervisor with a Cathedra
-\supervisor{Doutor Renato Jorge Caldeira Nunes}
+\supervisor{Doutor Renato Jorge Caleira Nunes}
\othersupervisor{Doutor António Manuel Raminhos Cordeiro Grilo}
% Date of the dissertation
View
4 2_texto_principal/1_intro.tex
@@ -36,8 +36,8 @@ \section{Objectivos}
\item Identificar necessidades num ambiente doméstico e propor para estas, soluções de hardware existentes no mercado;
\item Identificar uma plataforma de simulação existente que permita, de uma forma realista, simular o comportamento do sistema;
\item Definir a arquitectura do sistema e os papeis de cada interveniente;
- \item Implementar a simulação de um algoritmo de encaminhamento;
- \item Implementar a simulação de um algoritmo de localização;
+ \item Implementar a simulação de um protocolo de encaminhamento;
+ \item Implementar a simulação de um sistema de localização;
\item Analisar a simulação criada com métricas que permitam conhecer o erro de localização, bem como os limites e valores óptimos do sistema.
\end{itemize}
View
8 2_texto_principal/2_state_of_the_art.tex
@@ -23,7 +23,7 @@
\section{Monitorização com Sinal Vídeo ou Áudio}
\label{chap:2:sec:1}
-Em \cite{2} através de um sensor wireless equipado com um acelerómetro e transportado pela pessoa, são detectadas possíveis quedas. Por forma a minimizar o número de falsos alarmes, são usadas câmaras que cobrem o espaço, que analisam a posição da pessoa e são activadas de acordo com a localização do nó móvel. Essa localização é obtida através de triangulação baseada nas posições conhecidas dos nós fixos e a potência recebida do nó móvel. É também apresentada a possibilidade de efectuar transmissão de voz utilizando o rádio IEEE 802.15.4, uma vez que já existem rádios com largura de banda necessária para efectuar transmissão de voz.
+Em \cite{2} através de um sensor wireless equipado com um acelerómetro e transportado pela pessoa, são detectadas possíveis quedas. Por forma a minimizar o número de falsos alarmes, são usadas câmaras que cobrem o espaço, que analisam a posição da pessoa e são activadas de acordo com a localização do nó móvel. Essa localização é obtida através de triangulação baseada nas posições conhecidas dos nós fixos e a potência recebida do nó móvel. É também apresentada a possibilidade de efectuar transmissão de voz utilizando o rádio \acs{IEEE} 802.15.4, uma vez que já existem rádios com largura de banda necessária para efectuar transmissão de voz.
\begin{figure}[!htb]
\centering
@@ -62,7 +62,7 @@ \section{Monitoriza
\label{chap:2:sec:2}
Com a evolução dos sensores wireless aparecem cada vez mais soluções que permitem fazer uma monitorização contínua do estado de saúde de uma pessoa, independentemente da sua localização ou actividade. A redução do tamanho dos sensores permite idealizar a criação de vestuário com sensores embutidos, suficiente leve e confortável para poder ser usado diariamente. Para além da monitorização há também a possibilidade de administrar medicamentos, recorrendo a actuadores, automaticamente ou de forma manual por um profissional de saúde de forma remota.
-Em \cite{8} é abordada a \acf{BSN} como solução para a detecção precoce de problemas cardíacos. Através de um conjunto de sensores equipados com medidor de temperatura, medidor de pulso, acelerómetro e até sensores capazes de obter um electrocardiograma\footnote{Representação gráfica da actividade eléctrica do coração} (ECG), um electromiograma\footnote{Representação do potencial eléctrico gerado pelas células dos músculos} (EMG) ou um electroencefalograma\footnote{Representação da actividade do cérebro, obtida por pequenos sinais eléctricos chamados impulsos} (EEG). O sistema abordado tem um nó coordenador para onde todos os outros enviam informação e é usada a norma IEEE 802.15.4, que com suficiente largura de banda permite a transmissão da informação necessária.
+Em \cite{8} é abordada a \acf{BSN} como solução para a detecção precoce de problemas cardíacos. Através de um conjunto de sensores equipados com medidor de temperatura, medidor de pulso, acelerómetro e até sensores capazes de obter um electrocardiograma\footnote{Representação gráfica da actividade eléctrica do coração} (ECG), um electromiograma\footnote{Representação do potencial eléctrico gerado pelas células dos músculos} (EMG) ou um electroencefalograma\footnote{Representação da actividade do cérebro, obtida por pequenos sinais eléctricos chamados impulsos} (EEG). O sistema abordado tem um nó coordenador para onde todos os outros enviam informação e é usada a norma \acs{IEEE} 802.15.4, que com suficiente largura de banda permite a transmissão da informação necessária.
\begin{figure}[!htb]
\centering
@@ -74,7 +74,7 @@ \section{Monitoriza
A aplicação corre em TinyOS, open-source e com uma gestão de energia eficiente.
É referida a estrutura modular do sistema operativo que permite escolher componentes conforme a sua aplicação, o que facilita bastante a utilização de diferentes tipos de sensores.
-De referir o grupo de estudo IEEE 802.15 TG6\footnote{http://www.ieee802.org/15/pub/TG6.html} que pretende estabelecer a norma para as \acfp{BAN}, que define um protocolo de comunicação para dispositivos de baixa potência que operem dentro, em ou à volta do corpo humano.
+De referir o grupo de estudo \acs{IEEE} 802.15 TG6\footnote{http://www.ieee802.org/15/pub/TG6.html} que pretende estabelecer a norma para as \acfp{BAN}, que define um protocolo de comunicação para dispositivos de baixa potência que operem dentro, em ou à volta do corpo humano.
Em \cite{9} é feita uma discussão sobre o tipo de antena e protocolo \acf{MAC} para \acfp{WBAN}, bem como sobre diversas aplicações para este tipo de redes. Na Figura \ref{fig:5:wban} podemos observar que o tráfego é categorizado em 3 categorias: \textit{On-demand} iniciado pelo médico ou nó coordenador para obter uma determinada informação de um ou mais sensores, \textit{Emergency} iniciado pelos nós quando ultrapassam um determinado \textit{threshold} e \textit{Normal} que não apresenta qualquer elemento temporal crítico.
@@ -85,7 +85,7 @@ \section{Monitoriza
\label{fig:5:wban}
\end{figure}
-É referido o impacto do corpo na propagação do sinal através da constante dieléctrica alta que este possui bem como através da condutividade parcial do tecido muscular que pode absorver parte do sinal, factores que se tornam ainda mais significativos quando as antenas são de muito pequena dimensão. Outro aspecto relevante referido neste trabalho é o facto de não existir no IEEE 802.15.4 um mecanismo fiável para o envio das mensagens \textit{On-demand} e \textit{Emergency}. Como possível solução para este problema é apontada a utilização das IEEE 802.15.4 \acf{GTS} para lidar com eventos críticos.
+É referido o impacto do corpo na propagação do sinal através da constante dieléctrica alta que este possui bem como através da condutividade parcial do tecido muscular que pode absorver parte do sinal, factores que se tornam ainda mais significativos quando as antenas são de muito pequena dimensão. Outro aspecto relevante referido neste trabalho é o facto de não existir no \acs{IEEE} 802.15.4 um mecanismo fiável para o envio das mensagens \textit{On-demand} e \textit{Emergency}. Como possível solução para este problema é apontada a utilização das \acs{IEEE} 802.15.4 \acf{GTS} para lidar com eventos críticos.
Por fim, o trabalho \cite{9} indica através da Tabela \ref{tab:1:sensor_apps} um conjunto de possíveis aplicações para sensores. Doenças cardiovasculares, detecção de doenças oncológicas, sistemas de tele-medicina são algumas das aplicações mencionadas.
View
266 2_texto_principal/5_arquitecture.tex
@@ -9,35 +9,267 @@
\section{Sistema de Monitorização EMoS}
\label{chap:5:sec:1}
-Propõe-se nesta tese o \acf{EMoS}, uma solução simulada para o problema da monitorização de pessoas em ambiente doméstico. O \acs{EMoS} é uma rede \acs{WSN} constituída por diversos nós wireless colocados de forma homogénea numa casa.Embora o sistema possa efectuar a monitorização de todo o tipo de pessoas, neste trabalho será focada a monitorização de idosos ou pessoas com necessidades especiais.
+Propõe-se nesta tese o \acf{EMoS}, uma solução simulada para o problema da monitorização de pessoas em ambiente doméstico. O \acs{EMoS} é uma rede \acs{WSN} constituída por diversos nós wireless colocados de forma homogénea numa casa. Embora o sistema possa efectuar a monitorização de todo o tipo de pessoas, neste trabalho é focada a monitorização de idosos ou pessoas com necessidades especiais.
-O sistema é caracterizado pelos seguintes tipos de dispositivo:
+São sugeridas opções de hardware comercialmente disponível para cada componente do sistema pretendendo-se desta forma ir para além da simples simulação e obter parâmetros reais para a configuração da mesma. Alguns aspectos de hardware mencionados não serão simulados por limitação de tempo na execução deste trabalho e também por não corresponderem ao âmbito estabelecido no Capítulo \ref{chap:1:sec:2}.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=0.95\textwidth]{img/05_emos_overview.png}
+ \caption{Esquema modular do \textit{Elder Monitorization System} (EMoS).}
+ \label{fig:1:emosOverview}
+\end{figure}
+
+O sistema \acs{EMoS} (Figura \ref{fig:1:emosOverview}) é caracterizado pelos seguintes tipos de dispositivo:
+
+\begin{itemize}
+\item Nó Móvel (\acf{MN}): Monitorização de pessoas e calibração do sistema;
+\item Nó Fixo (\acf{SN}): Envio de \textit{beacons} para localização, comunicação e monitorização doméstica;
+\item Nó Base (\acf{BN}): Gestão central do sistema recebendo os dados de monitorização ou pedidos do utilizador e enviando mensagens para a rede \acs{WSN} ou para o exterior através de uma \acs{LAN}.
+\end{itemize}
+
+Os nós estáticos estão ligados à rede eléctrica e enviam periodicamente mensagens de assinatura em modo \textit{broadcast}. No caso dos nós \textit{SN8}, \textit{SN9}, \textit{SN12} e \textit{SN13}, pode existir também envio de mensagens para outros nós estáticos ou para o nó base. Isto pode acontecer quando por exemplo, é detectado gás no caso do \textit{SN12}, quando é ligado/desligado o fogão no caso do \textit{SN13} ou quando alguém se deita/levanta numa das camas onde estão os sensores \textit{SN8} e \textit{SN9}.
+
+O nó de base recebe informação dos nós estáticos ou do exterior através da \acs{LAN} e toma decisões com base nessa informação. Pode, por exemplo, avisar num monitor que existe alguma anomalia na casa, enviar uma mensagem para o nó móvel ou para um nó fixo, ou comunicar com o exterior caso seja necessário.
+
+O nó móvel pode funcionar em dois modos: calibração e normal. No modo de calibração limita-se a receber assinaturas dos nós fixos e a registar essa informação, gerando no um ficheiro XML com o mapa rádio do casa. No modo normal recebe de igual forma as assinaturas, mas periodicamente envia de volta para o nó estático mais próximo, um conjunto de médias das potências recebidas. O nó estático por sua vez envia esta informação para o nó base que irá calcular a localização do nó móvel.
+
+Todos os nós formam uma estrutura em \textit{flat-routing} usando o \acs{AODV} para comunicar e apresentam uma estrutura interna idêntica (Figura \ref{fig:2:emonsNodeInternal}). O sistema é perfeitamente escalável, sendo possível adicionar-se vários outros nós móveis. No caso de existir um número muito elevado de nós móveis é possível criar novos nós base associados a \textit{clusters} de nós fixos, que comuniquem através da LAN para eliminar sobreposições.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=0.80\textwidth]{img/05_emos_node_internal.png}
+ \caption{Estrutura interna de um nó no sistema EMoS.}
+ \label{fig:2:emonsNodeInternal}
+\end{figure}
+
+Neste trabalho foi criada uma camada \textit{Network} comum para todos os nós e uma camada \textit{Application} por cada tipo de nó que implementa cada u dos tipos descritos. Nas próximas secções é feita uma exposição detalhada de todo o sistema.
+
+\subsection{Nó Móvel (MN)}
+\label{chap:5:sec:1.1}
+
+O nó móvel é um sensor equipado com rádios \acs{IEEE} 802.15.4 e Bluetooth, um acelerómetro, um botão de pânico e capacidade de armazenamento em cartão \acs{SD}. O facto de ter dois tipos de rádio permite-lhe comunicar com ambas as redes \acs{BSN} para monitorização local biomédica e \acs{WSN}. Está instalado num objecto de uso diário, como uma bengala, um andarilho ou uma cadeira de rodas e possui baterias recarregáveis. O carregamento é feito no sítio habitual de apoio da bengala ou então por ligação com as baterias de uma cadeira de rodas eléctrica.
+
+A rede \acs{BSN} é composta por um electrocardiógrafo e um medidor de pressão arterial ambos equipados com Bluetooth, que efectuam monitorização contínua. Quando detectam uma situação anómala comunicam a mesma ao nó móvel. Na simulação este comportamento é recreado com um temporizador aleatório no nó móvel que simula a comunicação vinda da \acs{BSN} ao nível da aplicação.
+
+Como solução de hardware sugere-se a utilização do módulo \textit{Waspmote} (Figura \ref{fig:3:waspMote}, com rádio \textit{XBee-802.15.4} (Figura \ref{fig:4:waspXBee}), da \textit{Libelium}\footnote{http://www.libelium.com/products/waspmote} que permite a utilização de dois tipos de rádio, tem acelerómetro integrado, micro\acs{SD} e pins para obtenção do \acs{RSSI}.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=0.50\textwidth]{img/05_wasp_mote.png}
+ \caption{Módulo \textit{Waspmote} da \textit{Libelium}.}
+ \label{fig:3:waspMote}
+\end{figure}
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=0.40\textwidth]{img/05_wasp_xbee.png}
+ \caption{Rádio \textit{XBee} IEEE 802.15.4 usado no módulo \textit{Waspmote}.}
+ \label{fig:4:waspXBee}
+\end{figure}
+
+O rádio \textit{XBee} simulado terá os seguintes parâmetros obtidos do manual \footnote{http://ftp1.digi.com/support/documentation/90000982\_H.pdf}):
+
+\begin{table}[!htb]
+ \centering
+\begin{tabular}{ |l|r|}
+ \hline
+ Parâmetro & Valor \\
+ \hline
+ Modulation & O-QPSK \\
+ Receiver Sensitivity & -92 dbM \\
+ Transmit Power & 1mW \\
+ Sleep Current & <10 uA \\
+ Current Consumption RX & 50 mA \\
+ Current Consumption TX (P=0dBm) & 45 mA \\
+ \hline
+\end{tabular}
+ \caption{Parâmetros do rádio \textit{XBee} da \textit{Digi}.}
+ \label{tab:1:xbeeNICParameters}
+\end{table}
+
+\subsection{Nó Fixo (SN)}
+\label{chap:5:sec:1.2}
+
+O nó fixo está equipado com rádio \acs{IEEE} 802.15.4. Ficará ligado à rede eléctrica dada a necessidade de estar periodicamente a enviar assinaturas em \textit{broadcast}. O hardware escolhido para a implementação deste nó será o \textit{MicaZ} com rádio \textit{Texas Instruments CC2420} da \textit{Crossbow}\footnote{http://www.xbow.com/} (Figura \ref{fig:5:micaz}).
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=0.35\textwidth]{img/05_micaz.png}
+ \caption{Módulo \textit{Micaz} da \textit{Crossbow}.}
+ \label{fig:5:micaz}
+\end{figure}
+
+A escolha deste nó é motivada pelo baixo custo do mesmo e o facto de ser o nó que estará presente em maior número na rede.
+
+O rádio \textit{Texas Instruments CC2420} tem os seguintes parâmetros obtidos do manual\footnote{http://www.ti.com/lit/gpn/cc2420};
+\begin{table}[!htb]
+ \centering
+\begin{tabular}{ |l|r|}
+ \hline
+ Parâmetro & Valor \\
+ \hline
+ Modulation & O-QPSK \\
+ Receiver Sensitivity & -95 dBm \\
+ Transmit Power & 1.1mW \\
+ Sleep Current & 0.02 uA \\
+ Current Consumption RX & 18.8 mA \\
+ Current Consumption TX (P=0dBm) & 17.4 mA \\
+ \hline
+\end{tabular}
+ \caption{Parâmetros do rádio \textit{Texas Instruments CC2420}.}
+ \label{tab:2:CC2420NICParameters}
+\end{table}
+
+\subsection{Nó Base (BN)}
+\label{chap:5:sec:1.3}
+
+O nó base tem como função efectuar toda a gestão centralizada da informação gerada por cada um dos sensores. Dada a grande necessidade de rapidez de processamento, espaço de armazenamento e comunicação com o exterior, optou-se por usar um \acs{PC} ligado a uma \acs{LAN} que está por sua vez ligada à Internet. Assim o hardware para a implementação física deste nó e que fará a ponte entre o \acs{PC} e a rede \acs{WSN}, será o \textit{Waspmote Gateway}, com rádio \textit{XBee-802.15.4} (Figura \ref{fig:4:waspXBee}), da \textit{Libelium}.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=0.40\textwidth]{img/05_waspmote_gateway.png}
+ \caption{Módulo \textit{Waspmote Gateway} da \textit{Libelium}.}
+ \label{fig:6:waspmoteGateway}
+\end{figure}
+
+Este nó usa o mesmo rádio que o \textit{Waspmote}, com parâmetros para simulação já registados na Tabela \ref{tab:1:xbeeNICParameters}.
+
+\section{Camada NIC}
+\label{chap:5:sec:2}
+Esta camada é constituída pelo \acs{MAC} e \acs{PHY}.
+
+Tal como descrito na Secção \ref{chap:4:sec:2} a camada \acs{PHY} do \acs{MiXiM} tem um conjunto de modelos analógicos e um \textit{decider} que calculam as diversas atenuações e \textit{bit-errors} do sinal. Para o simulação deste sistema optou-se por usar um conjunto de três modelos analógicos que vão introduzir atenuação no sinal recebido.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=1\textwidth]{img/05_analogue_models.png}
+ \caption{Sistema linear correspondente à aplicação dos modelos analógicos à potência do sinal recebido pelo nó.}
+ \label{fig:7:analogueModels}
+\end{figure}
+
+Optou-se por usar o modelo \textit{Breakpoint Path Loss}, um modelo empírico que permite recriar a atenuação de um sinal a longas distâncias, onde a partir da \textit{BreakPoint distance} o sinal sofre uma atenuação com declive superior e o \textit{Log Normal Shadowing} que permite simular as perdas provocadas pelas diversas reflexões existentes dentro de um edifício. Para simular a existência de obstáculos é utilizado o \textit{Simple Obstacle Shadowing} que tal como descrito na Secção \ref{chap:4:sec:3} permite recriar a atenuação causada pelas paredes da habitação. Dada a falta de dados reais que permitam inferir os parâmetros do modelo, utilizaremos parâmetros de configurações usadas nos exemplos do MiXiM para simulação de redes \acs{WSN}.
+
+%Assim para o modelo \textit{Breakpoint Path Loss} dado por:
+%
+%\begin{equation}
+% P_L = L_0 + 10\alpha{}\log{d}
+%\end{equation}
+%
+%Temos \begin{math}\alpha{}=2\end{math},\begin{math}L_0=40.2\end{math}dB para \begin{math}d<8\end{math}m e \begin{math}\alpha{}=3.3\end{math}, \begin{math}L_0=58.8\end{math}dB para \begin{math}d>=8.0\end{math}.
+%
+%Por sua vez para o modelo \textit{Log Normal Shadowing} dado por:
+%
+%\begin{equation}
+% G = -normal(\bar{x},\sigma{})
+%\end{equation}
+
+Paralelamente à atenuação do sinal há também o cálculo dos \textit{bit-errors} da mensagem levada a cabo pelo bloco \textit{decider}. Este foi configurado com uma probabilidade de erro de \begin{math}BER=1\times{10^{-8}}\end{math} e modulação O-QPSK.
+
+O ficheiro de configuração da camada \acs{NIC} está disponível no Anexo \ref{annex:a}.
+
+
+\section{Camada Network : \textit{AODVRoute}}
+\label{chap:5:sec:3}
+
+A tecnologia ZigBee é hoje bastante usada nas redes \acs{WSN} com vários produtos para as mais diversas áreas. O ZigBee usa como primeiro protocolo na camada \textit{Network} o \acf{AODV} e seguidamente quando este falha um protocolo hierárquico. Assim por forma a garantir uma compatibilidade do sistema desenvolvido com o ZigBee optou-se por implementar este protocolo no \acs{MiXiM}.
+
+O \acs{AODV} é um protocolo \textit{on-demand} que permite descobrir um caminho apenas quando este é necessário, recuperar caminhos perdidos e reutilizar caminhos já encontrados. Achou-se por isso conveniente implementá-lo no \acs{MiXiM} para ser usado no \acs{EMoS}. Este usa caminhos bidireccionais, o que significa que quando é feita a descoberta de um novo caminho são sempre gerados dois, acelerando o processo de procura de novos caminhos. A utilização de contadores sequenciais impede e formação de loops em todo o processo e é feita manutenção sobre os caminhos para eliminar os que deixaram de ser usados durante um determinado espaço de tempo.
+
+Neste trabalho foi implementada uma versão do \acs{AODV} que apenas contém as funcionalidades necessárias para descoberta de um novo caminho ou para a recuperação de um caminho perdido. O \textit{multicast} bem como a reparação local de caminhos perdidos (\textit{local-repair}\footnote{reparação que ocorre localmente quando um nó intermédio falha no encaminhamento da mensagem.} não foram implementadas. Ao módulo implementado foi dado o nome de \textit{AODVRoute}.
+
+\subsection{Tipos de Mensagens}
+\label{chap:5:sec:3.1}
+O \acs{AODV} funciona utilizando pelo menos três tipos de mensagens para descobrir o caminho de um nó A para um nó B.
+
+\begin{itemize}
+\item \acf{RREQ};
+\item \acf{RREP};
+\item \acf{RERR}.
+\end{itemize}
+
+Pode ainda existir um quarto tipo de mensagem, opcional, o \acf{RREP-ACK}, utilizado quando existe o perigo de existirem ligações unidireccionais que impeçam a chegada de um \acs{RREP}, mas que não será referido neste trabalho.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=1\textwidth]{img/05_aodv_msg_types.png}
+ \caption{Tipos de mensagens do AODVRoute.}
+ \label{fig:11:aodvMsgTypes}
+\end{figure}
+
+Na Figura \ref{fig:11:aodvMsgTypes} estão as mensagens criadas no \acs{MiXiM}. A criação de mensagens no \acs{OMNeT++} é relativamente simples uma vez que todo o \textit{boilerplate code} é gerado automaticamente. Assim é necessário apenas definir ficheiros do tipo \textit{msg} com os parâmetros necessários. Cada uma das mensagens definidas para este módulo estende a mensagem \textit{NetwPkt}, uma mensagem genérica para a camada \textit{Netw} com endereços de emissor e receptor e \acf{TTL}. Para além dos campos herdados existem também os seguintes para cada tipo de mensagem:
\begin{itemize}
-\item Nó Móvel (\acf{MN})
-\item Nó Estático (\acf{SN}
-\item Estação Base (\acf{BS})
+\item \textit{AODVRouteRequest} : endereços e números de sequência para o nós emissor e receptor, o \textit{RREQ\_ID} que é obtido de um contador existente para o efeito no nó emissor e o contador de saltos que permite perceber em que ponto do caminho está o \acs{RREQ};
+\item \textit{AODVRouteResponse} : endereços de emissor e receptor, número de sequência do nó de receptor e número de saltos até ao receptor;
+\item \textit{AODVRouteError} : endereço do nó de destino que não foi encontrado.
\end{itemize}
-\title{\textbf{Nó Móvel}}
+\subsection{Estruturas de dados}
+\label{chap:5:sec:3.2}
+
+Foram criadas três estruturas de dados neste novo módulo:
+
+\begin{itemize}
+\item \textit{pktMap} : utilizada para guardar os pacotes que vieram da camada \acs{APP} por nó de destino, num \acs{FIFO} quando para estes ainda não existe um caminho encontrado;
+\item \textit{RREQVector} : utilizada para guardar os pacotes \acs{RREQ} recebidos;
+\item \textit{routeMap} :utilizada para guardar as rotas em cada nó e a lista de precursores\footnote{Precursor de um caminho, é um nó que antecede o nó actual no caminho e só existe depois de ter enviado pelo menos uma mensagem pelo nó actual.} dessa rota.
+\end{itemize}
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=1\textwidth]{img/05_aodv_pkt_map.png}
+ \caption{PktMap - estrutura para a gestão dos pacotes de aplicação em espera.}
+ \label{fig:8:aodvPktMap}
+\end{figure}
+
+Na Figura \ref{fig:8:aodvPktMap} observamos a estrutura PktMap. Este mapa de pares do tipo de endereços e filas de pacotes, guarda para cada nó de destino os pacotes em espera de um caminho para o seu destino final. Cada elemento da fila tem como parâmetros o endereço do nó de destino, o tempo de vida do elemento (\begin{math}t_0+t\end{math}) e o pacote que foi enviado da camada \acs{APP}. Esta estrutura é sujeita a uma manutenção periódica que elimina os todos os elementos para os quais \begin{math}t_{sim}>lifetime\end{math}. O tempo de vida é suficientemente curto para que não exista uma disparidade grande entre o momento que foi encontrado um caminho e a nova posição do nó móvel.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=1\textwidth]{img/05_aodv_rreq_vector.png}
+ \caption{RREQVector - estrutura que guarda os RREQs recebidos num nó.}
+ \label{fig:9:aodvRREQVec}
+\end{figure}
+
+Na Figura \ref{fig:9:aodvRREQVec} observamos a \textit{RREQVec}, estrutura que guarda a chave pares \textit{RREQ\_ID} e \textit{srcAddr}, por forma a distinguir univocamente todos os \acp{RREQ} recebidos de um determinado nó evitando assim o envio de um \acs{RREQ} que já foi anteriormente enviado.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=1\textwidth]{img/05_aodv_route_map.png}
+ \caption{RouteMap - estrutura que guarda os caminhos encontrados para nós destino.}
+ \label{fig:10:aodvPktMap}
+\end{figure}
+
+Finalmente na Figura \ref{fig:10:aodvPktMap} temos a estrutura \textit{RouteMap} que guarda a informação dos caminhos encontrados em cada nó. Estão presentes em cada \textit{routeMapElement}, o nó final de destino do caminho, o número de sequência conhecido do destino, o próximo nó do caminho, o número de nós entre o nó actual e o nó de destino, o tempo de vida do caminho usado para garantir que os caminhos que deixaram de ser usados não ficam a ocupar espaço no limitado armazenamento disponível e uma lista de nós precursores que servirá para para enviar um \acs{RERR} de volta para todos os nós que anteriormente usaram o caminho que deixou de existir.
+
+\subsection{Modo de Funcionamento}
+\label{chap:5:sec:3.3}
+
+Neste trabalho a camada de aplicação poderá gerar vários tipos de mensagens. Essas mensagens poderão ser em \textit{broadcast} no caso das mensagens de assinatura enviadas pelos nós fixos ou \textit{unicast} quando existe um nó que pretende comunicar com outro. Todos os nós do sistema \acs{EMoS} podem comunicar uns com os outros, no entanto, nem sempre de forma directa. Sendo a camada \textit{Network} comum a todos os nós o comportamento é idêntico para todos.
+
+Suponhamos que a camada de aplicação de um nó fixo pretende enviar uma mensagem para o base, informando, por exemplo que o existe uma fuga de gás. A partir desse momento à mensagem de aplicação é anexada informação de controlo (\textit{NetwControlInfo}), contendo o endereço \textit{Network} do nó de destino, sendo enviada para a camada abaixo.
+
+
-O nó móvel é um sensor wireless
+\section{Camada Application}
+\label{chap:5:sec:4}
+\subsection{HORUS Modificado}
+\label{chap:5:sec:4.1}
-\section{Ficheiros XML de Configuração}
-\label{sec:im:sec2}
+\subsection{Módulo de Nó Móvel}
+\label{chap:5:sec:4.2}
-\section{Network Layer}
-\label{sec:im:sec3}
+\subsection{Módulo de Nó Fixo}
+\label{chap:5:sec:4.3}
-\subsection{\textit{Ad hoc On-Demand Vector Routing}}
-\label{chap:4:sec:4.1}
+\subsection{Módulo de Nó Base}
+\label{chap:5:sec:4.4}
-\section{Application Layer}
-\label{sec:im:sec4}
+\section{Mobilidade}
+\label{chap:5:sec:5}
-\subsection{HORUS}
-\label{chap:5:sec:5.1}
% Ensure that the next chapter starts in a odd page
\cleardoublepage
View
4 2_texto_principal/6_results.tex
@@ -28,6 +28,10 @@ \section{Escalabilidade}
Analise do ponto em que e necessario adicionar mais uma baseStation
Analise do sistema com mais que uma base station
+\section{Tolerância a Falhas de Nós}
+\label{}
+Verificar os efeitos na localização da remoção de nós da rede.
+
% Ensure that the next chapter starts in a odd page
\cleardoublepage
View
7 2_texto_principal/7_conclusions.tex
@@ -2,12 +2,9 @@
% Conclusions
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\fancychapter{Conclusões}
-\label{chap:conclusoes}
-Pequena intrudução
+\fancychapter{Conclusões e Trabalho Futuro}
+\label{chap:7}
-\section{Trabalho Futuro}
-\label{sec:conclusoes:tf}
Aquilo que se deveria ter feito mas não se fez por alguma razão. Eventuais evoluções ou melhorias ao trabalho feito.
Possibilidade do sistema auto-construir o radioMap com base em nos estaticos que conhecem a sua posicao.
View
53 3_referencias-anexos/2_anexos.tex
@@ -1,8 +1,47 @@
-\appendix
-
-% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% First appendix
-% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\fancychapter{Apêndice 1}
-
+\appendix
+
+% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% First appendix
+% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\fancychapter{Apêndice 1}
+\label{annex:a}
+
+\begin{annex-code}{Ficheiro XML de configuração da camada \acs{NIC}.}{list:a1:xmlNIC}
+<?xml version="1.0" encoding="UTF-8"?>
+<root>
+ <!-- ANALOGUE MODELS -->
+ <AnalogueModels>
+ <AnalogueModel type="BreakpointPathlossModel">
+ <!-- IEEE 802.15.4 path loss channel model -->
+ <parameter name="alpha1" type="double" value="2"/>
+ <parameter name="L01" type="double" value="40.2"/>
+ <parameter name="breakpointDistance" type="double" value="8.0"/>
+ <parameter name="alpha2" type="double" value="3.3"/>
+ <parameter name="L02" type="double" value="58.8"/>
+ <parameter name="carrierFrequency" type="double" value="2.4E+9"/>
+ </AnalogueModel>
+ <!-- we add a log-normal shadowing effect on top of the IEEE 802.15.4 path loss -->
+ <AnalogueModel type="LogNormalShadowing">
+ <parameter name="mean" type="double" value="0.0"/>
+ <parameter name="stdDev" type="double" value="6"/>
+ <parameter name="interval" type="double" value="1"/>
+ </AnalogueModel>
+ <!-- we add obstacle shadowing on top of the log-normal shadowing effect -->
+ <AnalogueModel type="SimpleObstacleShadowing">
+ <parameter name="carrierFrequency" type="double" value="2.4E+9"/>
+ </AnalogueModel>
+ </AnalogueModels>
+ <Decider type="Decider802154Narrow">
+ <!--Length of Start Frame Delimiter (used to compute probability of successful synchronization)-->
+ <parameter name="sfdLength" type="long" value="8"/>
+
+ <!--minimum possible bit error rate (BER floor)-->
+ <parameter name="berLowerBound" type="double" value="1e-8"/>
+
+ <!--modulation type-->
+ <parameter name="modulation" type="string" value="oqpsk16"/>
+ </Decider>
+</root>
+\end{annex-code}
+
\cleardoublepage
View
BIN dissertacao.pdf
Binary file not shown.
View
1 img/.~lock.05_emos_node_internal.png#
@@ -0,0 +1 @@
+mnobrega ,mnobrega,pclinux,28.10.2012 23:17,file:///home/mnobrega/.config/libreoffice/3;
View
BIN img/05_analogue_models.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_aodv_msg_types.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_aodv_pkt_map.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_aodv_route_map.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_aodv_rreq_vector.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_emos_node_internal.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_emos_overview.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_micaz.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_wasp_mote.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_wasp_xbee.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN img/05_waspmote_gateway.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
1 odf/.~lock.aodv_data_msg_types.odg#
@@ -0,0 +1 @@
+mnobrega ,mnobrega,pclinux,29.10.2012 08:30,file:///home/mnobrega/.config/libreoffice/3;
View
1 odf/.~lock.emos.odg#
@@ -0,0 +1 @@
+mnobrega ,mnobrega,pclinux,28.10.2012 19:51,file:///home/mnobrega/.config/libreoffice/3;
View
1 odf/.~lock.mixim_logic_layers.odg#
@@ -1 +0,0 @@
-mnobrega ,mnobrega,pclinux,28.10.2012 01:39,file:///home/mnobrega/.config/libreoffice/3;
View
1 odf/.~lock.mixim_node_module.odg#
@@ -1 +0,0 @@
-mnobrega ,mnobrega,pclinux,28.10.2012 01:46,file:///home/mnobrega/.config/libreoffice/3;
View
1 odf/.~lock.mixim_with_obstacles.odg#
@@ -1 +0,0 @@
-mnobrega ,mnobrega,pclinux,28.10.2012 03:51,file:///home/mnobrega/.config/libreoffice/3;
View
1 odf/.~lock.omnet_modules.odg#
@@ -1 +0,0 @@
-mnobrega ,mnobrega,pclinux,27.10.2012 23:42,file:///home/mnobrega/.config/libreoffice/3;
View
1 odf/.~lock.phy_analogue_models.odg#
@@ -0,0 +1 @@
+mnobrega ,mnobrega,pclinux,29.10.2012 05:02,file:///home/mnobrega/.config/libreoffice/3;
View
BIN odf/aodv_data_msg_types.odg
Binary file not shown.
View
BIN odf/aodv_data_structures.odg
Binary file not shown.
View
BIN odf/emos.odg
Binary file not shown.
View
BIN odf/phy_analogue_models.odg
Binary file not shown.

0 comments on commit 784a087

Please sign in to comment.
Something went wrong with that request. Please try again.