Departamento de Engenharia Electrotécnica

Sistemas de Telecomunicações

2009/2010

2º - Trabalho Prático: Sinalização e serviços em Redes GSM

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

http://tele1.dee.fct.unl.pt Rodolfo Oliveira Paulo Montezuma

2

1. Objectivo Introdução às funções de sinalização em redes de Telecomunicações e às

comutações de circuitos e de pacotes. O trabalho consiste na construção de um sistema de Telecomunicações celular. Cada computador do laboratório é uma célula onde podem estar activos até três receptores e três emissores. Os emissores e receptores podem trabalhar num modo de comutação de circuitos, ou num modo de comutação de pacotes não orientada à ligação (datagramas). Tal como acontece na realidade, os receptores têm de ser “ligados” à rede e ficam à espera que alguém os contacte. Existem depois emissores que consultam a base de dados da sua célula e estabelecem contacto com o receptor que pretendem e que esteja activo na sua, ou noutra célula. O contacto consiste num “talk” com o receptor. A comunicação entre um emissor e qualquer receptor é feita através da estação base da célula do emissor.

O sistema é composto pelos seguintes componentes:

• Estação Base (parte do código é fornecido pelo corpo docente)

• Emissor

• Receptores (fornecidos pelo corpo docente)

Sendo este um trabalho (de dois) de uma disciplina de Mestrado Integrado, não é um objectivo construir um sistema completo de Telecomunicações. Em muitos pontos deste enunciado vai aparecer a expressão “Para não complicar demasiado...” seguida da simplificação que se pretende que os alunos façam. Em todas elas é óbvio como se faria na realidade.

Antes de entrar nas especificações, a próxima secção descreve uma breve introdução à sinalização em redes de Telecomunicações e a alguns tipos de transmissão/comutação.

2. A Sinalização e a Transmissão nas Redes de Telecomunicações Designa-se por sinalização nas redes de telecomunicações toda a função que serve para

controlar o uso directo do funcionamento da rede (por exemplo, a indicação do número a chamar, o sinal sonoro de interrompido, etc.). Os equipamentos que existem na rede especificamente com estas funções designam-se por equipamentos de sinalização.

2.1. Sinalização em redes de comutação de circuitos Vai-se descrever primeiro o caso da comutação de circuitos. Para que dois interlocutores

possam transferir informação é necessário estabelecer uma ligação entre eles (que acaba por significar na prática o estabelecimento de um circuito entre eles). Este procedimento já é nosso conhecido na utilização da rede telefónica – antes de falarmos com alguém ao telefone é necessário discar o número dessa pessoa. Estamos a dar à rede a informação de endereço do terminal remoto com o qual queremos trocar informação para que a rede estabeleça o circuito. Basicamente, existem três grandes modos de trocar informação de sinalização:

Laço de corrente – o disco do nosso telefone gera impulsos de corrente por cada unidade do dígito discado e existe um detector na rede que determina o número através do reconhecimento desses impulsos (a figura 1a ilustra o caso do dígito 3).

Multifrequências – Num sistema DTMF (dual tone multifrequency) existem sete osciladores no nosso telefone, como está indicado na figura 1b, e detectores de

3

frequência na rede para determinar o dígito pretendido. Por cada dígito, são enviadas as duas frequências da matriz (por exemplo, no caso da figura, para o dígito 3 são enviadas simultaneamente as frequências D Hz e G Hz) e o equipamento receptor dentro da rede detecta-as e sabe que é um 3. Este tipo de sinalização é o que existe mais frequentemente em Portugal nos telefones analógicos.

Pacotes – Em redes mais modernas, como a RDIS (Rede Digital de Integração de Serviços), ou o ATM (Asynchronous Transfer Mode), usam-se pacotes para levarem a informação de endereço, tornando todo o processamento mais simples, rápido e barato – o próprio processador dos comutadores interpreta os pacotes não havendo necessidade de equipamento específico para detectar os números do endereço, e passar essa informação ao processador.

Figura 1 Exemplos de sinalização: (a) pulsos de disco e (b) DTMF O uso de pacotes permite ainda que os terminais (telefones ou outros) possam enviar de um

modo fácil outro tipo de informação de sinalização para além dos endereços (por exemplo, follow me, desvio automático a partir do quinto toque, etc.). Pode-se também colocar o endereço de origem e no momento em que o telefone toca aparece o número de origem (Isto já nos é habitual nos telefones celulares e mesmo nos fixos). É evidente que o telefone RDIS é bastante mais complicado do que um telefone normal, pois tem de possuir um processador para construir os pacotes (mas não existe a necessidade de se terem osciladores ou outro equipamento mais obsoleto na rede).

2.2. Sinalização em redes de comutação de pacotes Passando agora ao caso das redes de comutação de pacotes existem duas hipóteses: a rede

suporta a noção de ligação, ou não. Nas redes com chamadas de pacotes orientadas à ligação é necessária a existência de

pacotes que iniciem ligações, para depois haver pacotes que são simplesmente de dados com a indicação que pertencem a uma determinada ligação já estabelecida. Os pacotes para iniciar as ligações podem já ser considerados como pacotes de sinalização. Assim, o procedimento é muito idêntico à rede de comutação de circuitos, diferindo apenas na parte de troca de informação (dados), onde se usam pacotes em vez de tramas com amostras (TDM).

No caso da rede não suportar ligações, como é exemplo o IP da Internet, não há necessidade de sinalização explícita como a que se tem vindo a explicar. Aliás o termo sinalização como está explicado aqui é um termo muito utilizado nas redes de telecomunicações mais viradas para a voz, como a rede telefónica e a RDIS, e tem sido definido pelas organizações mais ligadas a esse mundo (ITU-T, por exemplo). A Internet, mais na área das redes de dados, evitava falar do termo sinalização. Hoje em dia, no caminho para se ter redes que suportem qualquer tipo de tráfego (redes integradas), baseadas ou não na Internet, começa a ser útil falar de sinalização de

E F G

B

A

2 D 3

C 4

1

5

8 9 7

6

0* #

(b) (a)

t

i

4

um modo geral. Assim, mesmo nas redes de pacotes não orientadas à ligação, é sempre preciso identificar os endereços de origem e destino (e mais alguns parâmetros que saem do âmbito deste trabalho), pelo que existe também sinalização, simplesmente de uma forma diferente.

2.3. Dois tipos de sinalização Outro aspecto importante na sinalização é que entidades é que estão a trocar sinalização. No

caso de ser um terminal de utilizador a trocar sinalização com um equipamento da rede, a interface entre esses dois componentes designa-se por user-network interface – UNI. Esta interface é a que estamos habituados a utilizar no nosso dia a dia – vai incluir pacotes de pedido de ligação, de pôr o telefone a tocar, de sinal de chamar, de estabelecimento de ligação, etc.

A outra interface é entre equipamentos da rede (comutador a comutador, por exemplo). Designa-se por network-network interface – NNI, e serve por exemplo, para dar seguimento pelo meio da rede a uma ordem que efectuámos (o pedido do utilizador para se ligar a um receptor deve ser reenviado a todos os equipamentos da rede que se encontram no caminho entre o emissor e o receptor). Podem também existir outras operações não directamente relacionadas com comandos do utilizador.

Em resumo, neste trabalho vai-se utilizar o modo de pacote para transportar a sinalização, e vão-se ter exemplos dos dois tipos de sinalização: UNI e NNI.

2.4. Dois tipos de transmissão e comutação

Para além de mostrar aos alunos o que é a sinalização, este trabalho tem também como

objectivo que os alunos percebam as diferenças de dois tipos de transmissão e modos de comutação. Actualmente a transmissão no nível físico é quase sempre síncrona. Isto é, tanto os emissores como os receptores têm um relógio sempre a correr e o código de linha (lembram-se de IT?) ajuda a acertar sempre os relógios. O emissor sabe sempre quando deve começar a enviar um bit (ou um símbolo) e o receptor quando o deve amostrar para decidir o que recebeu.

A grande questão agora é a de saber o que os bits significam... Normalmente a transmissão está muito relacionada com a comutação: 1. Comutação de circuitos – A transmissão consiste em enviar tramas (frames) TDM

(Time Division Multiplexing) umas atrás das outras. Portanto todos os bits transmitidos são relevantes. Uma determinada conversa tem a sua amostra algures na trama, por exemplo, canal/slot 4, e vai-se colocando o valor da amostra nos slots 4 de cada trama. No caso da rede telefónica, por exemplo, os comutadores recebem as tramas à velocidade a que elas vêm nas suas linhas de entrada (125 µseg para dar as 8.000 tramas por segundo) e têm de ter tramas prontas a sair nas suas linhas de saída à mesma velocidade. Pelo meio existe o módulo de comutação que pega num slot de uma trama de uma linha de entrada e coloca-o num slot de uma trama de uma linha de saída de acordo com a ligação que foi estabelecida. Por exemplo o slot 3 da trama de entrada da linha 1 vai para o slot 5 da trama de saída da linha 4. Chama-se a isto comutação por posição. O modo de transmissão é TDM e normalmente usa-se o PCM (Pulse Code Modulation) para as amostras;

2. Comutação de pacotes – A transmissão consiste em enviar pacotes. Quando não existem pacotes para enviar tem de se continuar a enviar bits para manter o sincronismo da linha física. Como estes bits não dizem respeito a nenhuns dados normalmente eles são flags umas atrás de outras. Portanto, neste modo nem todos os bits transmitidos são relevantes. Um grande problema que estudamos na parte teórica é saber onde começa e acaba uma trama. Assim, a linha, de vez em quando, vai ter tramas de nível Lógico (não confundir com a trama TDM). O router recebe a trama, retira-lhe os cabeçalhos do nível

5

Lógico e trata o pacote (nível Rede). Vê o endereço de destino, decide qual a linha de saída e coloca o pacote na fila de espera dessa linha para depois ser enviado pelo hardware. Chama-se a isto comutação por rótulo (o endereço de destino do pacote é o rótulo e não há a noção de posição dos dados como em TDM). As redes IP, X.25 e ATM são exemplos destas redes.

Um aspecto importante para os alunos reflectirem é a velocidade de transmissão de informação nas linhas.

No primeiro caso, comutação de circuitos, a informação circula na rede ao ritmo exacto da linha, qualquer que ele seja (por exemplo, no caso da voz se a linha tiver 640 Kbps vão circular 10 chamadas de 64 Kbps). Por muito rápido que o computador/telefone/etc. seja, a informação não “sai” mais depressa para a rede. Em cada trama TDM preenchem-se apenas os slots que devem ser preenchidos e espera-se pela trama seguinte para voltar a preencher os mesmo slots. O receptor também sabe a que ritmo (constante) a informação aparece. No presente trabalho o ritmo vai ser simulado ao se enviar uma trama TDM de x em x segundos (em vez dos 125 µseg).

No segundo caso o utilizador está ligado ao router com uma linha com um determinado ritmo. Em ambientes de escritório esse ritmo até pode ser de 622 Mbps. Cada pacote é enviado a esse ritmo!... Mas se não existirem pacotes para serem enviados a linha tem apenas os tais bits para manter o sincronismo, mas que não são parte das tramas (p.ex. as flags). Se os pacotes forem enviados uns atrás dos outros o ritmo de informação é de 622 Mbps. Se houver um certo tempo entre os pacotes (porque o computador não consegue ser tão rápido, por exemplo) o ritmo médio de pacotes é menor. Por exemplo, num certo intervalo de tempo o número de pacotes que foram enviados pode fazer com que a média seja de 1 Mbps. MAS CADA PACOTE VAI A 622 Mbps!...

Esta flexibilidade da comutação de pacotes tem uma consequência que não existe na comutação de pacotes. Podemos pensar que um computador muito rápido envie pacotes a uma cadência tal que entupa o computador de destino (entupir a rede é mais difícil). Como em teoria o computador emissor pode usar o ritmo todo da linha, tem de haver um mecanismo para o poder abrandar. O mecanismo de controlo na comutação de pacotes é um algoritmo de controlo de fluxo (a estudar na parte teórica da disciplina), e, claro, mais bits no cabeçalho do pacote relacionados com este algoritmo – mais “sinalização”... No caso da comutação de circuitos o ritmo é sempre fixo, conhecido e aceite pelos dois interlocutores, pelo que não há necessidade de controlo de fluxo.

3. Especificações A figura 2 mostra o sistema que se vai construir no laboratório. Cada círculo é uma célula

da rede com o nome do PC onde corre (pc-1, pc-2, …, pc-10). Em cada célula existe uma estação base e podem existir emissores e receptores. Se quisermos fazer uma analogia com a realidade na Europa, as estações base da rede GSM estão preparadas para suportar tráfego de voz e tráfego de dados, que aqui reduzimos ao SMS (isto é, tráfego de comutação de circuitos e tráfego de comutação de pacotes não orientado à ligação). Caso os alunos sintam que isso simplifica, podem executar um emissor para tráfego de voz e outro para SMS (um de cada tipo). Alternativamente, podem ter um emissor com o código necessário ao suporte dos dois tipos de serviços.

Como está mostrado na figura 2 vão existir mensagens de sinalização (setas grossas) e mensagens de dados (setas finas) entre os vários componentes. As mensagens de sinalização são, por sua vez divididas em mensagens UNI (setas pretas) e mensagens NNI (setas cinzentas).

6

A sinalização NNI compreende mensagens entre estações base para dar a conhecer umas às outras que receptores têm registados localmente.

A sinalização UNI compreende mensagens de subscrição de emissores e receptores às estações base da sua célula e pedidos de estabelecimento de ligação (e terminação).

Para além disso existem mensagens de dados para se transmitir informação. Cada receptor, depois de começar a funcionar regista-se na sua estação base e indica-lhe o

nome pelo qual quer ser conhecido e o seu endereço (IP+porto). Cada receptor pode estabelecer até uma associação no serviço de voz, não sendo necessária qualquer associação para o SMS. Isto é, se um emissor tentar estabelecer uma associação com um receptor que já esteja em contacto com outro recebe uma indicação negativa e não pode estabelecer a associação.

O emissor, quando arranca, regista-se na sua estação base fornecendo informação semelhante à dos receptores e pode estabelecer uma associação com qualquer receptor da rede para o serviço de voz (na sua célula, ou não). A identificação do receptor é lida pelo aluno a partir da tabela da rede que é mostrada pela estação base da sua célula. No caso de sucesso de associação com o receptor estabelece-se uma sessão de “talk” muito idêntica à do trabalho 0 desta disciplina.

O contacto com o receptor é feito através da estação base do emissor. Isto é, o emissor envia a informação para a estação base da sua célula que se encarrega de a enviar directamente para o receptor (da sua célula ou de outra célula). Daí que as estações base tenham de suportar quer comutação de circuitos (Voz em GSM) e comutação de pacotes não orientados à ligação (SMS em GSM). Note-se que os emissores e receptores só podem funcionar num dos modos em cada instante. Logo ou fazem chamadas ou enviam SMS.

As especificações exactas de todas estas trocas de pacotes estão descritas nos pontos abaixo.

Figura 2 Blocos constituintes da rede celular

3.1. Comunicação entre estações base – NNI Cada estação base escuta num porto datagrama conhecido – porto 25000. Cada estação

base envia regularmente um pacote, NNI_OLA, com a estrutura mostrada na figura 3 para todas as células da rede. Como se está a utilizar datagramas, se o destinatário não estiver activo não tem problema. Este envio de pacotes deve ser feito a cada 30 segundos. O pacote contém a identificação da célula (pc-1,…,pc-10), e a identificação de até três receptores (no caso de

pc-1

Estação Base

Emissor Receptor

Receptor

pc-2

Estação Base

Emissor Receptor

Receptor

pc-3

Estação Base

Emissor Receptor

Receptor

pc-4 pc-5

pc-6

7

haverem menos de três receptores activos os campos devem ir a zero). Cada identificação de receptor tem o seu “nome”, o seu endereço IP e porto, e o seu tipo.

Quando uma estação base recebe um desses pacotes coloca-o num vector (array) na posição respectiva (existem 10 células na nossa rede). O nome e o tipo de receptor devem ser mostrados no écran a seguir à identificação da célula (ver figura 5). Essa posição do vector vai ter um tempo de vida associado de 120 segundos. Podem acontecer duas coisas a essa posição do vector: o tempo passa e então a informação deve ser esquecida (e apagada do écran) ou; veio outro pacote com informação para essa posição e deve ser cancelado o relógio associado à informação anterior e relançado um relógio com 120 segundos para a nova informação dessa posição (a nova informação deve ser escrita no écran).

Figura 3 NNI – troca de pacotes OLA. A célula pc-1 tem dois receptores activos.

3.2. UNI - Associação de emissores e receptores às estações base Na rede GSM real os telefones têm um número de identificação (chamado de IMSI), e um

número de telefone associado (os nove dígitos que damos às outras pessoas). Neste trabalho vai existir a mesma coisa. Tanto os emissores como os receptores vão ter um número de identificação (o seu endereço IP e porto) e um nome associado em vez de um número (“banana”, “pera”, “super-homem”, etc.).

Quando um receptor arranca, cria um socket datagrama e regista-se na estação base, no porto conhecido (25000) indicando a informação mostrada na figura 4.

No caso dos emissores, a estação base guarda essa informação para a poder utilizar quando o emissor quiser estabelecer um contacto. No caso dos receptores a estação base guarda essa informação e difunde-a para as outras nove células regularmente como indicado no ponto anterior.

Observe-se que esta informação pode ser inexacta, pois as estações base não sabem se emissores e receptores deixaram de estar activos. Para não complicar muito o trabalho cada estação base vai ter dois botões para limpar todos os registos dos receptores e emissores que tiver (ver figura 5).

Também para não complicar o trabalho cada estação base só pode ter até três receptores e três emissores registados. Quando aparecer um quarto deve escrever uma informação de erro no écran e não aceitar o seu registo (o utilizador deve limpar os registos e começar outra vez os emissores e receptores).

NNI_OLA (‘pc-1’, ‘banana’, 172.16.54.1, 20001, ‘manga’, 172.16.54.1, 18756, 0,0,0,0) Estação Base

pc-1 Estação Base

pc-2

Estação Base pc-10

.

.

. NNI_OLA (‘pc-1’,

‘banana’, 172.16.54.1, 20001, ‘manga’, 172.16.54.1, 18756, 0,0,0,0)

8

Figura 4 Subscrições de emissores e receptores às estações base Neste trabalho vai-se admitir que tudo está a funcionar bem. Isto é, pode

acontecer que um emissor tente contactar um receptor que acabou de estar activo. Este facto poderia ser tratado com um relógio no emissor à espera de uma resposta a um pedido de contacto. Não se vai tratar este caso e só é exigido aos alunos que tratem os casos em que os vários componentes estão activos.

Figura 5 Exemplo da interface de uma estação base: Esta estação base é a do pc-4. Nesta célula não existem receptores activos e existem três emissores activos. A célula pc-6 também não tem receptores activos. As células pc-2, pc-5, pc-7 e pc-9 não estão activas de momento. As restantes células têm receptores activos.

3.3. Serviço de Voz GSM – de comutação de circuitos – Interface UNI Nesta secção descrevem-se os procedimentos de tratamento das mensagens de sinalização

entre os emissores/receptores e as estações base (UNI). Na rede de comutação de circuitos existem os seguintes pacotes de sinalização:

• um pacote de pedido de início de ligação no sentido utilizador-rede (UNI_REQ_CONN); • um pacote de indicação que alguém pretende efectuar uma ligação no sentido rede-

utilizador (UNI_CONN_IND);

UNI_SUBSC (EMISSOR, ‘BANANA’, 172.16.54.1, 20001)

Emissor A Receptor B Estação Base

UNI_SUBSC (RECEPTOR, ‘PERA’, 172.16.54.1, 20005)

9

• um pacote de aceitação da indicação no sentido utilizador-rede, que pode ser positivo ou neagtivo (UNI_CONN_ACC);

• um pacote de confirmação de estabelecimento de ligação no sentido rede-utilizador, que pode ser positivo ou negativo (UNI_CONN_ESTAB);

• um pacote de finalização de ligação no sentido utilizador-rede (UNI_REQ_TERM); • um pacote de finalização de ligação no sentido rede-utilizador (UNI_CONN_TERM). Os procedimentos de estabelecimento e terminação de ligações estão exemplificados na

figura 6. O estabelecimento é confirmado (4 primitivas). A terminação é confirmada para quem a requereu, e não o é para o outro. Qualquer dos terminais pode pedir a terminação da ligação, muito embora esteja apenas exemplificada na figura 6 a terminação pelo emissor. O receptor aceita sempre a chamada quando estiver livre. Rejeita a chamada se estiver em comunicação. Se a rede conseguir estabelecer chamada envia UNI_CONN_ESTAB para o emissor com a indicação positiva, caso contrário, envia o mesmo pacote com indicação negativa. O pacote UNI_CONN_TERM pode ser enviado em qualquer altura durante a ligação.

Figura 6 Procedimentos de estabelecimento e terminação de ligações Nos pacotes UNI_CONN_IND e UNI_CONN_ESTAB existe a indicação de qual o slot PCM que

se vai usar para transferir os dados na trama GSM (8 slots por trama). Cada trama GSM inteira é um datagrama. O datagrama tem, portanto, um tamanho de 8 octetos, sendo um octeto o tamanho de cada slot.

Nos pacotes UNI_REQ_CONN o utilizador pede à rede uma ligação com um slot PCM. A atribuição do número do slot ao emissor (isto é, se o slot pedido é o 6 ou o 27) é feita pela

estação base e deve ser aleatória, a partir de uma função estatística interna à estação base. O número do slot atribuído ao receptor é, também, aleatório e deve ser determinado independentemente do número usado para o emissor (Só por sorte é que existirão números iguais). A estação base trabalha como uma central digital de divisão temporal.

A ligação pode terminar em qualquer altura devido ao receptor ou o emissor se desligar da rede. A rede pode tomar a iniciativa de terminar ligações e assume-se que nunca perde tramas. Na realidade, é evidente que tal pode acontecer, pois são pacotes UDP.

UNI_REQ_CONN

UNI_CONN_IND

Emissor A

UNI_CONN_ACC

Receptor B

UNI_CONN_ESTAB

Estação Base

UNI_CONN_TERM(N)

Troca de dados

UNI_REQ_TERM

UNI_CONN_TERM(N)

10

3.4. Chamada de Voz – de comutação de circuitos – Interface de dados Uma vez em comunicação, existe um ritmo de envio de datagramas de x em x segundos. Se

os intervenientes não têm nada para enviar nessa altura, o slot respectivo deve ir a zero. Caso tenham alguma coisa preenchem esse slot com a informação.

Tem, assim, de se estabelecer uma ligação, escrever os dados em cada trama TDM (simulada por um pacote) nos slots que se negociaram e finalizar a ligação. Por exemplo, se a rede disser que estabeleceu a ligação no slot 4, o quarto octeto de cada pacote tem um octeto do ficheiro, sendo os outros octetos do pacote não definidos.

3.5. Serviço SMS – de comutação de pacotes não orientada à ligação – interface de dados

No serviço SMS, de comutação de pacotes não orientada à ligação, não existem pacotes

específicos de sinalização. Os pacotes de dados é que vão ter a indicação total da rota, nomeadamente nos seus cabeçalhos. Para se ter uma comparação simples, vai-se fazer com que o tamanho da parte de dados dos pacotes seja também de 100 octetos. A parte do cabeçalho é que vai ser maior pois vai ser necessário, pelo menos, enviar a identificação do destinatário em todos os pacotes.

A rede não vai ter consciência de qualquer associação entre emissores e receptores e deve apenas reenviar os pacotes para onde eles devem ir. Logo para este modo de operação é somente necessário o pacote:

• pacote de dados (SMS_GSM); Muito embora os datagramas não sejam fiáveis, vai-se assumir neste trabalho que nunca se

perdem, não necessitando os alunos de programar situações de recuperação deste género. Os pacotes de dados são enviados à medida que houverem dados da mensagem para serem

transferidos e podem usar os slots que se encontrarem livres na estação base. 4. Codificação dos datagramas trocados entre os módulos Para simplificar, a colocação e extracção dos dados nos pacotes vai ser realizada utilizando

as rotinas de colocação e extracção fornecidas aos alunos no módulo (Mensagem.pas). Este módulo define o tipo ST_PackType, um tipo “variant record” que permite representar em PASCAL qualquer um dos pacotes/mensagens utilizados no trabalho.

Os alunos trabalham sempre com mensagens e são trocados sempre pacotes entre os componentes. Assim, na emissão, os alunos devem usar as mensagens para trabalhar, chamar as rotinas de codificação que devolvem o pacote e enviar esse pacote pelo socket. Na recepção devem receber o pacote, chamar a rotina de descodificação e trabalhar normalmente com a mensagem.

4.1. Envio de mensagens O envio de mensagens é feito utilizando a estrutura ilustrada na figura 8. Admite-se que

existe um objecto do tipo TNMUDP (socket UDP) com o nome NMUDP1. O envio de uma mensagem passa por várias fases:

1) a criação da mensagem numa variável local (msg) do tipo ST_PackType. É usado um procedimento diferente por cada tipo de mensagem (ou quase...);

11

2) a configuração do endereço de destino do socket (NMUDP1); 3) o preenchimento do pacote a partir da mensagem utilizando o procedimento

codifica_pacote. O procedimento codifica_pacote transfere para a variável “pacote” o conteúdo da variável “msg”. É a variável “pacote” que será depois enviada;

4) o envio do pacote através do socket; tarefa que será realizada com os conhecimentos já adquiridos sobre sockets;

5) a libertação da memória da variável “msg” através da função delete_message; var   msg: ST_PackType;   pacote:TMemoryStream:  begin   // 1‐Criação da mensagem   new_message_???(msg, ?????);    // 2‐Configuração do endereço de destino   NMUDP1.RemoteHost:= { Endereço IP }   NMUDP1.RemotePort:= { Porto }    // 3‐serialização do pacote   codifica_pacote(msg, pacote);     // 4‐Envio do pacote   …     // 5‐Libertação de memória   delete_message(msg); end; 

Figura 7 Procedimento de envio de uma mensagem Os vários procedimentos que estão no módulo Mensagem.pas para a criação de

mensagens estão listados mais à frente. O primeiro argumento é sempre um argumento de saída do tipo ST_PackType, onde é retornada a mensagem já preenchida. Os restantes argumentos dependem da constituição de cada uma das mensagens.

4.2. Recepção de mensagens A recepção de mensagens é realizada na rotina de tratamento do evento

“OnDataReceived” do socket UDP utilizando a estrutura ilustrada na figura 8. Admite-se que existe um objecto do tipo TNMUDP (socket UDP) com o nome NMUDP1.

Após a recepção do pacote a partir do socket (feita pelos alunos) executa-se a descodificação da mensagem. A função de descodificação é denominada de descodifica_pacote. Esta função vai interpretando o feixe (stream) recebido e constrói uma mensagem do tipo ST_PackType (variant record) dando os valores correctos aos vários campos.

A variável ‘msg’ tem um campo fixo, comum a todos os tipos de mensagens: • campo ‘msg.tipo’ que divide o conjunto de mensagens possíveis em cinco grupos

(NNI_OLA, UNI_SUBSC, UNI_GSM, CC_GSM, SMS_GSM).

12

De seguida, identifica-se o tipo da mensagem através do teste condicional “case” e trata-se a mensagem. Por fim liberta-se a memória alocada para essa mensagem através da invocação do procedimento delete_message. Este é o esquema de recepção utilizando a biblioteca de tratamento de mensagens fornecidas no módulo Mensagem.pas. De referir a existência da função message_to_string para permitir a escrita de uma mensagem. Esta função retorna um string que contém os valores da mensagem e pode ser muito útil na fase de detecção de erros do programa.

procedure TForm2.NMUDP1DataReceived(Sender: TComponent;   NumberBytes: Integer; FromIP: String); var    msg:ST_PackType;    pacote:TMemoryStream; begin    if NumberBytes < 1 then      exit;     // recebe o pacote       …     // transfere o pacote de dados recebidos para a variável msg    if descodifica_pacote(pacote, msg) then      begin        // afixa a mensagem recebida        Memo1.Lines.Add('Recebeu ‐ ' + message_to_string(msg));         // executa a mensagem 

 case msg.tipo of    NNI_OLA:    UNI_SUBSC:        UNI_GSM:        CC_GSM:        SMS_GSM:  end;   

        // apaga a mensagem        delete_message(msg);      end    else    begin      ShowMessage('Pacote inválido');    end; end;  Figura 8 Procedimento de recepção de um pacote 5. Estruturas de dados para as mensagens e rotinas de codificação

5.1. Recepção de mensagens As estruturas de dados para as mensagens são as seguintes (apresentam-se também os

campos dos pacotes através de figuras):

13

const NUMBER_GSM_CHANNELS = 8;

type { Tipos de Pacotes } STPackType = (NNI_OLA, UNI_SUBSC, UNI_GSM, CC_GSM, SMS_GSM); { Tipos de Equipamento Terminal } ST_TermEquip = (Emissor, Receptor);

{ Tipos de Resultados de Contactos } ST_ConnResultType = (AcceptConn, RejectConn); { Tipos de Pacotes UNI_GSM } ST_UNI_GSMPackType = (UNI_REQ_CONN, UNI_CONN_IND, UNI_CONN_ACC,

UNI_CONN_ESTAB, UNI_REQ_TERM, UNI_CONN_TERM); ByteArray = PACKED ARRAY of Byte; { Registo de receptores } ST_RecId_Type = RECORD nome_receptor : ^String; IP_receptor : TInAddr; porto_receptor : Word; tipo_receptor : ST_FunctType; end;

{ Pacotes NNI_OLA } ST_NNI_OLA_PackType = RECORD cell_name : ^String; receivers : array [1..3] of ST_RecId_Type; end;

14

{ Pacotes Subscribe } ST_UNI_SUBSC_PackType = RECORD term_equip_type : ST_TermEquip; equip_name : ^String; equip_address : TInAddr; equip_port : Word; equip_type : ST_FunctType; end; { Pacotes UNI_GSM }

ST_UNI_REQ_CONN_PackType = RECORD source_port : Word; source_name : ^String; dest_name:^String; num_channels : Byte; end;

ST_UNI_CONN_IND_PackType = RECORD source_name : ^String; num_channel : Byte; end;

UNI_GSM uni_conn_acc1 1

Len (nome) nome2 len

resultado1

ST_UNI_CONN_ACC_PackType = RECORD source_name : ^String; result : ST_ConnResultType; end;

ST_UNI_CONN_ESTAB_PackType = RECORD result : ST_ConnResultType; num_channel : Byte; end;

15

UNI_GSM uni_req_term

1 1

Len (nome) nome2 len

Len (nome) nome2 len

ST_UNI_CONN_TERM_PackType = RECORD source_name : ^String; dest_name:^String; end;

UNI_GSM uni_conn_term1 1

// UNI_CONN_TERM nada

{ Pacotes CC_GSM } ST_CC_GSM_PackType = RECORD dest_name:^String; data : array [0..NUMBER_GSM_CHANNELS-1] of Char; end; { Pacotes CC_GSM } ST_CC_GSM_PackType = RECORD dest_name:^String; data : array [0..NUMBER_GSM_CHANNELS-1] of Char; end;

SMS-GSM1

Len(nome) nome2 len

Len(nome) nome2 len

Packet order Numb. Packets1

dados1

{ Pacotes SMS_GSM } ST_SMS_PackType = RECORD destination_name : ^String; source_name : ^String; packet order : word; Number of packets: word; data_p : array [0..NUMBER_OF_GSM_CHANNELS-1] of Char; end; { Pacotes UNI_GSM genéricos } ST_UNI_GSM_PackType = RECORD case codigo : ST_UNI_GSMPackType of UNI_REQ_CONN : (rc_msg : ST_UNI_REC_CONN_PackType); UNI_CONN_IND : (ci_msg : ST_UNI_CON_IND_PackType); UNI_CONN_ACC : (acc_msg : ST_UNI_CONN_ACC_PackType); UNI_CONN_ESTAB : (ce_msg : ST_UNI_CONN_ESTAB_PackType); UNI_REQ_TERM:(rt_msg : ST_UNI_CONN_TERM_PackType);

UNI_CONN_TERM : ( ) ; end;

16

{ Pacotes genéricos }

ST_PackType = RECORD case tipo : STPackType of NNI_OLA : (nni_ola_msg : ST_NNI_OLA_PackType); UNI_SUBSC : (uni_subsc_msg : ST_UNI_SUBSC_PackType); UNI_GSM : (uni_gsm_msg : ST_UNI_GSM_PackType); CC_GSM : (cc_gsm_msg : ST_CC_GSM_PackType); SMS_GSM : (sms_gsm_msg : ST_SMS_GSM_PackType); end; Por exemplo, se a variável para os pacotes for msg, o campo de resultado do

estabelecimento de ligação no pacote UNI_CONN_ESTAB para se saber se a ligação teve sucesso ou não é o seguinte:

msg.uni_gsm_msg.ce_msg.result muito simples, como se pode ver!…

5.2. Rotinas de codificação As rotinas de codificação são as seguintes:

5.2.1. NNI – mensagem de OLA Procedure  new_message_NNI_OLA  (var msg: ST_PackType; 

celula:string;               // nome da celula receivers: array of ST_RecIdType);//receptores registados 

5.2.2. UNI – mensagem de subscrição

Procedure  new_message_UNI_SUBSC  (var msg: ST_PackType; 

tipo:ST_TermEquip;           // tipo de terminal (Emissor ou Receptor) nome:string;                 // nome do telefone IP_telef:TInAddr;            // endereço ip do telefone porto:word; )                 // porto do telefone  

5.2.3. UNI – mensagens de GSM

Procedure  new_message_UNI_CONN_REQ  (var msg: ST_PackType; 

porto:word;                 // porto do telefone emissor nome_emissor:string;        // nome do telefone emissor nome_dest:string;)           // nome do telefone destinatario 

Procedure  new_message_UNI_CON_IND  (var msg: ST_PackType; 

nome:string;               // nome do emissor numChannel:Byte);          // numero do canal pretendido 

17

Procedure  new_message_UNI_CONN_ACC  (var msg: ST_PackType; response: ST_ConnResultType;   // aceita ou não nome:string);                  // nome do telefone emissor 

Procedure  new_message_UNI_CONN_ESTAB  (var msg: ST_PackType; response: ST_ConnResultType;   // aceita ou não numChannel:Byte);              // numero do canalpretendido 

Procedure  new_message_UNI_REQ_TERM  (var msg: ST_PackType; 

nome_emissor:string;        // nome do telefone emissor nome_dest:string);          // nome do telefone destinatario 

Procedure  new_message_UNI_CONN_TERM  (var msg: ST_PackType); 

5.2.4. Mensagem de dados de Voz GSM

Procedure  new_message_CC_GSM  (var msg: ST_PackType; 

nome:string;               // nome do telefone destinatário var buf:ARRAY of char);    // trama de informação 

5.2.5. Mensagens SMS

Dependendo do tipo de pacote alguns dos campos não são considerados na rotina de

codificação. Procedure  new_message_SMS_GSM (var msg: ST_PackType; 

nome_dest:string;             // nome do telefone destinatario nome_emissor:string;          // nome do telefone que emite o pacote packet order: word;          // ordem do pacote enviado Number of Packets;           // numero total de pacotes da mensagem  var buf:ARRAY of char);       // dados 

6. Módulo de relógios Nas redes de Telecomunicações os relógios são fundamentais para várias situações que

incluem recuperações de anomalias, cálculos de tempos de vida de informação, momentos de envio de pacotes, etc.

Muitas das vezes eles devem ser lançados, mas o propósito deles, se tudo correr bem, nunca se cumpre pois aparece algum evento que invalida a acção de recuperação (felizmente). Assim, a maioria dos relógios são lançados e retirados antes de expirar.

Atendendo a este facto, não se devem usar relógios do sistema operativo pois as operações do sistema operativo são muito “caras” – cerca de 10 a 100 milisegundos. O que se faz habitualmente é criar um módulo de relógios virtuais onde se pode colocar e retirar relógios de um modo muito mais rápido. Este módulo de relógios é oferecido aos alunos pelo corpo docente e segue de muito perto a proposta descrita no livro recomendado da disciplina na página 223.

Para se lançar um relógio deve-se chamar um procedimento onde se dá uma identificação do relógio, o tempo que queremos em segundos e um pointer para um procedimento que deve ser chamado quando o relógio expirar (este procedimento tem como parâmetro de entrada o identificador do relógio):

É fornecido aos alunos um módulo “relogios.pas” que contém o módulo de relógios e duas rotinas exemplificativas do seu uso. Estude esse módulo e use-o.

18

Tenha em atenção que pode acontecer que se cancele um relógio num momento tal que já esteja “armada” a chamada à rotina. Isto é, o relógio já expirou e o sistema está à espera para chamar a rotina e entretanto o relógio foi cancelado. Assim, convém que na rotina de serviço ao relógio se verifique se ele ainda faz sentido (através do estado presente na máquina de estados).

Este modo de usar relógios tem a mesma filosofia do DELPHI, pois é mais um evento para o programa, mas desta vez feito pelo próprio programa e não pelo DELPHI.

7. Implementação

7.1. Emissores O programa emissor vai ser responsável pelo envio de caracteres escritos pelo utilizador

para o outro lado e por escrever os caracteres do outro utilizador no écran. Deve-se poder configurar: (a) o nome do emissor; (b) o endereço IP da estação base a utilizar (sendo o valor que deve aparecer na janela no arranque o endereço do PC onde está a correr); (c) no caso de GSM deve-se também poder configurar o tempo que medeia o envio de cada. A ligação a um receptor deve ser escolhida pelo utilizador com o nome desse receptor. No caso do SMS não existe nenhuma informação de canais a escolher, evidentemente.

Pretende-se que os alunos estudem todas as sequências de pacotes válidas para os dois tipos de redes, utilizando a descrição dos protocolos apresentada nas especificações, e que definam as máquinas de estados do emissor que devem realizar para cada um dos protocolos. Nas máquinas de estados devem definir os mecanismos de recuperação de erros (da própria máquina e não de erros de perdas de pacotes), em caso de violações do protocolo. Isto é, em cada estado devem estar preparados para aceitar todos os tipos de pacotes e agir para cada caso (claro, que as acções para pacotes inválidos pode ser muito parecida, ou mesmo igual).

Na fase de programação, os alunos devem ter o cuidado de realizar a máquina de estados definida anteriormente para cada tipo de rede. Devem ainda ter o cuidado de validar todos os pacotes, premir de botões, e expirar de temporizadores, de maneira a tornar o seu programa robusto.

O utilizador deve escolher o tipo de equipamento que pretende que corra e depois deve premir o botão para que o emissor se registe na estação base. No final, termina-se o contacto. O porto do socket do emissor deve ser iniciado a 0 (atribuído aleatoriamente), permitindo que várias cópias do emissor corram em paralelo.

7.1.1. Envio de Dados

O envio de dados pode ser confuso, principalmente no modo de Voz do GSM. O utilizador escreve à sua vontade o texto que quer enviar, mas só se pode utilizar o slot da trama para o quais se pediu a ligação, para enviar o texto. Isto tem o problema do utilizador poder escrever mais depressa do que os dados saem, ou escrever tão devagar que não haja dados para enviar na altura de transmitir o slot. Assim, tem de se fazer o desacoplamento entre a escrita de texto e o envio. Um modo muito simples está ilustrado em baixo na figura com um pseudo-código a seguir.

E u g o s t o m

prox_car

0 00 00 0 00 0 0 0 000

19

O funcionamento é o seguinte: à medida que o utilizador escrever, o carácter vai ser

colocado num buffer (existe um índice com a posição livre em que o carácter deve ser colocado, incrementando-se o índice a seguir); quando são retirados caracteres para serem enviados, chega-se o conteúdo do buffer todo para a esquerda, assim como o índice anterior e limpam-se as últimas posições para zero (0) para não serem lixo. Quando é preciso enviar e não há caracteres tem de se enviar qualquer coisa e o melhor é enviar zero (0) para não aparecer lixo no outro terminal. O exemplo seguinte considera que a ligação está a usar um slot.

O pseudo código é o seguinte: Assume-se que no início do programa o buffer foi enchido a zeros. Rotina de escrita de caracteres: buffer [prox_car] := key; if (prox_car < LIMITE_BUFFER) then prox_car := prox_car + 1; else escrever (‘Pânico: o buffer encheu’); Rotina de envio de caracteres (em cada x segundos): trama [slot_pretendido] : = buffer[i]; if (prox_car > 1) then begin pos_final := prox_car; for j := 1 to pos_final do buffer [j] := buffer [j+1]; if (prox_car > 1) then prox_car := prox_car – 1; end; end end; No serviço SMS pode-se enviar um pacote por mensagem escrita. Se a mensagem tiver

mais do que 100 caracteres, o envio tem de ser feito usando mais pacotes.

20

7.1.2. Emissor de Teste É fornecido um emissor para permitir o teste dos vários programas. A figura abaixo

apresenta uma interface gráfica possível do emissor de teste.

7.2. Receptor

O programa receptor é executado pelo corpo docente. No entanto, os alunos devem cumprir

as especificações para poder comunicar com ele.

7.3. Estação Base O programa estação base vai estabelecer a ligação entre os emissores e receptores, com

qualquer um dos tipos de rede. É fornecido aos alunos uma parte muito pequena de código que contém uma parte da

interface gráfica. Os alunos devem prosseguir a partir daí. O programa deve aceitar que os seus emissores se registem, ficando com essa informação, e

manter a informação de outras células da rede durante o tempo especificado. Uma proposta para a interface deste programa foi mostrada na figura 5.

Pretende-se que os alunos estudem todas as sequências de pacotes válidas para os dois tipos de redes, e sinalização NNI e UNI, utilizando a descrição dos protocolos apresentada nas especificações, e que definam as máquinas de estados da estação base que devem realizar para cada um dos protocolos. Nas máquinas de estados devem definir os mecanismos de recuperação de erros(da própria máquina e não de erros de perdas de pacotes), em caso de violações do protocolo.

Na fase de programação, os alunos devem ter o cuidado de realizar a máquina de estados definida anteriormente para cada tipo de rede. Devem ainda ter o cuidado de validar todos os pacotes, e expirar de temporizadores, de maneira a tornar o seu programa robusto.

Nome do receptor

Período entre pacotes dados

21

8. Disposições Finais Não se devem tratar situações muito excepcionais dado o caracter pedagógico do trabalho

(num trabalho profissional tudo teria de ser considerado). Os casos excepcionais acontecem quando um pacote UDP se possa ter perdido levando a uma situação de impasse na continuação da interacção (deadlock). Não se preocupe com isso.

Postura dos alunos Cada grupo deve ter em consideração o seguinte: • Não perca tempo com a estética de entrada e saída de dados • Programe de acordo com os princípios gerais de uma boa codificação (utilização de

indentação, apresentação de comentários, uso de variáveis com nomes conformes às suas funções...) e

• Proceda de modo a que o trabalho a fazer fique equitativamente distribuído pelos membros do grupo.

DATA DE ENTREGA A duração deste trabalho é de 5 semanas. Este trabalho deve ser entregue até às 24h00 do dia 7 de Junho. Não são permitidas

entregas posteriores, sendo a nota deste trabalho de zero valores. Cumpra a planificação proposta pelo corpo docente (em baixo).

PLANIFICAÇÃO DO TRABALHO

Para permitir um desenvolvimento suave do trabalho os alunos devem cumprir as seguintes etapas. Caso se atrasem devem contar com um esforço suplementar no final, o que é sempre indesejável:

1ª aula – Completar a parte gráfica da Estação Base Executar toda a programação NNI (pacote NNI_OLA, com os relógios, e consequências na parte gráfica e de dados). Escrever a máquina de estados em papel para a estação base.

2ª aula – Programação total da parte do serviço SMS do GSM na estação base. Começo da programação da parte do serviço de voz em GSM na estação base.

3ª aula – Finalização da parte do serviço de voz do GSM na estação base Início da programação do emissor (incluindo a máquina de estados).

4ª aula – Finalização da programação do emissor. 5ª aula – Finalização de possíveis atrasos dos assuntos das 3ª e 4ª aulas